Home

2011 - Anwaltskanzlei Koch

1. Streitz IT Projekte retten 168 x M ller Hengstenberg CR 1999 789 791 Koch IT Projektvertr ge rechtssicher gestalten 43 Pr fung des vorhandenen Codes durch eine Drittfirma selbst oft erheblichen Kosten und Zeitaufwand Erscheint die Fortf hrung der Entwicklung durch den bisherigen Anbieter als vertretbar oder gibt es keine Mitbewerber sollte diese vertraglich neu definiert werden Hier sollten jetzt unbedingt kontrollf hige kleinere Leistungsabschnitte definiert und mit Abnahme Verg tung bzw Vertragsstrafenverwirkung verkn pft werden Milestones Bei diesen Teilabnahme k nnen sollten Dritte Sachverst ndige etc hinzugezogen werden Zugleich ist ein Vorbehalt zu erkl ren dass die Wirkung der Teilabnahme entf llt wenn der Integrationstest fehlschl gt Bei Stundensatzhonoraren sollte die Obergrenze der zul ssig in Rechnung zu stellenden Anzahl der Stunden festgelegt sein Mindestens ein Drittel der Verg tung sollte erst als Schlusszahlung bei Gesamtabnahme Integrationstest f llig werden Auch sollte eine Vertragsstrafe f r den Fall weiterer Vertragsverletzungen vereinbart werden aber durch Individualvertrag Alternativ sollte anbieterseits eine Erf llungsb rgschaft vorgelegt werden Weiter ist zu kl ren ob der Auftragsumfang jedenfalls tempor r auf die wichtigsten Teile des Projektes reduziert werden kann soweit diese trennbar sind Leistungstermine sollten nach M glichkeit als Fixtermine vereinbart
2. In Einkaufs AGB unwirksam dem BGH zufolge ist eine Regelung nach der der Lieferant auch f r unverschuldete Rechtsm ngel einzustehen hat Nach 307 Abs 2 Nr 1 BGB k nne n mlich eine Schadensersatzpflicht nur auf Verschulden beruhen Eine verschuldensunabh ngige Schadensersatzhaftung komme nur in Betracht wenn der Verk ufer f r die Beschaffenheit der Kaufsache eine Garantie bernommen hat nicht aber ohne eine solche Verpflichtung allein aus der gesetzlichen Verk uferhaftung 0 Westermann NIW 2002 241 247 2il Westermann NIW 2002 241 248 BGH Urt v 5 10 2005 VIII ZR 16 05 CR 2006 221 50 Koch IT Projektvertr ge rechtssicher gestalten Teil HI Sonderf lle 1 Einf hrung von ERP Enterprise Resource Planning Software Die Einf hrung von ERP Software stellt ein geradezu klassisches Beispiel f r komplexe IT Projekte dar a Absicherung berpr fbarer schrittweiser Projektdurchf hrung Die zu Recht gef rchtete Kostenexplosion etwa bei R 3 Implementierungsprojekten durch Beratungsfirmen resultiert zumeist aus nicht rechtzeitig beseitigten Unklarheiten ber die Anfangsbedingungen Anbieter tendieren dazu das Projekt allein aus der Perspektive ihrer Software und Konzepte zu sehen Die Ist Analyse und ein Soll Konzept m ssen deshalb zur verbindlichen Grundlage des Implementierungsprojekts gemacht werden damit das Projekt nicht die Bodenhaftung mit der ben tigten Anwendung verliert Weiter is
3. ber die 195 ff BGB weshalb Garantiehaftung mit Schluss des Jahres beginnt 195 Abs 1 BGB in dem der Anspruch entstanden ist und der Gl ubiger Kenntnis erlangt hat oder erlangen musste Ein Sachmangel liegt vor wenn i Gesetzesbegr ndung BT Drucks 14 6040 224 BGHZ 77 218 22 BGH NIW 1978 2241f 3 BGH a a O Palandt Heinrichs 276 Rdn 110 2t BGH NIW 1978 2242 5 BGHZ 77 218 er lessner Richtlinie und Reform Die Einpassung der Kaufgew hrleistungs Richtlinie ins deutsche Recht in Grundmann Medicus Rolland Kaufgew hrleistung 233 244 Gesetzesbegr ndung BT Drucks 14 6040 224 Anspruch bereits aus 280 Abs 1 BGB unabh ngig von Verzugsvoraussetzungen des 281 Abs 1 BGB einschlie lich Anspruch auf Ersatz von Rechtsverfolgungskosten F Gesetzesbegr ndung BT Drucks 14 6040 224 2 Boerner ZIP 2001 2264 2272 Koch IT Projektvertr ge rechtssicher gestalten 49 die Sache nicht die garantierte Beschaffenheit aufweist 434 Abs 1 S 1 BGB Die garantierte Beschaffenheit entspricht der vereinbarten Beschaffenheit Der Verk ufer haftet auf Schadensersatz nach 280 Abs 1 BGB wenn die garantierte Beschaffenheit nicht vorliegt Auf einen Ausschluss der Haftung f r eine Garantie kann der Verk ufer nicht berufen 444 BGB dies gilt auch f r Individualvertr ge 5 Die Garantie im Sinne des 443 BGB wird a andige Vertrag verstanden den auch ein Dritter anbieten bzw abschlie en kann
4. 4 Fortlaufende Kontrolle des Auftragnehmers Diese Abstufungen lassen sich in entsprechender Weise nat rlich auch bei Vergabe von anderen Projekten verwenden Phasen des Outsourcing Projekts nach dem BSI Das GS Handbuch des BSI unterscheidet sieben Phasen von Outsourcing Vorhaben Phase 1 Strategische Planung des Outsourcing Vorhabens Bereits bei der strategischen Entscheidung ob und in welcher Form ein Outsourcing Vorhaben umgesetzt wird m ssen die sicherheitsrelevanten Gesichtspunkte herausgearbeitet und zum Teil des Pflichtenhefts gemacht werden Phase 2 Definition der wesentlichen Sicherheitsanforderungen Die wesentlichen bergeordneten Sicherheitsanforderungen fe das Outsourcing Vorhaben m ssen die Basis f r das Ausschreibungsverfahren sein Phase 3 Auswahl des Outsourcing Dienstleisters Der Outsourcing Dienstleister ist sorgf ltig auszuw hlen Anm des Verfassers Hier sind zun chst konsistente Auswahlkriterien festzulegen Die Auswahl selbst sollte in nachvollziehbarer Weise intern begr ndet und dokumentiert werden 245 i f R FE i Nach Gorritz Habermann Gezieltes und strukturiertes Outsourcing von IT in Dietrich Schirra IT im Unternehmen 235 256 257 Zum BSI Phasenmodell s S 246 GS Handbuch M 2 251 Koch IT Projektvertr ge rechtssicher gestalten 59 Phase 4 Vertragsgestaltung Auf Basis des Pflichtenheftes m ssen mit dem Outsourcing Dienstleister vertraglich die gew nschten Le
5. BGH Urt v 23 7 2009 VII ZR 151 08 CR 2009 637 bezieht sich andererseits nur auf bewegliche Sachen Aus der BGH Rechtsprechung ist damit nicht ableitbar dass 651 BGB analog auf die Online bertragung von Computerprogrammen anwendbar w re 651 BGB beruht auf der Verbrauchsg terkaufgew hrleistungs Richtlinie 1999 44 EG Der dort in Art 1 Abs 2b als bewegliche 74 Koch IT Projektvertr ge rechtssicher gestalten b Anwendbares Vertragsrecht Nach den allgemeinen Grunds tzen schuldet der Anbieter bei Fehlen des Pflichtenhefts aus Werkvertrag nur einen mittleren Ausf hrungsstandard Bei agiler Programmentwicklung hilft der R ckgriff auf einen solchen Standard aber allenfalls in ungekl rt gebliebenen Teilbereichen der Entwicklung da die Ausgestaltung der Software gerade in Abstimmung mit dem Kunden anstelle der Pfichtenhefterstellung erfolgen soll Gewisserma en erstellen Anbieter und Kunde die ben tigte Zusammenstellung der Leistungsmerkmale gemeinsam Einiges spricht daf r dass zwar das Entwickeln einer ersten Fassung einer lauff higen und demonstrierbaren Grundfunktionalit t Werkvertragsrecht oder ber 651 BGB Kaufrecht folgt die zumal m ndlich gesteuerte quasi auf Zuruf erfolgende Weneren une und Ausgestaltung der ersten Fassung hingegen Dienstvertragsrecht Die Leistungen sind freilich auch dann unter Einhalten der Ma st be des Stands der Technik der Softwareerstellung zu erbringen die Nichteinh
6. Lieferung einer Bedienungsanleitung bzw eines en Euch verpflichtet anderenfalls erf llt er den Vertrag jedenfalls teilweise nicht Eine Entwicklungsdokumentation ist zumindest dann geschuldet wenn der Anbieter nicht die Pflege der aktualisierungsbed rftigen Software bernimmt und der Kunde alle Rechte an der Software einger umt erhalten hat Dies wirft die Frage auf ob die Wahl agiler Methoden der Softwareentwicklung den Anbieter ohne Weiteres von dieser vertraglichen Dokumentationspflicht befreien kann Hier ist zu differenzieren Allein daraus dass der Anbieter ein agiles Entwicklungsverfahren anbietet muss f r den Kunden noch nicht erkennbar sein dass er nicht mit einer Benutzerdokumentation rechnen darf wenn er nicht ausnahmsweise selbst im Bereich der Software Entwicklung t tig ist Selbst das Agile Manifesto schlie t eine Dokumentation nicht generell aus sondern behandelt sie in der Gewichtung nur nachrangig Der Anbieter muss deshalb dem Kunden ausdr cklich zu erkennen geben dass die Dokumentationserstellung nicht zur gew hlten Leistungsform geh ren soll Dies Anschaulich macht dies Ebert Systematisches Requirement Management 2005 245f Viele Prozesse wachsen ber die Zeit stark an weil man sich nie fragte was davon inzwischen unn tig ist Auf jeden Fehler im Produkt kam ein weiterer Testschritt Mit jeder falsch verstandenen Anforderung aus einem Kundenkontakt hat sich die Checkliste vergr ert Mit j
7. Minderung pauschalierter und ah ebenso Messverfahren und Reporting durch Anbieter ber die Einhaltung der Vorgaben in Service Level Agreements vereinbaren e Spezifikation von Schnittstellen Sind die IT Systeme des Auftragebers und des Auftragnehmers tk panel muss in einem Migrationsprojekt vorab eine Anpassung erfolgen Diese kann bei einer Vielzahl von Komponenten sehr umfangreich ausfallen Spezifikation von technischen Standards e Sicherheitsregeln e Mandantenf higkeit des IT Systems des Anbieters Auslegung f r mehrere Auftraggeber Teilweise nach Lux Sch n Outsourcing der Datenverarbeitung 1997 Gadatsch IT Controlling in Tiemeyer Hrg Handbuch IT Management 359 397 Klotz Dorn Vertragsmanagement in der Informationsverarbeitung 20 Die Auflistung kann schon aus Raumgr nden nur die wichtigsten Regelungspunkte erfassen Heymann Lensdorf Outsourcing Vertrag in Redeker Hrg Handbuch der IT Vertr ge Abschnitt 5 4 Rdn 12 die Verfasser warnen zutreffend dass Outsourcing Vertr ge i d R sehr umfangreich ausfallen bei den Autoren erstreckt sich ein Vertragsmuster auf etwa 96 Druckseiten Bl selPechardscheck CR 2002 785 787 Br utigam IT Outsourcing Teil 11 Rdn 23 Bl selPechardscheck CR 2002 785 788 i H rllH user CR 2003 713 717 R Vertragsstrafen werden mangels abweichender Vereinbarung nur bei Verschulden verwirkt BGH BB 1991 2252 7 Heymann Lensdorf Outsourcing Vertrag
8. analysiert vereinbart und un Projekt zugewiesen im Projekt verfolgt und als nderungen vereinbart werden Die Anforderungen m ssen m glichst vollst ndig erfasst ynd eindeutig sowie konsistent formuliert werden soll ihre Erf llung berpr fbar sein Hzu erfassen sind funktionale und nichtfunktionale Anforderungen Funktionale Anforderungen beziehen sich auf die einzelnen Funktionen der Gesch ftsprozesse oder sonstiger Anwendungen Eine Schwachstelle im Projekt stellen erfahrungsgem nichtfunktionale Anforderungen dar Sie werden mit teilweise eher vagen und jedenfalls nicht aus sich pr zise in der Erf llung berpr fbaren Eigenschaften wie Benutzbarkeit Verst ndlichkeit Performanz Qualit t Sicherheit Wartbarkeit Portierbarkeit oder Zuverl ssigkeit beschrieben ISO IEC 9126 f hrt u a folgende nichtfunktionale Eigenschaften an Interoperabilit t F higkeit mit vorgegebenen Systemen zusammenzuwirken Ordnungsm igkeit Erf llung anwendungsspezifischer Normen Vereinbarungen gesetzlicher Bestimmungen etc Daten Sicherheit Zuverl ssigkeit F higkeit der Software ihr Leistungsniveau unter festgelegten Bedingungen ber einen festgelegten Zeitraum zu bewahren Benutzbarkeit Verst ndlichkeit Erlernbarkeit und Bedienbarkeit Effizienz Verh ltnis zwischen dem Leistungsniveau der Software und dem Umfang der eingesetzten Betriebsmittel
9. ge rechtssicher gestalten a eXtreme Programming Der am weitesten ee Ansatz ist das von Kent Beck ausgearbeitete eXtreme Programming XP Die Anforderungen werden in Form von User Stories m glichst vom Kunden selbst auf Story Cards beschrieben die allerdings nicht die Dokumentation implementierter Programmteile aufweisen Die Anforderungen k nnen sich bei Hinzutreten weiterer Benutzerw nsche immer wieder ndern XP verlangt ein iteratives und ikre mente les Vorgehen jede solche Iteration soll etwa zwei bis drei Wochen dauern Projektplanung e erfolgt nicht im Gesamtmodell sondern von Iteration zu Iteration ebenso die Aufwandssch tzung die jeweils vom Kunden gebilligt werden muss 2 Ausgangspunkt sind in Quick Design Sessions festgelegte Entw rfe B amp Einheitlicher Programmierstil und Konventionen sind einzuhalten Erforderlich sind Reviews um Fehler im Code oder Abweichungen von Standards oder in Anforderungen festzustellen Beim XP kann der Kunde ny gen Quellcode und die Unit Tests als Dokumentationssubstitute erwarten nicht aber eine Entwicklungsdokumentation eine f r viele Anwendungen unzureichende Basis Der Kunde tut gut daran die Erstellung einer Benutzerdokumentation und erst recht wenn ben tigt einer Entwicklungsdokumentation ausdr cklich zu vereinbaren die er insbesondere immer dann ben tigen wird wenn er etwa Drittfirmen sp ter mit Softwarepflegeleistungen beauftragen will Der Kunde muss a
10. glich sollen Gespr che haupts chlich zwischen Entwicklern nicht notwendig mit dem Kunden stattfinden Daily Scrum Jede Sprint Phase ist r ckblickend zu beurteilen Retrospektive b Crystal Family F r die agile Softwareentwicklung eingesetzt werden k nnen verschiedene Verfahren Ein Beispiel ist ne der Anzahl der beteiligten Personen differenzierende Crystal Family Anders als etwa bei XP ist bei Crystal ein Entwickeln beim On site Customer und das Pair Programming nicht erforderlich Viel verwendet wird auch das in der Programmiersprache Ruby geschriebene gye loreng Web Application Framework Ruby on Rails oder kurz Rails das mit einer Art Ger stbau Scaffolding das Schreiben von a Obendorf Szenariotechniken amp Agile Softwareentwicklung in Gross Hrg Mensch amp Computer 2007 Konf f r interaktive und kooperative Medien 2007 19 http mc informatik uni hamburg de konferenzbaende mc2007 konferenzband mc2007_04_Obendorf pdf der von einer Scheu vor einem big upfront Design spricht Hierdurch kann sich freilich f r den Kunden wirtschaftlich der Korrektur und Anpassungsaufwand erh hen n Balzert www w3l de W3lmedia W3L Medium164417 folien BleeklWolf Agile Softwareentwicklung 2008 149 BleeklWolf Agile Softwareentwicklung 2008 151 F r alle Cockburn in http alistair cockburn us Crystal Clear distilled Balzert Lehrbuch der Softwaretechnik So
11. glichst kurzfristige Exploration und Abschluss eines Projekts mit einem rtlich konzentrierten kleinen Team unter Kundenbeteiligung Komplexe Produktions oder Entwicklungsprozesse die sich weder insgesamt noch in Einzelschritten im Voraus planen lassen Vorliegen eher weicher und yong ausformulierter Anforderungen die sich w hrend der Erstellung ndern 2 Entbehrlichkeit des Pflichtenhefts keine Ausschreibung BleeklWolf Agile Softwareentwicklung 2008 163 gt Bleek Wolf Agile Softwareentwicklung 2008 161 BleeklWolf Agile Softwareentwicklung 2008 161 BleeklWolf Agile Softwareentwicklung 2008 162 gt t BleeklWolf Agile Softwareentwicklung 2008 163 3 BleeklWolf Agile Softwareentwicklung 2008 165 75 9 HindellH rmann M ller Schmied Geplante Selbstorganisation in iX Kompakt IT Projekte 3 2009 80 82 7 HindellH rmann M ller Schmied Geplante Selbstorganisation in iX Kompakt IT Projekte 3 2009 80 83 i Ebert Systematisches Requirement Management 2005 249 2 Balzert Lehrbuch der Softwaretechnik Softwaremanagement 2 Aufl 2008 683 76 Koch IT Projektvertr ge rechtssicher gestalten Teil IV Rechtliche Verantwortlichkeit der Gesch ftsleitung f r die Projektdurchf hrung Gute IT Projektvertr ge k nnen f r das auftraggebende Unternehmen berlebenswichtig sein Werden erforderliche vertragliche Regelungen etwa zur zeitnahmen Projektkontrolle oder Ma nahmen zur te
12. hrungsfristen berufen kann wurde AGB rechtlich als zul ssig angesehen Jeder Shader muss dokumentiert werden und wie die Hauptleistung qualit tsgesichert erfolgen Das muss auch f r Manselbsseinzungen als Form von Changes gelten in der Praxis keineswegs die Regel 6 Mitwirkung des Auftraggebers Der Kunde hat bei der Projektdurchf hrun m itzuwirken Obliegenheit im Einzelfall auch Schuldnerpflicht etwa als Pilotkund amp So hat er etwa die f r den Anbieter wesentlichen Installationsvoraussetzungen herzustellen fachkompetentes Personal zur Mitwirkung bei Anlieferung Installation Einweisung und Funktionspr fung zu stellen BGH Urt v 24 6 1986 X ZR 16 85 CR 1986 799 KG Berlin Urt v 1 6 1990 14 U 4238 86 CR 1990 768 770 a Schneider v Westphalen Redeker Software Erstellungsvertr ge D Rdn 202 5 Schneider v Westphalen Redeker Software Erstellungsvertr ge D Rdn 191 Koch IT Projektrecht Rdn 155 T HindellH rmann M ller Schmied Basiswissen Software Projektmanagement 186 BGH CR 1993 424 S Projekt II Streitz IT Projekte retten 135 Koch IT Projektrecht Rdn 162 Koch IT Projektrecht Rdn 173 24 Koch IT Projektvertr ge rechtssicher gestalten und bez glich des Eigentums des Anbieters etwa an dessen Rechgern Verkehrssicherungspflichten bzw vertragliche Schutzpflichten zu bernehmen Die Kosten f r diese Mitwirkung muss der Kunde vor
13. ngelhaftung soweit Kauf bzw Werkvertragsrecht anwendbar w hrend der gesamten Vertragslaufzeit Zu unterscheiden sind M ngel der Transition Leistungen und der eigentlichen Outsourcing Leistungen Fehlerklassendefinitionen sind meist nur auf letztere anwendbar Eskalationsverfahren Regelung der bernahme der Software wenn die Software des Auftraggebers vom Outsourcing Anbieter bernommen werden soll Im Vertrag Auftraggeber Software Anbieter muss diese Weitergabe lizenzrechtlich zugelassen sein Datenschutz f r Kunden und Mitarbeiterdaten Datensicherheit der IT Systeme des Auftraggebers und des Auftragnehmers Kompetentes und zertifiziertes Fachpersonal Auch nachvertraglicher mit Vertragsstrafen bewehrter Know how Schutz f r Betriebs und Gesch ftsgeheimnisse Regelung zur berleitung von Mitarbeitern gem 613a BGB Betriebs teilJ bergang Festzulegen sind die bergehenden Mitarbeiter deren Information 613 a Abs 5 BGB und eine Regelung zum bergang der Haftung f r Forderungen der bergehenden Mitarbeiter bergang von Miet Leasingvertr gen f r Hardware auf den Austrasnehmer soweit dieser Systeme bernimmt Heymann Lensdorf a a O Abschnitt 5 4 Rdn 215 Zum Change Management s S f r ITIL f r ISO 20000 Heymann Lensdorf Outsourcing Vertrag in Redeker Hrg Handbuch der IT Vertr ge Abschnitt 5 4 Rdn 268 62 Koch IT Projektvertr ge rechtssicher gestalten e Regelung zu
14. ssen aufeinander abgestimmt erfolgen was mehrere Anpassungsdurchl ufe erforderlich machen kann Ziel des RM ist die Anforderungen an die im Projekt erstellten Produkte und Produktkomponenten zu managen und Inkonsistenzen zwischen diesen nun und den Projektpl nen sowie den Arbeitsergebnissen zu identifizieren ne gr ndet sich wesentlich auf das Capability Maturity Model Integration CMMI das seinerseits aus dem Capability Maturity Model CMM des Software Engineering Instituts SED entwickelt wurde Grundlage des CMM sind die Normen ISO 15504 f r Assessment und Modelle der Prozessverbesserung ISO 12207 f r Lebenszykle H ISO 15288 f r Schnittstellen im Lebenszyklus und SPIC Das CMMI weist f nf Reifegrade auf Initial bzw ad hoc der Projekterfolg ist von Einzelinitiativen abh ngig Gemanagt Anforderungsmanagement Projektmanagement wird f r einzelne Projekte durchgef hrt Definiert einheitliche Prozesse f r die gesamte Organisation spezifizierte Anforderungsentwicklung Quantitativ goanagi durch statistische und quantitative Techniken und Optimierend j CMMI ist st rker als ISO 9001 prozessorientiert erleichtert also Kontrollen Spezifisch auf das RM bezogen sind der IEEE Standard 1233 f r die Entwicklung und Spezifizierung von Anforderungen von Systemen w hrend der IEEE Standard 830 Ebert Systematisches Requirements Management 18 Koch Requirements Management IT Rechtsb
15. Anpassung des Projektplans erforderlich macht Auch Ma nahmen zur Beseitigung von M ngeln sind zu dokumentieren Unzumutbar kann die mehrfache Wiederholung von M ngelbeseitigungsversuchen f r den Kunden sein wenn die Nachbesserungsversuche mit personellem und zeitlichen Mitwirkungsaufwand auf der Kundenseite verbunden sind Der Anbieter muss alle Kosten der Nacherf llung tragen so auch alle Nebenkosten etwa f r ra Anfahrt Arbeitszeit und el ebenso erforderliche Nebenarbeiten etwa von Anpassungen des bereits erstellten an sich m ngelfreien Programmcodes die durch die M ngelbeseitigung erforderlich werden Hierzu geh ren auch Megraufwendungen f r erneut durchzuf hrende Tests Der Anbieter kann die Nacherf llung aber verweigern wenn sie f r ihn mit unverh ltnism igen Kosten verbunden w re 635 Abs 3 BGB Der Anbieter ist aber schon aus seiner vertraglichen Leistungstreuepflicht im Projektvertrag gehalten nach M glichkeit eine tempor re oder dauerhafte Umgehungs oder Ausweichl sung zu realisieren Auch wird er zu pr fen haben ob m gliche Schadensersatzanspr che des Kunden bei R cktritt wegen Verweigerung der Nachbesserung und Projektabbruch zu einer deutlich h heren Kostenbelastung als eine M ngelbeseitigung oder sogar Neuerstellung f hren k nnen 3 Dann sind allenfalls Fehler des Datentr gers denkbar LG Coburg Urt v 1 8 1984 2 O 478 83 TUR 1986 314 7 BGH NIW 1979 2095 198 BG
16. Basis eine Feature Liste planend entwerfend und entwickelnd abgearbeitet Die Entwicklung ist durch Re bersichtliche Granularit t des iterativen und inkrementellen Entwickelns leichter kontrollierbar und dokumentierbar jedoch muss der Kunde sp testens mit Abschluss des Gesamtmodells genau wissen was er will Au erdem ist an keiner Stelle im Entwicklungsprozess ein vollst ndiger Entwurf vorgesehen wodurch das Erreichen eines einheitlichen Designs erschwert wird und sich Features nach 2 Wird eine Entwicklungsumgebung Framework wie JUnit eingesetzt m ssen die Tests m glichst schnell lauff hig gemacht werden sodass im Test Framework der Balken gr n wird Hruschka Rupp Starke Agility kompakt 2 Aufl 2009 89 Richtig verstanden zeigt dieser Hinweis dass die Testf lle eigentlich kleine Anwendungsteile Units sind nicht reine Pr ftests aus Kundensicht ob fertig erstellter Code funktioniert Vielmehr wird solange Code ge ndert bis der Test l uft Der Kunde muss hier pr fen k nnen ob das Programm an die Anforderungen angepasst wird und nicht umgekehrt die Anforderungen an die lauff higen Testteile HruschkalRupp Starke Agility kompakt 2 Aufl 2009 86 S die Hinweise bei http www iur it de beitraege Agile_Total_Ouality 3 Balzert Lehrbuch der Softwaretechnik Softwaremanagement 2 Aufl 2008 660f 4 BleeklWolf Agile Softwareentwicklung 2008 90 BleeklWolf a a O 152 BJeeklWol
17. Erg nzungen in einem geregelten Verfahren erfolgen dem sog Change Management Zwei Typen von Change Requests sind zu unterscheiden nderungen oder Erg nzungen der vereinbarten Leistungen sind grunds tzlich nur bei Vereinbarung anbieterseits geschuldet und meist mit Mehraufwendungen f r den Anbieter verbunden Als Mehrverg tung kann der Anbieter diese zus tzlichen Kosten nur berechnen wenn dies zumindest stillschweigend 632 Abs 1 BGB vereinbart war Mit seinem nderungs Erg nzungsantrag fordert der Kunde den Anbieter auf ihm dem Kunden ein Angebot ber die Durchf hrung zu machen invitatio ad offerendum Der Anbieter wird ein solches Angebot meist in den F llen machen in denen der Auftraggeber zur Zahlung einer angemessenen Zusatzverg tung bereit ist hingegen einen Change ablehnen wenn die Ausf hrung des gew nschten Changes technisch nicht oder nur unter unverh ltnism igem Aufwand m glich w re oder wenn die Auswirkungen des Changes auf bereits erstellte Leistungsteile gerade im Programmierungsbereich nicht oder nur sehr schwer kontrollierbar sind Schon die Pr fung von Changes kann verg tungspflichtig wenn sie mit nicht unbetr chtlichem Stahlknecht Hasenkamp Einf hrung in die Wirtschaftsinformatik 218 t Streitz IT Projekte retten 4 50 Koch IT Projektvertr ge rechtssicher gestalten 23 Zusatzaufwand verbunden ist Dem BGH zufolge muss aber der Anbieter bei Vertragsschluss in gewissem Um
18. Governance Diese Anforderungen werden wie folgt aufgeschl sselt e Die Leistungserstellung der IT muss im Rahmen der IT Security Anforderungen Integrit t Vertraulichkeit Verf gbarkeit gew hrleistet werden e Die IT Strukturen sollten offen und herstellerunabh ngig sein e Die IT Strukturen m ssen von den Kapazit ten her skalierbar sein die Integration von weiteren Partnern oder Tochterunternehmen muss unkompliziert m glich sein e Eine einheitliche Datenbasis muss f r alle Anwendungen gegeben sein keine Redundanzen e Ein effektives Schnittstellenmanagement hat zu erfolgen d h Schnittstellen sind leicht einzubinden und die Verf gbarkeit der Schnittstellen garantiert e Die Gesamtkosten Total Cost of Ownership TCO f r die einzelnen Anwendungen m ssen m glichst gering sein K Streitz IT Projekte retten 43 i Streitz IT Projekte retten 23 f Wintersteiger IT Strategien entwickeln und umsetzen in Tiemeyer Hrg Handbuch IT Management 45 Buchta EullSchulte Croonenberg Strategisches IT Management 15 Seibold IT Risikomanagement 164 Seibold IT Risikomanagement 164 16 Koch IT Projektvertr ge rechtssicher gestalten e Eine optimale Gesch ftsprozessunterst tzung ber Unternehmensgrenzen hinweg wird erwartet Sorgf ltig ist zu pr fen ob vorhandene ltere Systeme EDV Inseln wirklich noch weiterhin genutzt werden m ssen Meist m ssen hier individuelle K
19. Handbuch des BSI B 1 11 Das GS Handbuch unterscheidet folgende Formen Outsourcing ist der Oberbegriff Tasksourcing bezeichnet das Auslagern von Teilbereichen Werden Dienstleistungen mit Bezug zur IT Sicherheit ausgelagert wird von Security Outsourcing oder Managed Security Services gesprochen z B die Auslagerung des Firewall Betriebs die berwachung des Netzes Virenschutz oder der Betrieb eines Virtual Private Networks VPN Unter Application Service Provider ASP versteht man einen Dienstleister der auf seinen eigenen Systemen einzelne Anwendungen oder Software f r seine Kunden betreibt E Mail SAP Anwendungen Archivierung Web Shops Beschaffung Auftraggeber und Dienstleister sind dabei ber das Internet oder ein VPN miteinander verbunden Beim Application Hosting ist ebenfalls der Betrieb von Anwendungen an einen Dienstleister ausgelagert jedoch geh ren im Gegensatz zum ASP Modell die Anwendungen noch dem jeweiligen Kunden 56 Koch IT Projektvertr ge rechtssicher gestalten Endet ein Wartungs oder auch ein Outsourcing Vertrag ben tigt der Kunde im Rahmen der erforderlichen Beendigungsunterst tzung seine Daten rechtzeitig vor Vertragsende um z B den Vertragspartner bruchlos wechseln zu k nnen Die Rechtsprechung bejahte a entsprechenden Anspruch auf R ck bertragung rechtzeitig vor Vertragsende amp ohne dessen Ausgestaltung aber n her festzulegen Im Vertrag sollten deshalb der passende Zeitpunkt und die Durchf
20. Rdn 5 selbst ndig verwertbares Teilprogramm BGH Urt v 8 1 2002 X ZR 6 00 JurPC Web Dok 98 2002 Koch IT Projektrecht Rdn 121 22 Koch IT Projektvertr ge rechtssicher gestalten f Zeitplan f r Projektaktivit ten F r jedes IT Projekt sollte ein verbinflicher Zeitplan erstellt werden aus dem die Anbieterleistungen und kundenseitigen Mitwirkungshandlungen in eine zeitlicher Abfolge ablesbar sind Aus einem Projektzeitplan sollte also f r jede Phase erkennbar sein wann etwas_zu tun ist wer etwas zu tun hat und welche Kosten hierbei h chstens entstehen d rfen Bei Terminfestlegungen sollten Reservezeiten quasi als Puffer vorgesehen werden um m glichen een Schwierigkeiten gescheiterte Teilabnahmen etc Rechnung tragen zu k nnen g Installation Die Vertragsparteien sollten im Projektvertrag ausdr cklich regeln welcher Vertragspartner die Installation der Software durchzuf hren hat Zu regeln ist auch die Installation von Updates und neue Versionen der Software gleich on es sich um Software Pflegeleistungen oder Nacherf llung handelt Zu kl ren und zu vereinbaren ist auch ob automatische Installationsroutinen eingesetzt werden und ob eine Funktionspr fung nach Installation erfolgt etwa zur Suche neuer M ngel wenn im Patch ger gte M ngel beseitigt wurden 5 Change Management Viele IT Projekte werden in ihrer Durchf hrung erg nzt oder ge ndert Zur besseren Kontrolle sollten diese nderungen und
21. RfCs steuern ISO 20000 enth lt eine integrierte und prozessorientierte Methodik f r eine effektive Planung und Erstellung von IT Services Die Norm folgt dem PDCA Zyklus des Plan Service Management planen Do Service Management implementieren Check berwachen Messen ber Pr fen und Act kontinuierlich verbessern Ebert Systematisches Requirements Management 103 109 Ebert Systematisches Requirements Management 13 Ebert Systematisches Requirements Management 135 121 Ebert Systematisches Requirements Management 75 177 S n her Koch ITRB 2008 61 und Koch Requirements Management IT Rechtsberater 7 2009 160 162 Vietor G nther Optimiertes IT Management mit ITIL 27 t Vietor G nther Optimiertes IT Management mit ITIL 57 ISO IEC 20000 2 Nr 4 1 4 4 Koch IT Projektvertr ge rechtssicher gestalten 11 Mit zunehmender Projektdauer w chst freilich die Anzahl der nderungen und der Aufwand f r ihr Management Empfohlen wird deshalb mittels einer Wirtschaftlichkeitsrechnung projektspezifisch einen Zeitpunkt festzulegen und zu vereinbaren ab dem die Anforderungen gewisserma en eingefroren werden da das Projekt auch die zunehmende Anzahl von nderungen unwirtschaftlich wird Freeze amp In gr eren Projekten wird diese laufende Dokumentanpassung meist nur mittels Versionierung und als IT gest tztes Document Management zu bew ltigen sein In auf Datenbankbasis zu imple
22. Transition regelt den bergang des IT Betriebs der Leistungsteil dann die vom Outsourcing Anbieter zu erbringenden Leistungen Beide Teile sind integriert in ein Projekt zu definieren und zu vereinbaren Besonders regelungskritisch ist die Transition da hier von einer individuell Nach Scheja Schmitt CR 2005 321 322 323 x Heymann Lensdorf Outsourcing Vertrag in Redeker Hrg Handbuch der IT Vertr ge Abschnitt 5 4 Rdn 5 58 Koch IT Projektvertr ge rechtssicher gestalten unterschiedlichen Ausgangsbasis auszugehen ist Die berzuleitenden Funktionen und die Art der berleitung sind deshalb genau zu spezifizieren Das Outsourcing Projekt selbst wird in der Literatur in vier Phasen aufgeteilt 1 Bestimmen der Zielsetzung und Vorbereitung der internen Strukturen Hier sind die Schnittstellen zu beschreiben Kommunikationsprozesse zu strukturieren und Service Levels festzulegen Metriken und Berichtsstrukturen einzuf hren 2 Auswahl des externen Partners bzw Definition der Organisationsstruktur Neben Preisen und Service Levels m ssen Servicequalit t und die F higkeit zur reibungslosen Gestaltung des bergangs der entsprechenden IT Funktionen evaluiert werden Das Vertragsvolumen muss unter Wahrung von Vorlauffristen erh ht oder verringert werden k nnen 3 bergabe der Aufgabe bergang des Personals und gegenenenfalls von IT Infrastruktur und Lizenzen gesteuert durch Projektmanaement und Reporting
23. berschaubare Teilprojekte abgegrenzt werden e extensives Testen 100 aller Fehler lassen sich nur mit unverh ltnism igem Aufwand wenn berhaupt feststellen Sinnvoll erscheint eine Begrenzung auf Kernfunktionalit ten e Mehrfachentwicklungen sollten im auftraggebenden Unternehmen etwa ber Projektdatenbanken erkannt und verhindert werden 1 Ausf zur IT Konsolidierung s Tiemeyer Hrg Handbuch IT Management 99 nS Keese Wehner IT Konsolidierung im Rahmen einer Post Merger Integration in Dietrich Schirra IT im Unternehmen 201 213 Palandt Heinrichs B rgerliches Recht 433 Rdn 41 und 47 i Nach ohne Verf Schwarze L cher im Budget Computerwoche 36 2004 26 40 Koch IT Projektvertr ge rechtssicher gestalten Die angef hrten Punkte sind auch bei Unternehmensfusionen zu pr fen bei denen eine IT Merger Integration durchzuf hren ist um Kostensynergien in der Wertsch pfungskette zu erreichen Kosten lassen sich in diesem Zusammenhang etwa durch Ham nisieren von Gesch ftsprozessen und Standardisieren der IT Infrastruktur 178 179 erreichen Als Strategien zur Kosteneinsparungen werden genannt 13 Risiken und Sanierung von IT Projekten a Risiken Je gr er der Entwicklungs und oder Anpassungsteil in IT Projekten ist desto mehr Risiken bestehen dass das Projekt Verz gerungen erleidet oder scheitert Angesichts der Vielgestaltigkeit der Projekte lassen sich mes nur allgemein u
24. dem Netz und in Einzelf llen auch Risiken aus der Nutzung nicht lizenzierter Software durch Mitarbeiter Die Konsequenzen von St rungen und Ausf llen betrieblicher IT Systeme oder aus massiven Angriffen Dritter aus dem Internet auf das IT System k nnen zur zeitweisen Unterbrechung der gesamten Produktion und oder Gesch ftst tigkeit f hren insbesondere bei unzureichender Datensicherung und damit rasch zur Insolvenz des betroffenen Unternehmens Deshalb geh rt auch die berwachung des gesicherten Ablaufs der Funktionen betrieblicher IT Systeme zur notwendigen Bestandssicherung ebenso aber das Vorbeugen von Risiken aus Verz gerung oder gar Scheitern von IT Projekten Teil V ITIL und ISO Normen als Pr fma stab ITIL Information Technology Infrastructure Library stellt eine aus der Praxis gebildete Best PACUGE ana und einen de facto Standard da ISO 20000 eine international geltende Norm Gegenw rtig wird Version ITILv3 angewendet Die Standards nach ITIL und ISO definieren konkrete Mindestanforderungen die als objektiver Ma stab f r die Ziele von Umsetzungsprojekten dienen k nnen und liefern Diese Risiken gelten als leistungswirtschaftliche Risiken Lange Wall Lange Risikomanagement nach dem KonTraG 2001 2 Rdn 22 Koch IT Projektrecht Rdn 624 Koch IT Projektrecht Rdn 650 2 Koch IT Projektrecht Rdn 704 Koch IT Projektvertr ge rechtssicher gestalten 79 Kontrollzie
25. der gesamten Projektdurchf hrung geschuldet wird Die Einheit des Projekts erlaubt freilich nicht diese und andere projektspezifische Leistungen vertragstypologisch v llig isoliert zu behandeln sondern es muss gewisserma en ein bergreifender vertraglicher Mantel gefunden werden der eine Vererinheitlichung der Rechtsfolgen bei Leistungsst rungen und hier insbesondere bei Leistungsm ngeln erlaubt Dies gelingt etwa durch Annahme eines Typenkombinationsvertrags a M ngelrechte aus Werkvertrag Der Anbieter muss frei von Sach und Rechtsm ngeln leisten 633 Abs 1 BGB Ob ein Mangel vorliegt bestimmt sich nach der vereinbarten Beschaffenheit 633 Abs 2 BGB bzw ersatzweise nach der vertraglich vorausgesetzten oder jedenfalls gew hnlichen Verwendung Ist die Werkleistung etwa das IT bezogene Pflichtenheft oder die Software mangelhaft kann der Auftraggeber die Abnahme 640 BGB verweigern da das geschuldete Werk nicht vertragsgem ist Nimmt der Auftraggeber die Leistung dennoch ab muss er sich seine Bestellerrechte aus 634 Nr 1 3 BGB einschlie lich Schadensersatzanspr chen vorbehalten wenn er von M ngeln Kenntnis hat 640 Abs 2 BGB Ein entsprechender Vorbehalt sollte im Abnahmeprotokoll ausdr cklich erkl rt werden Der Kunde darf nicht bersehen dass die kaufm nnische R gepflicht auch hei Werklieferungsvertr gen 381 Abs 2 377 HGB ber Individualsoftware besteht wenngleich sie f r ED
26. der Infrastruktur einschlie lich DOIDYSTSDLEUNG und Klimatisierung von Serverr umen Zugangsgew hrung Datensicherung Die Leistung der Software Pflege bzw Systemwartung l sst sich mit verschiedenen technisch definierbaren Parametern n her spezifizieren So bezeichnet man als Reparaturzeit Time To Repair ie Zeit bzw die Summe der Zeiten zwischen Ausfall und Neuanlauf des Systems Die TTR ergibt sich aus der Summe der Diagnosezeit Detection Time und der Reparaturzeit Meist wird eine mittlere Reparaturzeit zugrundegelegt Mean Time To Repair MTTR Gemessen wird weiten die mittlere Zeit zwischen zwei Ausf llen Mean Time Between Failures MTBF F r den Anwender ist die Vereinbarung der maximalen Dauer der TTR noch wesentlich wichtiger als die Mindestreaktionszeit in der mit einer Fehlerbeseitigung begonnen wird dies gilt besonders wenn die Anwendung unterbrechungssensibel ist etwa eine Webpr senz und jeder Nutzungsausfall zu einem Umsatzentgang f hrt Werden Fehlerbehebungszeiten vereinbart wird oft eine e nach Fehlerkategorien getroffen z B in critical major und minor a Koch Computer Vertragsrecht Rdn 950 133 Koch IT Projektrecht Rdn 230 134 2 Nach Wesseler Computerwoche extra 5 v 6 7 2001 8 9 Der Autor berichtet von einer Tagung den beherzigenswerten Satz Vereinbaren Sie nichts was Sie nicht messen und verrechnen k nnen Etwa im Rahmen der ARM Application Re
27. der Praxis Pflichtenheft im Sinne der Rechtsprechung 3 Stahlknecht Hasenkamp Einf hrung in die Wirtschaftsinformatik 228 Koch IT Projektrecht Rdn 18 Koch IT Projektvertr ge rechtssicher gestalten 7 detailliert aufgeschl sselt Das Spezifizieren der zur Erf llung der fachlichen Aufgaben erforderlichen IT im IT Pflichtenheft pst hingegen grunds tzlich in der Verantwortlichkeit des beauftragten Anbieters Die Erstellung der Anforderungsanalyse ist grunds tzlich vom Kunden durchzuf hren E wenn nicht der Anbieter mit dieser Analyse etwa als Studie ausdr cklich gesondert beauftragt wird Auch ohne solchen Auftrag muss der Anbieter aber auf f r ihn erkennbany Unklarheiten hinweisen und bei der Formulierung der Bed rfnisse mitwirken jedenfalls dann wenn der Kunde zu erkennen gibt dass er dieser Unterst tzung bedarf Der Anbieter muss mangels abweichender Vereinbarung aber nicht von sich aus ohne gesonderte Vereinbarung die fachlichen Anforderungen des Kunden komplett untersuchen Requirements Management Die Anforderungen k nnen im Verlauf l ngerfristiger IT Projekte an neue Gegebenheiten anzupassen sein Diese Anlassung bedarf genauer Kordinierung damit nicht z B bereits erbrachte Leistungsteile ihre Verwendbarkeit verlieren Notwendig ist hier ein geregeltes Requirements Management RM Ziel muss es sein dass auch nach Festlegen und Durchf hren aller Erg nzungen und nderungen f r beide Seiten erkennbar b
28. erfordern Einzelne Anbieter versuchen eine Konkretisierung indem sie zu ber cksichtigende Faktoren benennen etwa die Realisierbarkeit innerhalb des gemeinsam verabschiedeten und fortgeschriebenen Zeitplans den Grad der Unabweisbarkeit einer Anforderung die Verf gbarkeit einer bereits vorhandenen oder schneller realisierbaren und zumutbaren L sung bzw der Einfluss der fraglichen 1 BGH Urt v 29 1 2002 X ZR 231 00 JurPC Web Dok 168 2002 ia Streitz IT Projekte retten 170 Streitz IT Projekte retten 170 44 Koch IT Projektvertr ge rechtssicher gestalten Systemeigenschaft auf Wartungsfreundlichkeit und zu erwartende Performance wie in einem ERP Vertrag eines gro en Anbieters formuliert wurde Formuliert sind hier aber eben nur Anhaltspunkte jedoch weder eine m gliche Konfliktl sung noch auch nur ein Weg zu dieser Die Vereinbarung eines Eskalationsmanagements EM darf insbesondere nicht dazu f hren dass der Kunde an sich bestehende Erf llungs und oder Gew hrleistungsanspr che nicht mehr geltend machen kann Dies widerspr che schon den 307 Abs 2 Nr 2 bzw 309 Nr 8 a BGB Besonders ist zu beachten dass der Kunde auch nicht durch nachtr gliche individualvertragliche Vereinbarung im EM auf diese Rechte verzichtet Weiter sollte die Regelungskompetenz nicht einseitig beim Anbieter liegen der sonst festlegen k nnte wann welche Leistung von ihm erbracht wird vielmehr muss eine tats chl
29. grunds tzlich als vertragliche 4 Koch IT Projektrecht Rdn 254 1 Koch IT Projektrecht Rdn 255 S die bersicht in Computerwoche 51 52 2002 32 4 Kraus Computerwoche 8 2005 32 Koch IT Projektrecht Rdn 259 LG Heidelberg Urt v 1 9 1986 O 53 85 KfH I IuR 1987 S 108 Koch IT Projektvertr ge rechtssicher gestalten 33 Nebenpflicht einzustufende Einhaltung einer bestimmten Reaktionszeit innerhalb deren mit der Leistung also etwa mit der St rungsbeseitigung begonnen werden muss Kann bei besonderer Vereinbarung selbst zur Hauptpflicht werden so etwa wenn der Nachweis st ndiger Reaktionsbereitschaft f r den Kunden von wesentlicher Bedeutung ist etwa bei dem Einsatz von software gest tzten Flugsicherungssystemen Im Einzelfall ist zu pr fen ob die Einhaltung durch Vereinbarung einer Vertragsstrafe bei Nichteinhaltung gesichert werden sollte Auch bei vertragsgem er Erf llung der Reaktionspflicht ist aber noch keine rasche Beseitigung eines Fehlers gesichert Nur schwierig vorab im Vertrag fixierbar ist die maximal zul ssige Dauer der Fehlerbeseitigung da die Fehlerursachen und erforderlichen Beseitigungsma nahmen sehr unterschiedlich sein k nnen Vermeidbare Verz gerungen etwa weil Entwickler mit einem neuen Projekt besch ftigt sind k nnen Ersatzanspr che aus Pflichtverletzung bzw aus Verzug ausl sen Das generelle Festschreiben maximaler Fehlerbehebungsfristen in Kunden AGB kann jedenfal
30. in Tiemeyer Hrg Handbuch IT Management 321 337 Gadatsch IT Controlling in Tiemeyer Hrg Handbuch IT Management 359 376 2I Nach Tiemeyer Organisation und F hrung im IT Bereich in Tiemeyer Hrg Handbuch IT Management 321 338 haben nach einer Umfrage 80 aller befragten Unternehmen u a mit unzureichenden Ma nahmen um die Einhaltung von geschuldeten Spezifikationen sicherzustellen SE Gadatsch IT Controlling in Tiemeyer Hrg Handbuch IT Management 359 377 Koch IT Projektvertr ge rechtssicher gestalten 55 Durch Outsourcing auszulagernde Gesch ftsprozesse sollten vorher von Fehlern und Inkonsistenzen bereinigt standardisiert und optimiert werden Es gilt die Grundregel Source niemals ein Problem aus Au erdem ist nur bei standardisierten Prozessen ein Benchmarking und ein Wettbewerb m glich Besondere Sorgfalt bei der vertraglichen Planung und Absicherung ist allein schon angesichts des vielgestaltigen Leistungsbildes unabdingbar Dies beginnt bereits bei der Kostensch tzung bei der auch die Anlaufkosten f r das Outsourcing Projekt die Aufwendungen f r die Ver nderungsprozesse im Hause des Auftraggebers die erh hten Preise f r k nftige Erweiterungs und nderungsw nsche gegpnjber dem Auftragnehmer sowie die laufenden Zahlungen an diesen einzubeziehen und gegen die erwarteten Kosteneinsparungen gegenzurechnen sind Allgemein m ssen die erzielbaren nominellen Einsparungen durc
31. s ausf Lapp ITRB 2010 69 70 320 Denn ein befragbarer Kunde soll Teile der Spezifikation ersetzen www ordix de ORDIXNews 3_2007 Projektmanagement agile software entwicklung htmi 2 BleeklWolf Agile Softwareentwicklung 2008 148 Koch IT Projektvertr ge rechtssicher gestalten nicht besser in eine Lastenhefterarbeitung und Anforderungsspezifikation vor Beginn der Software Erstellung investiert werden sollte Dann muss der Kunde auch weniger mit Problemen durch seine innerbetriebliche Revision und das Controlling rechnen die bei Programmentwicklung ohne konkrete und in den Leistungsmerkmalen berpr fbare Zielvorgaben schnell in Schwierigkeiten geraten weil sie bei solcherart unsicheren Entwicklungsprozessen mit deutlich erh hten Risiken hinsichtlich Kostenexplosion oder Scheiterns des Projekts rechnen m ssen Vertragsrechtlich kann die intensivierte Kooperation die Mitwirkung des Kunden von einer sonst meist gegebenen Obliegenheit zu einer Mitwirkungspflicht aufwerten Hierf r reicht aber nicht aus dass der Kunde ein Interesse an ausreichender Leistungsspezifikation haben muss sondern es muss fallspezifisch ein besonderes Interesse des Anbieters an der Pro etca hiing etwa bei einem markterschlie enden Pilotprojet hinzukommen 2 3 5 Vertragsrechtliche Gestaltung agiler Softwareentwicklung a 651 BGB Witte hat a Bezug agiler Softwareentwicklung zu 651 BGB n her dargestellt Er zeigt zugleich das Dil
32. seinerzeit DM 19 900 00 zu bezahlen Ordentliche K ndigung bzw Nichtverl ngern des Vertrages ist zul ssig eine Verpflichtung des Anbieters noch f nf Jahre nach Ende nach Veran des letzten Exemplares sog Life Cycle Wartungsleistungen verf gbar zu halten wurde berwiegend kritisiert Ein W i amp echsel auf neue Release Punkt Null Versionen sollte zun chst unterbleiben da diese meist noch sehr fehlerbehaftet sind und allein schon die laufende Fehlerbeseitigung erhebliche zus tzliche Arbeitszeitkosten verursachen kann und oft auch alle Anpassungen Erweiterungen und Schnittstellen mit berarbeitet werden m ssen In gr eren Unternehmen sollten Releases vereinheitlicht werden Hierzu k nnen Verfahren automatischer Software Verteilung einzusetzen sein Propriet re Legacy Systeme sollten abgel st werden wenn ihr Support bzw st ndige individuelle Anpassungen an Updateslaufend hohe Kosten verursacht Allgemein sollten historisch gewachsene Anwendungslandschaften konsolidiert und etwa Spezialanwendungen mit niedrigem Beitrag zum Gesch ftserfolg durch Standardapplikationen ersetzt werden Server Konsolidierung zielt darauf ab Dienste Applikationen und Datenbanken auf ie hochverf gbare und dynamisch rekonfigurierbare Systeme zusammenzuf hren Kostenvorteile und eine Verbesserung der Datenqualit t Vereinheitlichung der Datenformate Beseitigen von Redundanzen vereinfachte Un bringt auch eine Kons
33. umso schwerer je st rker ein Scheitern des jeweiligen Projekts den Bestand den auftraggebenden Unternehmens gef hrden kann etwa weil eine notwendige Migration auf andere Systemplattformen oder die ben tigte Einf hrung oder nderung von unternehmenssteuernder Software scheitert Die Durchf hrung von IT Projekten muss deshalb von eine Risikomanagement begleitet werden notwendig ist eine Zuordnung der IT Risikoszenarien zu Projektthemen Zu Risiken von IT Projekten geh rt etwa die Entscheidung f r eine Technologie die sich ga Mani nicht durchsetzen kann und deshalb z B nicht langfristig unterst tzt wird Ein anderes Risiko kann sich aus der zeitlich parallelen aber unabgestimmt nebeneinander laufenden Durchf hrung von mehreren IT Projekten ergeben Hier muss ein Multiprojektmanageme Ziel und Aufgaben berschneidungen sowie Ressourcenkonflikte verhindern ee Lange Wall Picot Risikomanagement nach dem KonTraG 1 Rdn 66 Lange Wall Kindler Pahlke Risikomanagement nach dem KonTraG 1 Rdn 208 229 Lange Wall Kindler Pahlke Risikomanagement nach dem KonTraG 1 Rdn 230 8 Seibold IT Risikomanagement 81 Koch IT Projektrecht Rdn 621 4 Seibold IT Risikomanagement 18 Seibold IT Risikomanagement 28 w r 78 Koch IT Projektvertr ge rechtssicher gestalten Zu berwachunesbec rtugen Risiken geh ren auch Risiken aus dem Ausfall von IT Systemen durch vorhersehbare Systemfehler Angriffe aus
34. unter festgelegten Bedingungen das Zeitverhalten und das Verbrauchsverhalten der ben tigten Bedingungen nderbarkeit Aufwand der zur Durchf hrung von nderungen wie Korrekturen neue Funktionen notwendig ist Portierbarkeit Aufwand die Software in eine andere Umgebung zu verlagern dort zu installieren anzupassen oder Teile auszutauschen u Ebert Systematisches Requirements Management 36 7 Balzert Lehrbuch der Softwaretechnik Softwaremanagement 2 Aufl 2008 573 K Ebert Systematisches Requirements Management 33 Koch Requirements Management IT Rechtsberater 7 2009 160 162 4 Ebert Systematisches Requirements Management 17 Hindel H rmann M ller Schmied Basiswissen Software Projektmanagement 41 i Ebert Systematisches Requirements Management 98 Nach Ebert Systematisches Requirements Management 99 10 Koch IT Projektvertr ge rechtssicher gestalten Nichtfunktionale Anforderungen m ssen operationalisiert und damit messbar und bin r als nichterf llt oder erf llt entscheidbar gemacht werden damit ihre Einhaltung kontrollierbar und darlegbar ist bzw ein Mangel substantiiert behauptet werden kann Aus den Anforderungen erarbeitet der Anbieter eine L sung Die Anforderung beschreibt den zu erreichenden Nutzen Problemraum L sung hingegen wie dieser Nutzen exakt zu implementieren ist L sungsraum Dies entspricht in etwa der bisherigen Unterscheidu
35. werden Ist dieses nicht m glich l sst sich ersatzweise eine bindende Leistungsfrist vereinbaren bei deren ergebnislosem Ablauf der Kunde sofort zur cktreten oder Nichterf llungsanspr che geltend machen kann Von der Werkabnahme unabh ngige Abschlagszahlungen k nnen auch noch Bach Vertragsschluss vereinbart werden etwa bei l ngerdauernden Funktionspr fungen Manches Projekt kann durch eine Reduzierung des Projektumfangs gerettet werden Dies kann etwa durch Verzicht auf nicht zwingend erforderliche Anpassungen oder bestimmte organisatorische Ver nderungen erreicht werden Hierzu kann auch ein st rkeres Strukturieren von abzubildenden Gesch ftsprozessen in Richtung Standards geh ren um individuelle Anpassungen oder Erg nzungsprogrammierungen unn tig zu machen Auch ein Zentralisieren der Datenhaltung ist vorteilhaft Kostenintensive eigene EDV Inseln sollten m glichst aufgegeben und deren Aufgaben auf Dienstleister bertragen werden Weiter ist an eine Aufteilung in eigenst ndige zeitlich verschiebbare Projektteile zu denken Teilweise finden sich in Vertr gen rudiment re Bestimmungen zu einem Eskalationsmanagement Diese Regelungen helfen dann wenig wenn nur festgestellt wird dass die Vertragsparteien einen fairen Kompromiss herbeif hren sollen Das ergibt sich im Grunde schon aus 242 BGB wonach der Schuldner die Leistung so bewirken soll wie Treu und Glauben es mit R cksicht auf die Verkehrssitte
36. zul ssig sein Grunds tzlich erfolgt die n here Festlegung der Leistungskomponenten in der Abfolge Probleml sung Software gt Hardware Die erarbeitete Probleml sung legt also die auszuw hlende bzw zu erstellende Software fest und die Software ihrerseits die Hardware Dies sollte auch im IT Projektvertrag festgelegt werden Zu pr fen sind ben tigte Schnittstellen zu vorhandenen Anwendungen Aufr stbarkeit und Erweiterbarkeit Zu ber cksichtigen ist auch der vorhandene Datenbestand da sich sein Umfang auf da Ressourcenverbrauch und die anzuschaffende IT Infrastruktur auswirken kann ebenso die bernahme gr erer Altdatenbest nde Festzulegen sind bei objektorientierter Programmierung Klassen und Objektdefinitionen Das Pflichtenheft muss au erdem Betriebsbedingungen z Streitz IT Projekte retten 23 Das Pflichtenheft umfasst nach DIN 69901 die vom Auftragnehmer erarbeiteten Realisierungsvorgaben aufgrund der Umsetzung des Lastenhefts amp LG Trier Urt v 2 12 1992 5 O 1 92 CR 1995 221 f r das fachbezogene Pflichtenheft Streitz IT Projekte retten 41 Streitz IT Projekte retten 30 Streitz IT Projekte retten 39 Streitz IT Projekte retten 128 Koch IT Projektvertr ge rechtssicher gestalten 15 spezifizieren ebenso Qualit tsanforderungen Benutzeroberfl chen technische Produkt und Entwicklungsumgebungen Die Einbindung des Projekts in das Qualit tssicherungssy
37. 250 01 JurPC Web Dok 123 2003 Koch IT Projektvertr ge rechtssicher gestalten 19 Wenn der Anbieter die jeweils geschuldete Dokumentation insbesondere die Anwenderdokumentation bzw das ne nicht bergibt bzw liefert hat er eine Hauptleistungspflicht teilweise nichterf llt 2 und kann der Kunde einen Teil der Verg tung zur ckbehalten Kann der Kunde eine Software ohne Anwenderdokumentation berhaupt nicht nutzen z B nicht einmal laden wird sogar vollst ndige Nichterf llung anzunehmen sein und die Verg tung voll zur ckbehalten werden k nnen Die jeweilige Dokumentation muss vom Auftragnehmer mangels abweichender vorcinbaring grunds tzlich erst bei Abschluss der Arbeiten an der Software geliefert 1 werden Im Rahmen der Qualit tssicherung durch den Anbieter s dieser die Dokumentation parallel zur Software erstellen und nicht erst nachtr glich 4 Spezifische Probleme der Software Erstellung a Parametrisierung Durch Parametrisieren werden gewisserma en Einstellungen an im Programm bereits vorgegebenen Stellschrauben Parametern vorgenommen Man stellt so etwa die Anzahl der nen Nutzer ein Hier wurde ein Kaufvertrag mit Nebenleistungen angenommen Eingriffe in den Programmcode sind nicht erforderlich Diese Einstellungsarbeiten k nnen dennoch recht umfangreich sein etwa bei po hung f r unternehmenssteuernder Enterprise Resource Planning Software Auf diese Anpassungsleistung kann Werkvertragsrecht
38. 437 Nr 2 1 Fall 440 323 326 Abs 5 BGB wenn eine angemessene Frist zur Nacherf llung gesetzt wurde abgelaufen ist 323 Abs 1 BGB oder die Fristsetzung entbehrlich war 440 BGB e den Kaufpreis mindern 437 Nr 2 2 Fall 441 BGB e Neben R cktritt und Minderung kann der Kunde Schadensersatz 437 Nr 3 2 Alt 440 280 281 283 311 a BGB oder Ersatz vergeblicher Aufwendungen 437 Nr 3 2 Alt 284 BGB verlangen Der Anbieter haftet da er M ngelfreiheit als Teil Bo ulunEspiheht ee den 281 283 BGB e f r Mangre ian etwa Reparaturkosten mangelfeststellungsbezogene Gutachte ten verbleibender Minderwert Nutzungsausfall w hrend der Reparatur und Gewinnenigans i Betriebsst rung Betriebsausfallschaden durch verz gerte Inbetriebnahme e und aus 280 Abs 1 BGB f r Mangelfolgesch den also Sch den an anderen Rechtsg tern des K ufers Schadensersatz statt Leistung geht wie bisher Schadensersatz wegen Nichterf llung auf das positive Interesse weshalb der Kunde so zu a a ist wie er st nde wenn der Vertrag ordnungsgem erf llt worden w re e Bei Gattungssachen besteht eine verschuldensunabh ngige Einstandspflicht aus bernommenem Beschaffungsrisiko 280 Abs 1 276 BGB c Haftung aus Garantie Der Anbieter haftet verschuldensunabh ngig aus Garantie bernahme f r eine Beschaffenheit oder Haltbarkeit 443 BGB deren Verj hrung sich nicht ber 438 BGB bestimmt sondern
39. Anbieter nachpr fbaren Form dokumentieren dem Anbieter die zur Durchf hrung der erforderlichen Ma nahmen notwendige Zeit am System und Zugang zu diesem einr umen und bei der Leistungserbringung sopi erforderlich selbst mitwirken Vorf hren der Fehler Stellen von Personal etc 7 Nicht abschlie end gekl rt ist ob Software Pflegeleistungen dokumentiert werden m ssen F r Leistungen zur Hardw re Wartung wird dies bei Fehlen einer entsprechenden Vereinbarung verneint F r Software Pflege kann und muss das vereinbarungsunabh ngige Bestehen einer Dokumentationspflicht jedenfalls dann bejaht 46 OLG M nchen Urt v 22 11 1988 25 U 5810 86 BB Beilage 10 1990 9 or Koch Computer Vertragsrecht Rdn 970 Rn Koch Computer Vertragsrecht Rdn 970 OLG M nchen Urt v 24 4 1986 1 U 5742 85 CR 1988 S 38 34 Koch IT Projektvertr ge rechtssicher gestalten werden wenn Teile der Software weiterentwickelt werden Insoweit ist wie bei Neuentwicklungen auch eine Dokumentation geschuldet Aber auch f r sonstige Leistungen zur Software Pflege empfiehlt sich f r den Anbieter schon aus Beweisgr nden eine Dokumentation der erbrachten Leistungen Jedenfalls sollte die entsprechende Dokumentationspflicht vertraglich als Teil geschuldeter Qualit tssicherung der Software Pflegeleistung vereinbart werden Da Fehlerbeseitigungs und Entwicklungsarbeiten die Qualit t der Software verschlechtern k nnen sind die durchzuf hrenden Pr
40. GS Handbuch M 2 255 60 Koch IT Projektvertr ge rechtssicher gestalten h Zentrale Regelungspunkte in Outsourcing Vertr gen e Auswahl der auszulagernden Prozesse bzw Funktionen Diese sollten m glichst gut strukturiert und standardisiert sein e Mindestvertragslaufzeit Entweder durch K ndigungsregelungen oder durch ausdr ckliche Bestimmung der Vertragslaufzeit ist sicherzustellen f r welchen Zeitraum der Auftraggeber gesichert mit der Nutzbarkeit der Leistungen rechnen kann e Markt bliche Preise Leistungsabh ngiges Preismodell mit Bonus Malus System e Definition des Service Name Ansprechpartner Beschreibung Serviceort etc Bezeichnen gesch ftskritischer Prozesio Einhalten gesetzlicher und sonstiger Regelungen sowie einschl giger Normen amp e Transition Verlagerung der Leistungserbringung an den zuk nftigen Ort Anbieter RZ Festlegung der Ausgangsbasis Ist Zustand und Zielvorgabe Milestones Verg tung f r Transition Leistungen Abnahmeregelung e Service Levels Typisierte Leistungsumf nge bzw Leistungsparameter z B Kernservicezeiten Bereitschaftszeiten Erreichbarkeit Selbstl sungs und Fehlerraten Verf gbarkeit w hrend definierter Zeitr ume Wartungsfenster maximal zul ssige Ausfallzeiten Reaktion und wenn m glich Fehlerbeseitigungsfristen maximale Systemantwortzeiten jeweils als Mindeststandards Vorsorgema nahmen und Notfallpl ne gestaffelte Sanktipnen bei Verletzung tz B
41. HZ 58 332 339 Koch IT Projektvertr ge rechtssicher gestalten 47 e Der Kunde darf den Mangel selbst beseitigen 634 Nr 2 1 Alt 637 BGB und hierf r vom Anbieter einen Kostenvorschuss 637 Abs 3 BGB sowie Ersatz der erforderlichen Aufwendungen zu verlangen 634 Nr 2 2 Alt 636 BGB au er der Unternehmer hat die Nacherf llung zu Recht verweigert 637 Abs 1 BGB Diese Variante zur Beseitigung einer Leistungsst rung im Werkvertragsrecht wird aber zumeist nicht zum Tragen kommen da der Kunde auch bei Vorliegen von M ngeln nicht die Herausgabe verlangen darf und ohne diese zumeist keine M ngelbeseitigung am Programmcode durchf hren kann e Der Kunde kann vom Vertrag zur cktreten 634 Nr 3 1 Alt 636 323 326 Abs 5 BGB Damit ist das Projekt freilich durch Abbruch beendet und der Kunde kein St ck seiner Probleml sung n her Bei nur unerheblichen M ngeln ist der R cktritt ausgeschlossen 634 Nr 3 323 Abs 1 BGB die anderen Gew hrleistungsrechte bleiben unber hrt Scheitert der Anbieter mit der vertraglich geschuldeten Entwicklungsleistung muss er im Rahmen der r cktrittsbedingten R ckabwicklung auch erhaltene Lizenzgeb hren zahlen und darf er nicht seinen Entwicklungsaufwand in Rechnung stellen 22 e Der Kunde kann die Verg tung mindern 634 Nr 3 2 Alt 638 BGB Der Anbieter bleibt auch bei Minderung leistungsverpflichtet Der Kunde muss aber pr fen ob ihm mit einer Verg tungsminde
42. Hrg Softwaretechnik 1 Aufl 2000 Buchtal Eul Schulte Croonenberg Strategisches IT Management Wert steigern Leistung steuern Kosten senken 2 Aufl 2005 Dietrich Schirra IT im Unternehmen Leistungssteigerung bei sinkenden Budgets Erfolgsbeispiele aus der Praxis 2004 Ellenberger M ller Zweckm ige Gestaltung von Hardware Software und Projektvertr gen 2 Aufl 1984 Els sser ITIL einf hren und umsetzen Leitfaden f r effizientes IT Management durch Prozessorientierung 2 Aufl 2006 Hansen Neumann Wirtschaftsinformatik 1 Grundlagen und Anwendungen 9 Aufl 2005 Heilmann EtzellRichter IT Projektmanagement Fallstricke und Erfolgsfaktoren Erfahrungsberichte aus der Praxis 2 Aufl 2003 Heussen Richtige Vertragsgestaltung und Ablaufkontrolle bei EDV Projekten RWS Skript 259 1993 Heussen Hoh Controlling von EDV Projekten Vertragsgestaltung und Kostenkontrolle RWS Skript 233 1992 Hindel H rmann M ller Schmied Basiswissen Software Projektmanagement 2 Aufl 2006 H rl H user Service Level Agreements in IT Outsourcingvertr gen CR 2003 713 Intveen Lohmann Das IT Pflichtenheft CR 2003 640 Klotz Dorn Vertragsmanagement in der Informationsverarbeitung Handbuch f r Planung Durchf hrung und Controlling von IT Vertr gen 2006 Koch Handbuch Software und Datenbank Recht 2003 Koch Computer Vertragsrecht 6 Aufl 2002 Koreimann Grundlagen der Software Entwicklung 3 Aufl 2000 Liggesmeyer Software Qu
43. IT Projektvertr ge rechtssicher gestalten Auffallend ist schon dass in den Darstellungen zur agilen Softwareentwicklung das Thema Qualit tssicherung kaum eine Rolle spielt Agilit t scheint sich sogar umgekehrt poportional zur Qualit t zu verhalten Mit steigender Agilit t sinkt die Qualit t Gerade Stimmen aus der Praxis belegen dies deutlich Man will schnelle Ergebnisse haben Daf r opfert man Qualit t der Software Durch schnelles Entwickeln geht man das Risiko ein nicht alles ausgereift implementieren zu k nnen XP legt Wert auf den m glichst einfachen Entwurf nicht auf die Qualit t der Erstellungsprodukte Fraglich ist aber ob diese scheinbar etwas laxen Ans tze den Anbieter von vertraglicher Erf llungs oder gar Produkthaftung entlasten k nnen Dies wird grunds tzlich wohl zu verneinen sein wenn die Vertragsparteien nicht ausdr cklich etwas anderes vereinbart haben Da die Vereinbarung Kundenrechte wesentlich einschr nken kann wird sie wie ausgef hrt nur individualvertraglich wirksam getroffen werden k nnen Gegen ber gesch digten Dritten kann sich der Anbieter ohnehin nicht freizeichnen Damit haftet der Anbieter grunds tzlich auch bei Einsatz agiler Softwareentwicklungsmethoden aus Fehlern dieser Software und allgemein f r die Organisation und berwachung auch der Qualit tssicherung Insbesondere gegen ber gesch digten Dritten kann es nicht entlastend wirken wenn der Anbieter besonders a damit aber
44. IT Projektvertr ge rechtssicher gestalten Ein berblick ber die wichtigsten Regelungspunkte f r IT Projektvertr ge von Dr Frank A Koch Stand 2011 Rechtsanwalt Dr Frank A Koch Maximilianstr 54 80538 M nchen Tel 089 221 330 und 089 112 339 E Mail koch anwaltskanzlei koch de Website www anwaltskanzlei koch info Blog itrecht blogg de 2 Koch IT Projektvertr ge rechtssicher gestalten Einleitung Die Mehrzahl der IT Projekte Kann nicht zum geplanten Zeitpunkt im geplanten Budget und mit der spezifizierten Qualit t abgeschlossen werden Dies f hrt zu vermeidbaren und teilweise erheblichen Zusatzkosten und kann sogar das wirtschaftliche Schicksal des Unternehmens gef hrden das von einer bestimmten Anwendung und oder einem bestimmten Anbieter abh ngig ist Mit auf die jeweiligen IT Projekte passgenau zugeschnittenen und kontrollf higen Projektvertr gen k nnen diese Risiken deutlich reduziert werden Allerdings gen gt es hierf r nicht einfach Standardvertr ge aus Mustersammlungen zu bernehmen Die spezifischen Projektrisiken m ssen im Projektvertrag angemessen abgebildet werden Nur auf diese Weise kann die dauerhafte Nutzbarkeit der Applikation und ausreichender Schutz des betrieblichen IT Systeme vor Angriffen aus dem Netz erreicht werden Die Gesch ftsleitung muss ein unmittelbares Interesse an der richtigen Gestaltung der Projektvertr ge und der Projektsteuerung haben Vers umnisse k nnen n mlich zu
45. Kunde tats chlich ben tigt und sukzessive entsprechenden Change Requests abzuarbeiten Zu Beginn dieses Prozesses wissen beide Seiten noch nicht wohin sie die Kl rung f hren wird Dieser Kl rungsprozess nach Vertragsschluss und erfolgter Erstellung des Produkts wird nun bei Einsatz agiler Erstellungsmethoden in den Erstellungsprozess selbst vorverlagert Die Unsicherheit ber das Entwicklungsziel bleibt aber die gleiche Bei herk mmlicher Programmerstellung auf der Basis von Lastenheft und Spezifikation muss der Kunde nderungsauftr ge erteilen und diese nderungen voll verg ten hnlich tr gt der Kunde grunds tzlich auch bei agiler Entwicklung das Risiko der hieraus entstehenden Kosten f r das nachtr gliche Einf gen von Features Der Anbieter kann insoweit nicht das Erreichen eines bestimmten Leistungsziels versprechen und auch keinen Leistungserfolg schulden da dieses erst gemeinsam im laufenden Vertrag festgelegt wird Der Kunde kann seinerseits nicht vorab feststellen mit wievielen kostenausl senden Iterationen er rechnen muss Au erdem nen eine Entwicklung Feature by Feature ein einheitliches Design Henning Vogelsang Hrg Taschenbuch Programmiersprachen 2 Aufl 2007 507 vww ordix de ORDIXNews 3_2007 Projektmanagement agile software entwicklung html 30 69 7 Obendorf Szenariotechniken amp Agile Softwareentwicklung in Gross Hrg Mensch amp Computer 2007 Konf f r interaktive und ko
46. Leistungsst rungen im Projekt 1 Kundenrechte bei Anbieterverzug 2 Kundenrechte aus M ngeln der Anbieterleistung III Sonderf lle Beispiele typischer IT Projekte 1 Einf hrung von Enterprise Resource Planning Software 2 Outsourcing 3 Agile Software Entwicklung IV Compliance Haftung der Gesch ftsleitung aus unzureichender vertraglicher Absicherung und Kontrolle von IT Projekten V ITIL Best Practices und ISO Normen als Pr fma stab 17 18 19 22 23 25 28 29 32 36 36 40 44 44 45 50 50 52 64 76 78 4 Koch IT Projektvertr ge rechtssicher gestalten I Gestaltung von IT Projektvertr gen Das Schicksal von IT Projektvertr gen entscheidet sich weitgehend bereits bei den Vertragsverhandlungen Am falschen Ende spart hier wer nur allgemein formulierte Anforderungen vereinbart Erschwert wird hier n mlich die notwendige Pr fung ob der Anbieter die ben tigte Leistung auch tats chlich erbracht hat Der Kunde l uft au erdem Gefahr dass die von ihm nachtr glich als erforderlich festgestellte Konkretisierungen einzelner Leistungspunkte als teure Sonderw nsche behandelt werden oder sogar unausf hrbar sind Der Projektverlauf sollte in Abschnitte z V Modulerstellung aufgeteilt werden Milestones deren Erreichen getrennt kontrollf hig ist Aus dem Projektvertrag muss sich auch ergeben welche Nutzungsrechte dem Kunden an der Software zustehen sollen Hier werden in der auch fach Janwalt
47. Projektbeginn realistisch absch tzen und in seine Kalkulation einbeziehen Sie k nnen zwischen 30 und 50 des des gesamten Projektaufwands betragen Erf llt der Kunde ar Obliegenheit nicht kann der Anbieter selbst nicht in Leistungsverzug geraten eine Entsch digung verlangen 642 Abs 1 BGB und muss er nur f r grobe Fahrl ssigkeit und nat rlich Vorsatz haften 300 Abs 1 BGB Auch soll er bei Nichtliefern einfache Programmiervorgaben durch den Kunden berechtigt sein sich auf die UNION UNS gu beschr nken und Verg tung so zu verlangen als h tte er vollst ndig programmiert Projektkritische Mitwirkungshandlungen sollten bereits im Projektvertrag oder zur Entlastung der Vertragsdokumente in einem getrennten Dokument festgelegt werden das ausdr cklich im Vertrag als Anhang erw hnt und zum Teil des Vertrags gemacht wird F r den Anbieter wird eine unzureichende Beschreibung notwendiger Mitwirkungshandlungen sp testens dann misslich wenn er das Unterbleiben einer erforderlichen Mitwirkungshandlung des Kunden z B Pflichtenhefterstellung Altdaten bergabe zwecks Konvertierung r gen will Der Anbieter kann hier u U nicht eindeutig feststellen und in einem Prozess beweisen zu welchem Zeitpunkt der Kunde welche Mitwirkungsleistung h tte erbringen m ssen Der Anbieter sollte also darauf achten im Projektvertrag ein m glichst vollst ndiges und klar aufgeschl sseltes Obliegenheitsprogramm f r den Kunden zu definier
48. Projektrecht Rdn 672 80 Koch IT Projektvertr ge rechtssicher gestalten Levels SLs erm glichen Mit Kunden schlie t der Anbieter Service Level Agreements SLAs mit seinen Lieferanten Underpinning Contracts UCs Beide Vertragspartner m ssen die Service Levels gemeinsam definieren realisieren Leistungsmessungen und Transparenz sind von wesentliche Bedeutung Wesentliche Ran sind etwa Verf gbarkeit Ausfallzeit maximal tolerierbarer Datenverlust Anforderungen nach m e Service Level Anforderung seitens Business und Kunden verhandeln und vereinbaren e Monitoring und Berichten ber tats chlich erbrachte Service Level Leistungen SL Reporting e Laufende Verbesserung der Service Level planen und durchf hren Kontinuierlicher Vervesserungsprozess KVP Service Level Management und Support Funktionen koordinieren Durchf hren von Service Review Meetings mit Kunden Durchf hren des Service Verbesserungsprogramms berwachen der sich ndernden Anforderungen des Unternehmens und entsprechende Anpassung des Service Level Agreements e Anpassung des Operation Level Agreements OLAs und der Unterst tzungsvertr ge UCs mit externen Lieferanten e Erstellen und Pflege des Service Katalogs Messkriterien Abdeckungsgrad des IT Services Anzahl der Abweichungen zu den vereinbarten Service Levels Kundenzufriedenheit IT Prozesskosten ISO 20000 Die Kone pyon der Norm ISO 20000 soll am Beispiel des Change Manag
49. Status der Funktionsf higkeit eines Programmes oder Systems ist ein wenngleich auf einen Dauerzustand gerichteter Erfolg im Sinne des Werkvertragsrecht ebenso das Bereithalten qualifizierten jederzeit einsatzbereiten Personals da dieses Vorhalten zwingende Voraussetzung etwa f r ein schnelles Wiederherstellen der Funktionsf higkeit sein kann Bei Software Pflegevertr gen kann sich die Yeruagsie inne auf das Vorhalten qualifizierter Leistung Leistungsbereitschaft reduzieren Der Charakter der Pflegeverpflichtung als Dauerschuldverh ltnis steht der Anwendung von Werkvertragsrecht nicht entgegen Der werkvertragliche Erfolg wird hier da der Vertrag f r eine gewisse Laufzeit abgeschlossen wird gewisserma en zeitlich gestreckt und ist durch laufende Kontrolle herzustellen Ein werkvertraglicher Erfolg muss nicht begriffsnotwendig als zeitlich punktuell zu erbringender verstanden werden 2 Gerade bei Dauerschuldverh ltnissen und zudem bei den f r die EDV Nutzung wesentlichen Kontroll und Wartungsaufgaben setzt der Kunde besonderes Vertrauen in die Person bestimmter Mitarbeiter des Anbieters und ist eine bertragung der Leistungspflichten aus dem Wartungsvertrag auf Dritte Subunternehmer deshalb nur sehr eingeschr nkt m glich wenn der Kunde nicht zustimmt Die Vereinbarung einer entsprechenden bertragungsbefugnis in AGB wurde als unwirksam angesehen wpa sie formularm ig das Genehmigungserfordernis des 415 Abs 1 BGB erse
50. Urt v 9 10 2001 X ZR 58 00 a a O BGH Urt v 14 7 1993 VIII ZR 147 92 NIW 1993 2436f Nach Fischbach Lachmann Winnemuth Altdatenmigation wird oft untersch tzt Computerwoche 10 2002 26 Koch IT Projektvertr ge rechtssicher gestalten 21 e Projektkosten Der Kunde muss die voraussehbaren Projektkosten bereits bei Vertragsabschluss f r die gesamte vorausgesehene Nutzungsdauer kalkulieren Zu ber cksichtigen sind auch zus tzliche Beratungs Anpassungs vergleichbare Leistungen wie etwa Schulungen Wird die Abrechnung nach Aufwand vereinbart sollten die Vertragsparteien den voraussichtlichen Gesamtaufwand in einem Kostenvoranschlag verbindlich festlegen Der Anbieter sollte dann mit Erreichen der verschiedenen Projektstufen un Kostenvoranschlag fortschreiben und einen laufenden Ist Soll Vergleich durchf hren Bei Berechnung der Verg tung nach Aufwand sollte grunds tzlich Abrechnung auf der Basis von Stundenzetteln vereinbart werden in denen die jeweils erbrachte T tigkeit stichwortartig knapp aber doch nachpr fbar bezeichnet wird ebenso der beteiligte Mitarbeiter und die Stundenzahl Teilverg tungen sollten je nach Projektfortschritt etwa ankn pfend an Milestones f llig werden Hierdurch werden nicht nur Zahlungen verschoben sondern das Entstehen der ZA UNE pilieni eISEIERL sich oder entf llt wenn n mlich der Milestone nicht nachweisbar erreicht ist Fehlt eine Vereinbarung zur Verg tung im Projekt
51. V unkundige Kaufleute hinsichtlich des Umfangs der M ngelschilderung auf das dem Laien zumutbare Ma beschr nkt ist u Zum Problem aus 651 s S 194 OLG Celle Urt v 8 11 1985 11 U 212 84 IUR 1986 311 46 Koch IT Projektvertr ge rechtssicher gestalten Aus dem Umstand dass Software Fehler nur bei der Definition fehlerhafte Vorgaben dem urf Design Fehler oder bei dem Codieren auftreten k nnen nicht aber erst sp ter wurde zutreffend die Vermutung abgeleitet dass SON bereits bei Gefahr bergang mit Abnahme 644 640 BGB vorhanden sind Eine Ausnahme kann allerdings f r den Software Teil Dokumentation gelten in welche Anbieter auch noch nach bergabe der Programme Fehler einbauen k nnen wenn sie die Dokumentation erst im nachhinein erstellen Der Kunde kann aus nach Abnahme entdeckten und ger gten M ngel im Rahmen der gesetzlichen M ngelhaftung aus Werkvertrag e Nacherf llung verlangen 634 Nr 1 635 BGB Der Nacherf llungsanspruch hat Vorrang vor weiteren M ngelrechten Der Anbieter ist als Werkunternehmer anders als beim Kauf berechtigt zwischen M ngelbeseitigung und Nachlieferung zu w hlen 635 Abs 1 BGB Das Nacherf llungsverlangen und damit Nachlieferung wie M ngelbeseitigung stellt im Rahmen der Projektdurchf hrung einen Change Request dar den der Anbieter ohne Kosten f r den Auftraggeber durchzuf hren hat Hierdurch kann eine Terminsverz gerung auftreten die oft eine
52. W 2002 1159 1161 7 S etwa BAG NJW 1975 1378 BAG AP Nr 103 zu 613 a BGB best tigt durch EuGH NZA 1993 169 BAG NJW 1998 3138f NZA 1998 750 77 Gesetzesbegr BT Drucks 14 7760 20 WillemsenlLembke NIW 2002 1159 1160 Die Grunds tze lauten www agilemanifesto org alle Webseiten Angaben mit Visit Datum 20 1 2010 1 Individuals and interactions over processes and tools 2 Working software over comprehensive documentation 3 Customer collaboration over contract negotiation 4 Responding to change over following a plan Koch IT Projektvertr ge rechtssicher gestalten eigentliche Entwicklungsziel aus den Augen und die bersicht in Sammlungen von Nice to have Merkmalen b nderungen Das Risiko erh ht sich dadurch dass ganz im Gegensatz zum traditionellen Management der Softwareentwicklung nderungen auch in sp ten Entwicklungsphasen m glich und gew nscht sein sollen In der Praxis bleibt hier der Aufwand nur dann kalkulierbar wenn die nderungen lediglich abgegrenzte kleine Softwaremodule betreffen und nicht oder nur begrenzt mit R ckwirkungen Side Effects auf andere Teile des Codes zu rechnen ist Anderenfalls kann bereits der Aufwand f r das st ndige Wiederholen erforderlicher Tests und das Umschreiben bereits erstellter Dokumentationsteile exponentiell ansteigen da sich mit fortschreitendem Entwicklungsstand auch die M glichkeiten unvorhergesehener Nebenwirkungen dur
53. alit t Testen Analysieren und Verifizieren von Software2002 M ller Hengstenberg BVB Computersoftware Besondere Vertragsbedingungen f r die berlassung Erstellung Planung und Pflege von DV Programmem 3 Aufl 1992 M ller Hengstenberg Der Vertrag als Mittel des Risikomanagements CR 2005 385 M ller Hengstenberg Krcmar Mitwirkungspflicht des Auftraggebers bei IT Projekten CR 2002 549 Redeker Hrg Handbuch der IT Vertr ge Stand 2006 Koch IT Projektvertr ge rechtssicher gestalten 83 R hrborn Sinhart Application Service Providing juristische Einordnung und Vertragsgestaltung CR 2001 69 Schneiderlv Westphalen Software Erstellungsvertr ge 2006 Schoengarth Application Service Providing Vertragsgestaltung und Risiken insbesondere Betriebsausfallsch den 2005 Schreibauer Taraschka Service Level Agreements f r Softwarepflegevertr ge CR 2003 557 Schricker Loewenheim Urheberrecht 3 Auflage 2006 Seibold IT Risikomanagement 2006 S bbing Handbuch IT Outsourcing Rechtliche strategische und steuerliche Fragen 2002 Stahlknecht Hasenkamp Einf hrung in die Wirtschaftsinformatik 11 Aufl 2005 Streitz IT Projekte retten Risiken beherrschen und Schieflagen beseitigen 2004 Thewalt Der Softwareerstellungsvertrag nach der Schuldrechtsreform Rechtsnatur Leistungs bestimmung und M ngelhaftung 2004 Tiemeyer Hrg Handbuch IT Management Konzepte Methoden L sungen und Arbeitshilfen f r die Praxis 2006 Wen
54. altung dieser Ma st be wird regelm ig eine anbieterseitige Pflichtverletzung darstellen Jedoch bed rfen wohl Dokumentierung und Qualit tssicherung unter Dienstvertragsrecht in der Regel gesonderter Vereinbarung und Weisung Bei besonders intensiver Zusammenarbeit von Anbieter und Kunden wurde auch die Ananas einer beide Seiten umschlie enden BGB Gesellschaft als m glich angesehen 3 6 Indikationen und Kontraindikationen Betrachtet man die Praxis der agilen Softwareentwicklung n her so lassen sich einige Kriterien f r F lle formulieren in denen agile Verfahren nicht gew hlt werden sollten Zwingend dokumentierte Erf llung bestimmter IT Prozessabl ufe und Vorgaben f r die Qualit t und insbesondere f r die IT Sicherheit odpr gar lebenskritische Funktionen etwa in der Medizin oder Flug berwachung k rperliche Gegenst nde definierte Begriff der Verbrauchsg ter kann nicht durch ein deutsches Gericht analog auf unk rperliche Online bertragungen ausgeweitet werden 2 S n her Schneider ITRB 2010 18 19 Auer Reinsdorff ITRB 2010 f r Entwicklung unter Scrum 2 Womit ab diesem Zeitpunkt der Weiterentwicklung die Verweisung des 651 BGB ohnehin an Bedeutung verliert Auch wenn die Ausgestaltung Werkvertragsrecht folgt gelangt man nicht zu 651 BGB soweit keine Lieferung erfolgt sondern die Anpassungen on site beim Kunden durchgef hrt werden 8 Lapp ITRB 2010 69 70 auf gemeinsame Rechte
55. am Code abstellend Allerdings verbleibt die Kundenmitwirkung meist nur im Bereich der sukzessiven Festlegung von Anforderungen w hrend allein die Mitarbeiter des Anbieters Programmcodes erstellen oder im objektorientierten Bereich Klassen und Vererbungshierarchien spezifizieren BleeklWolf Agile Softwareentwicklung 2008 160 Koch IT Projektvertr ge rechtssicher gestalten E E terminlich qualit tsbezogen und vom Umfang her klar fixierte Projekte Langwierige Change Bee een und lange oder formalisierte Entscheidungswege beim Kunden Kein oder nur unregelm iger Kontakt zum Kunder oder Kunden die an Lastenhefterstellung gew hnt sind Keine M glichkeit der Arbeit vor Ort beim Kunden Lange Entwicklungs Build Zeiten In diesen F llen k nnen aber dennoch flexible Entwicklungsmethoden eingesetzt werden etwa im Modell des Rational Unified Process RUP Der RUP gliedert auch in Phasen und diese in Iterationen auf die definierte und berpr fbare Meilensteine darstellen und jeweils zu Artefakten Produktteilen als Modellelemente von CASE Werkzeugen f hren B3 RUP baut wesentlich auch auf den Elementen Anforderungsmanagement iterative Entwicklung Qualit tskontrolle Change bzw Konfigurationsmanagement und einer Sammlung von Best Practices auf und k nnte deshalb f r viele Kunden das Entwicklungsverfahren der Wahl sein Empfohlen wird die agile Entwicklungsmethodik in folgenden F llen M
56. an andere Betriebssystem Plattformen kann meist nur von dessen Anbieter durchgef hrt werden da nur dieser ber die Sourcen verf gt Ein solches Portieren geh rt i d R nicht zur bestimmungsgem en Benutzung der Software bedarf also wenn sie von Drittfirmen durchgef hrt werden soll der Zustimmung des Anbieters Das Portieren einer vom Besteller zur Verf gung gestellten Software folgt diese Anpassung Werkvertragsrecht w hrend bei berlassung einer nach den Kundenanforderungen angepassten Software Werkliefervertrag angenommen wird d Datenmigration Sollen im einem IT Projekt Altdatenbest nde bernommen werden bedarf dies grunds tzlich besonderer Vereinbarung ebenso das Erstellen von Konvertierungsprogrammen f r diesen Zweck Genau geregelt werden sollte wer f r f r die Erfassung der Altdatenbest nde und deren Migration auf eine andere Plattform zust ndig sein soll Vorgeschlagen wird folgendes Ablaufschema f r die Datenmigration Migrationsplanung im Rahmen der Projektplanung Erhebung Verifikation der Ausgangsdatenmodelle und der Datenqualit t Planung der Datentransformation Transformation in das Zwischenformat Bereinigung Abgleich Verifikation von Bereinigung Abgleich Transformation in die Zielformate Laden in die Testumgebung Laden in Produktivumgebung 76 BGH Urt v 9 10 2001 X ZR 58 00 CR 2002 93 JurPC Web Dok 252 2001 einen Werkliefervertrag i S v 651 BGB ablehnend BGH
57. anzuwenden sein Diese Werkleistung kann sogar den Schwerpunkt des Vertrages bilden Eine sch pferische Programmentwicklung erfolgt beim Einstellen der Parameter nicht aber sehr wohl beim Erstellen der Software mit solchen Parametern das Einstellen begr ndet als solches damit auch keinen Urheberrechtsschutz b Programmieren bei Standardapplikationen Auch bei Standardsoftware k nnen Zusatzfunktionalit ten individuell entwickelt werden z B bei SAP R 3 mit ABAP4 Derartige Entwicklungsprodukte k nnen im Einzelfall durchaus eigenst ndig urheberrechtlich schutzf hig sein also unabh ngig vom Schutz der Applikation auf der sie aufbauen jr BGH Urt v 4 11 1992 VIII ZR 165 91 NJW 1993 461 CR 1993 422 p BGH Urt v 20 2 2001 X ZR 9 99 DB 2001 1141 CR 2001 367 Ausf hrlich zur Qualit tsssicherung s Koch IT Projektrecht Rdn 277 2 LG N rnberg F rth CR 1992 336 338 Schneider v Westphalen Redeker Software Erstellungsvertr ge D Rdn 109 Stahlknecht Hasenkamp Einf hrung in die Wirtschaftsinformatik 213 Schneider v Westphalen Redeker Software Erstellungsvertr ge D Rdn 110 20 Koch IT Projektvertr ge rechtssicher gestalten Zu pr fen ist aber jeweils ob Applikationen mit derartigen Erweiterungen noch voll releasef hig d h trotz individueller Erg nzungen auch mit Folge Releases lauff hig sind c Portierung Die Portierung also Anpassung eines vorgegebenen Programms
58. aten an Wer erfasst und wer bearbeitet welche Daten Wer erh lt welche Auswertungen Das Mengenger st legt die ben tigte Dimensionierung von Speichermedien und Datenleitungen Datendurchsatz fest Erwartbare Zuw chse an Datenmengen sind zu ber cksichtigen Zum typischen Mengenger st geh ren a Stammdaten und nderungsdaten hierzu z B Kunden oder Lieferantenanschriften Artikel b Bestandsdaten Debitoren Kreditoren Sachkonten Lagerpositonen Arbeitszeitkonten c Bewegungsdaten z B Kundenauftr ge Bestellungen bei Lieferanten Lagerentnahmen zug nge Kunden Lieferantenrechnungen Zahlungseing nge ausg nge Mahnungen J Vorhandene IT Komponenten und Software Anwendungen soweit diese weiter verwendet werden sollen Pr fen Werden solche Legacy Systeme oder Programme in der neuen Applikation unbedingt ben tigt Welche Schnittstellen zu anderen internen Anwendungen und zu externen IT Systemen etwa der Finanzverwaltung bestehen bzw m ssen eingerichtet werden Wie kann man die Prozesse mit Hilfe von Software weiter optimieren Stahlknecht Hasenkamp Einf hrung in die Wirtschaftsinformatik 242 e Stahlknecht Hasenkamp a a O 228 Koch IT Projektrecht Rdn 13 Streitz IT Projekte retten 29 Streitz IT Projekte retten 28 6 Koch IT Projektvertr ge rechtssicher gestalten e Sind die Software Lizenzen im Unternehmen einheitlich und unternehmensweit geregelt Liegt f r jeden Arbeitsplatz
59. bilden deshalb die offizielle Freigabe einer endg ltigen Version wesentlich ie Schneider v Westphalen Software Erstellungsvertr ge C Rdn 82 f Koch IT Projektrecht Rdn 26 Schneider v Westphalen Software Erstellungsvertr ge C Rdn 18f Das Lastenheft beinhaltet nach DIN 69901 die Gesamtheit der Anforderungen des Auftraggebers an die Lieferungen und Leistungen eines Auftragnehmers das Pflichtenheft die ausf hrliche Beschreibung der Leistungen die erforderlich sind oder gefordert werden damit die Ziele des Projekts erreicht werden Die DIN Norm nimmt keine Zuordnung der Verantwortlichkeiten vor M ller Hengstenberg Der Vertrag als Mittel des Risikomanagements CR 2005 385 390 j Klotz Dorn Vertragsmanagement in der Informationsverarbeitung 85 u HindellH rmann M ller Schmied Basiswissen Software Projektmanagement 41 Koch IT Projektvertr ge rechtssicher gestalten 13 Der Beschreibungsumfang mis Lasten Pflichtenhefts im Sinne von fachlichem Feinkonzept muss umfassen e Ist Zustand Ausgangssituation e Soll Zustand Zielbeschreibung e Beschreibung der Schnittstellen z B zwischen Benutzer oder Nicht EDV Funktionseinheiten z B elektronischen Steuerungen jeweils mit Beschreibung von Bildschirmein und ausgaben von Inhalten der Information und von Formaten Listenausgaben Verarbeitungsregeln Pr fregeln Mengenger ste Sicherung der Daten zeitlicher Rahmen e Ergo
60. bringen ist best effort Die Durchf hrung geschuldete definierter nderungen Changes unterliegt grunds tzlich Werkvertragsrech ebenso diejenige von Erg nzungen oder Funktionserweiterungen oder vom Portieren von Software auf andere Plattformen das zumeist eine weitgehend eigenst ndige Entwicklung darstellt Die Leistung ist auf einen vertraglich definierten oder zumindest blichen Status der Funktionsf higkeit bezogen Die Wahl der Mittel zur Erhaltung oder Wiederherstellung dieses Status steht dem Anbieter unter Werkvertragsrecht frei Nimmt der Kunde vertragsgem die Kontrollen bzw sonstigen entsprechenden OLG Koblenz Urt v 17 2 1984 2 U 1286 82 IuR 1986 363 OLG Karlsruhe Urt v 28 2 1985 9 U 102 83 CR 1987 232 LG Hagen Urt v 26 4 1988 21 O 159 87 BB Beilage 15 1989 8 11 AG Hamburg Urt v 4 10 1988 35 C 444 88 CR 1989 1102f AG Hamburg Urt v 4 10 1988 a a 0 LG Berlin Urt v 22 5 2001 10 O 483 00 CR 2001 743 LG K ln Urt v 11 5 1984 90 O 14 84 DV R 3 234 3 Lejeune K amp R 2002 441 445 Hartmann Thier CR 1998 581 582 Koch IT Projektvertr ge rechtssicher gestalten 35 T tigkeiten selbst vor und unterst tzt ihn das Software Haus nur beratend wird insoweit grunds tzlich nur Dienstvertragsrecht anwendbar sein en f r das Vorhalten von Dienstleistungen ber den gesamten Vertragszeitraum Auch Instandhaltung als Aufrechterhalten eines vertraglich definierten
61. cher gestalten 67 Die aus zu erarbeitenden Testf llen wird der Code erstellt Entwicklung erfolgt in Mikro Iterationen Erzeugt wird eine ausf hrbare Spezifikation Regelm ig werden Wiederholungen von Programmteilen entfernt und sonstige Optimierungen durchgef hrt Refactoring die freilich als solche zu Fehlern f hren k nnen was durch automatisiert ablaufende Unit Tests vermieden werden soll Bei testgetriebener Entwicklung soll die M glichkeit bestehen eine in die Entwicklung integrierte Qualit tssicherung zu generieren jedoch bedarf dies grunds tzlich besonderer vertraglicher Vereinbarung Auch bleibt zu pr fen ob die allgemeinen Anforderungen nach DIN ISO 9001 und 20000 erf llt werden k nnen Moduls b Industrial XP Mehr Kontrolle des Projektverlaufs erm glicht die XP Variante Industrial XP IXP Sie nimmt Praktiken aus den anderen nachfolgend erw hnten Verfahren auf n mlich Projektskizze als einfaches Pflichtenheft Risikomanagement testgetriebenes Entwickeln ge getriebener Entwurf Identifikation der Entwickler mit Qualit tsarbeit Dadurch wird das Entwickeln langsamer aber deutlich besser kontrollierbar c Feature Driven Development Das Feature Driven Development strukturiert den Entwicklungsprozess gjire und stellt prim r auf Festpreiskonstellationen mit fixiertem Umfang ab Zuerst wird mit dem Kunden ein Gesamtmodell der gew nschten Anwendung entwickelt und auf er
62. chgef hrter nderungen auf bereits vorhandene Teile des Entwicklungsprodukts entsprechend mehren c Kommunikation Ein weiteres Prinzip verlangt es h ufig Software an den Kunden auszuliefern und mit diesem t glich in pers nlicher Kommunikation zusammenzuarbeiten Auf den Kunden kommt allein hierdurch ein erheblicher auch personeller Aufwand zu der durch die Vorteile des flexiblen Entwickelns zumindest ausgeglichen sein muss Auch kann er vor dem Problem stehen die Einigung ber bestimmte erst w hrend der Projektdurchf hrung ad hoc und nur m ndlich ge u erte Leistungsw nsche im Streitfall darlegen und beweisen zu m ssen 32 Formen Zu beachten ist dass e nicht die sondern verschiedene agile Entwicklungsmethoden gibt die einander in wichtigen Merkmalen etwa dem Verzicht auf das Dokumentieren teilweise ausschlie en weshalb die jeweils passende gew hlt werden muss Dies zu kl ren ist prim r Kundenrisiko wobei der Anbieter in zumutbarem Umfang hinweis aufkl rungs und beratungspflichtig sein kann 65 i Principles behind the Agile Manifesto Principle 2 Welcome changing requirements even late in development Agile Processes harness change for the customer s competitive advantage 4 Principle 3 5 Principle 6 3 Principle 4 F r eine ausf hrliche bersicht ber die Merkmale der verschiedenen agilen Entwicklungsmethoden s Schneider ITRB 2010 18 19 66 Koch IT Projektvertr
63. chnischen Angriffssicherheit des betrieblichen IT Systems nicht betroffen oder M ngelrechte nicht konsequent verfolgt kann dies die pers nliche Haftung der Mitglieder der Gesch ftsf hrung gegen ber der Gesellschaft begr nden Die Mitglieder der Gesch ftsleitung des auftraggebenden Unternehmens m ssen damit ein eigenes pers nliches Interesse daran haben ihrer m glichen haftungsweisen Inanspruchnahme bereits in der Phase der Vertragsverhandlungen mit Anbietern durch richtige Vertragsgestaltung und bei der Projektdurchf hrung durch richtige Kontrolle der Vertragserf llung vorzubeugen Die Steuerung von Risiken aus IT Projekten ist genuine Aufgabe der Gesch ftsleitung also etwa der Gesch ftsf hrer der GmbH oder des Vorstandes der AG 76 f AktG Diese Pflicht ergibt sich gegen ber Arbeitnehmern aus dem Arbeitsverh ltnis und den hierdurch begr ndeten Arbeitgeberpflichten gegen ber Kunden oder sonstigen Dritten aus Vertrag oder Deliktsrecht Der Gesch ftsf hrer muss auch hierbei die Sorgfalt eines ordentlichen Kaufmannnes walten lassen 43 Abs 1 GmbHG Vorst nde von Aktiengesellschaften bzw GmbH Gesch ftsf hrer haben bei ihrer Gesch ftsf hrung die Sorgfalt eines ordentlichen und gewissenhaften Gesch ftsleiters anzuwenden 93 Abs 1 S 1 AktG Das Erfordernis eine informierten Entscheidung verlangt dass die Gesch ftsleitung die erforderlichen Informationen beschafft und Risiken f r ein pr ventives Handeln rechtzeiti
64. den In der Anwenderdokumentation werden Einstieg in die und Nutzung der Anwendung beschrieben ohne diese Anwenderdokumentation ist meist keine Abnahmepr fung m glich In der Systemdokumentation werden technische Angaben zusammengefasst die f r Betrieb Wartung und Pflege relevant sind Die Betriebsdokumentation enth lt f r die berwachung und Aufrechterhaltung des Betriebs ben tigte Informationen In der Installationsdokumentation sollte der Auftragnehmer den Status nach Installation einschlie lich erfolgter Parametrisierung festhalten Oft wird ein am Bildschirm abrufbares Benutzerhandbuch installiert Bei Individualentwicklungen oder Anpassungen vorhandener Software oder von zu erwerbender Standardsoftware ist eine Entwicklungsdokumentation jedenfalls dann auch ohne besondere Vereinbarung geschuldet wenn der Auftraggeber z B ein anderes Software Haus die Software selbst weiterentwickeln oder zumindest pflegen will Besteht eine Verpflichtung des Anbieters zur Herausgabe des Quellformats Sourcen muss h eine Quellcode Dokumentation bzw Beschreibung mit bergeben werden Die Dokumentation ist ORT sondere Vereinbarung geschuldet der Anbieter ist insoweit vorleistungspflichtig OLG K ln Urt v 22 4 1994 19 U 145 93 CR 1994 737 Rahmenvertrag a Nach Streitz IT Projekte retten 54 S etwa Schneider v Westphalen Software Erstellungsvertr ge C Rdn 220 OLG Karlsruhe Urt v 16 8 2002 1 U
65. der Abnahmepr fung kann es schlie lich sinnvoll sein einen Lasttest durchzuf hren mit dem der Durchsatz der Daten mit den Massedaten im Dialogbetrieb etwa hinsichtlich der Antwortzeiten gepr ft wird Festgestellter Fehler der Anbieterleistung werden oft nach ihrer Schwere klassifiziert e Der Fehler verhindert die Nutzung der Projektergebnisse Beispiele Der Fehler verursacht einen Systemabsturz also einen Abbruch der Verarbeitung Eine fehlerhafte Dokumentation verhindert die Nutzung wesentlicher Funktionalit ten I Teilweise nach Schmidt in Redeker Hrg Handbuch der IT Vertr ge Abschnitt 1 5 Rdn 162 Koch IT Projektrecht Rdn 181 M ller Hengstenberg Wild CR 1991 327 329 mit dem Hinweis dass im Integrationstest meist nur wenige Haupttransaktionen getestet werden k nnen und die noch ausstehenden Testaktivit ten 20 40 des gesamten Entwicklungaufwands ausmachen k nnen A Streitz IT Projekte retten 60 26 Koch IT Projektvertr ge rechtssicher gestalten e Der Fehler behindert die Nutzung der Projektergebnisse Beispiele Zur Fortsetzung der Nutzung muss eine Fehlerumgehung erfolgen e Der Fehler hat keine Auswirkung auf die Nutzbarkeit der Projektergebnisse Beispiel Rechtschreibfehler in der Dokumentation oder in Quellcode Kommentaren Bei Verhinderung wie bei Behinderung der Nutzung kann nicht mehr von unwesentlichen M ngeln gesprochen werden und besteht keine Abnahmepflicht des Auftraggebers Umk
66. der in einer Anlage hierzu definiert sein ebenso das Testverfahren und die Testdaten die der Auftraggeber mangels abweichender Vereinbarung beibringen muss Den Auftragnehmer kann bese ael der Auswahl geeigneter Testdaten eine Aufkl rungs und Hinweispflicht treffen Anstatt der gemeinsamen Funktionspr fung wird bei gr eren Projekten h ufig auch ein Probebetrieb als Form der Abnahme vereinbart Auch diese Abnahmeform bedarf besonderer Vereinbarung da sonst der Probebetrieb leicht als produktive Nutzung zu beurteilen sein kann die die Fiktion einer erfolgten Abnahme ohne tats chliche Billigung begr nden w rde Klar und genau m ssen hier Dauer und Umfang des Probebetriebs festgelegt werden da erst nach Abschluss die Pflicht zur Erkl rung der Abnahme entstehen darf ebenso die Art des Tests die vom Anbieter in ihrem Ergebnis als bindend akzeptiert werden m ssen Das Ende des Probebetriebs sollte durch Erkl rung des Auftraggebers festgestellt werden F r die Durchf hrung einer Abnahmepr fung und erst recht eines Probebetriebs der Software muss dem Auftraggeber bereits ein Recht zur Nutzung dieser Software einger umt sein Fehlt eine Vereinbarung f r diese testbezogene Nutzung wird aber meist aus der Vereinbarung einer Abnahme Probebetriebsregelung zu schlie en sein dass diese Teil der jedenfalls bei Vertragsbeginn bestimmungsgem en Benutzung im Sinne von 69 d Abs 1 UrhG sein sollen Hierzu wird ein Vervielf ltigen
67. dlungen m glichst klar bezeichnen wenn er sp ter etwa deren Nichterbringung behaupten muss Nur in dem Umfang in dem eine solche pr zise Leistungsbeschreibung erfolgt nn die Vertragsparteien in einem Rechtsstreit eine vereinbarte Beschaffenheit behaupten 633 Abs 2 S 1 BGB und unter Beweis stellen der Kunde um deren Nicht oder Schlechterf llung zu behaupten der Anbieter demgegen ber um die vertragsgem e Erf llung darzulegen w hrend Beweisrisiken bez glich der vertraglichen vorausgesetzten Verwendung 633 Abs 2 S 2 Nr 1 BGB und erst recht bbzlich der gew hnlichen Verwendung 633 Abs 2 S 2 Nr 2 BGB auftreten k nnen Lastenheft und IT Pflichtenheft als Formen der Leistungsbeschreibung Das Lastenheft enth lt grunds tzlich die fachlichen Anforderungen und ist vom Kunden zu erstellen Das IT Pflichtenheft enth lt die vom Anbieter erstellte DV technische L sung des fachlichen ARWENCEBESPIOB N ZU beachten ist dass die Rechtsprechung das Lastenheft als Pflichtenheft bezeichnet w hrend in der IT Praxis die fachlichen Anforderungen im Lastenheft H die DV technische L sung aber im Pflichtenheft erfasst werden Die endg ltige Fassung des Lastenhefts sollte wie auch sp ter die des IT Pflichtenhefts schon aus Ip serunden als solche bezeichnet und von beiden Seiten unterzeichnet werden Die Vertragsparteien m ssen beachten dass Lasten und Pflichtenheft die Basis f r die sp tere Fan une
68. edem gr eren Projekt haben sich Templates und Entwicklungsdokumentationen vergr ert Verkleinert und vereinfacht werden sie nie automatisch 309 BGH Urt v 4 11 1992 VIII ZR 165 91 CR 1993 203 1 Redeker IT Recht 4 Aufl 2007 Rdnr 315 Koch Computer Vertragsrecht 7 Aufl 2009 S 78 Koch IT Projektvertr ge rechtssicher gestalten kann durch einen ausreichend konkreten Hinweis und eine Aufkl rung ber die Auswirkungen des Fehlens einer Dokumentation in den Vertragsverhandlungen geschehen hierf r wird der Anbieter freilich beweispflichtig sein Denkbar ist vertragliche Vereinbarung eines Verzichts auf die Dokumentation Hierbei sollte ausdr cklich geregelt sein ob sich dieser Verzicht auf jede Art von Dokumentation bezieht oder etwa nur auf die Entwicklungsdokumentation Selbst dann kann eine solche Regelung problematisch sein wenn sie im Formularvertrag erfolgen soll Hierin Kann n mlich eine unangemessene Benachteiligung des Kunden i S v 307 Abs 2 Nr 2 BGB durch die Einschr nkung eines wesentlichen Rechts n mlich eines zumindest teilweisen Nichterf llungsanspruchs zu sehen sein Der Anbieter wird deshalb eine individualvertragliche Regelung vorziehen Hier l uft er freilich das Risiko den Verzicht nicht umfassend genug oder zu intransparent zu formulieren sodass er nicht beweisbar ist Als Alternative bleibt anbieterseits die Leistungsbeschreibung so zu fassen dass ein rasches und nicht durc
69. ehrschluss aus 640 Abs 1 S 2 BGB eits bei einzelnen solchen M ngeln kann eine Abnahme nicht mehr verlangt werden In vielen F llen ist schon aus Zeitgr nden keine vollst ndige Abnahmepr fung s mtlicher Funktionen m glich Hier wird unter Bezug auf eine 80 20 Regel geraten jedenfalls TE 20 der Funktionen zu pr fen die 80 des Produktivbetriebs abdecken Hierzu m ssen freilich die Kernfunktionalit ten in der Abnahmespezifikation komplett erfasst werden F r die restlichen 80 der Funktionen tritt mangels Kenntnis des Bestellers kein Verlust der M ngelrechte ein arg e 640 Abs 2 BGB Jedoch sollte im Projektvertrag oder im Anhang hierzu geregelt sein dass nur 20 der Funktionen gepr ft werden k nnen und diese in einem Pr fprotokoll auch bezeichnet werden Im Abnahmeprotokoll sollte au erdem vorsorglich gem 640 Abs 2 BGB erkl rt werden dass der Auftraggeber sich seine M ngelrechte bez glich der nicht gepr ften 80 der Funktionen vorbeh lt Vorsorglich ist auch vertraglich zu regeln dass hinsichtlich dieser 80 eine m gliche ber 651 BGB anzuwendende kaufm nnische Untersuchungs und R gepflicht nicht eingreift und f r die 20 Kernfunktionen die Pr fliste und die Abnahmetermine auch insoweit verbindlich sind Bei Pen uns von Abweichungen sollten folgende Merkmale protokolliert werden Datum Zeit Beteiligte Personen Unterscheiden zwischen Teilabnahme und Endabnahme Fehlen der Dokumentat
70. eine g ltige Lizenz vor K nnen ungenutzte Lizenzen gek ndigt werden e Gibt es nicht ben tigte Rechner Lizenzen oder Installationen e Ist das Patch Management zentral organisiert Der Kunde muss beachten dass sich vorhandene also ungel st gebliebene Probleme auf der fachlichen Ebene nicht durch IT Einsatz l sen lassen sondern nur verlagert werden L uft beispielsweise ein Gesch ftsprozess zu langsam ab ist er nicht ausreichend transparent organisiert oder zu kostentr chtig so hilft seine Abbildung in eine IT Anwendung kein St ck weiter Vor Beginn der Soll Analyse und Erstellung von Lastem und Pflichtenheft m ssen erforderliche Anpassungen von Gesch ftsprozessen durchgef hrt werden Erst dann ist die Basis Konsolidiert von der aus das IT Projekt in Angriff genommen werden kann Soll Analyse In der grunds tzlich vom Kunden durchzuf hrenden Soll Analyse ist darzulegen welche Aufgaben zuk nftig ben tigt werden auf welche Weise diese zu erledigen sind und welches Mengenger st voraussichtlich ben tigt werden wird Hierbei ist vorab zu pr fen ob und gegebenenfalls welche Gesch ftsprozesse optimiert werden oder u U entfallen k nnen Aufgetretene Probleme z B zu ungenaue Formulare Fehlerquellen bei Ergebnissen oder Engp sse etwa bei gleichzeitiger Bearbeitung verschiedener Auftr ge durch mehrere Mitarbeiter Sto belastungen sind zu ber cksichtigen ebenso Effizienzm ngel etwa mehrfaches Erfassen
71. einer pers nlichen Haftung der Mitglieder der Gesch ftsleitung gegen ber dem Unternehmen f hren Compliance Das gilt bereits dann wenn und soweit das erforderliche berwachungssystem zur Risikofr herkennung nicht oder nicht ausreichend eingerichtet und angewendet wurde Zu diesen Risiken geh ren auch grunds tzlich vorhersehbare Probleme die aus vom Scheitern bedrohten IT Projekten resultieren Das vorliegende Skript fasst die wichtigsten Regelungspunkte f r die rechtssichere Gestaltung und Steuerung von IT Projekten zusammen Es gr ndet auf der Darstellung des Verfassers IT Projektrecht Wiss Springer Verlag 2007 in der die Regelungspunkte und Problemstellungen ausf hrlicher erl utert werden Die vorliegende Zusammenfassung soll f r die Vertragspraxis eine erste Orientierung geben Eingef gt wurde neben Aktualisierungen ein ausf hrlicher Abschnitt zur agilen Programmierung Koch IT Projektvertr ge rechtssicher gestalten Inhalt I Gestaltung von IT Projektvertr gen Anforderungsanalyse Requirement Management Abschluss des Projektvertrages Dokumentation der Anbieterleistung Spezifische Probleme der Software Erstellung Change Management Mitwirkung des Auftraggebers Projektabnahme Rechte an Programmformaten Service Level Agreements 10 Hardware Wartung und Software Pflege in IT Projekten 11 Regelungen zur Projektbeendigung 12 Vertragsanpassungen 13 Sanierung von IT Projekten II
72. ektabbruch etwa durch jederzeit m gliche K ndigung durch den Besteller 649 BGB oder R cktritt 634 Nr 3 323 326 Abs 5 BGB bestehen nachvertragliche Pflichten beider Vertragsparteien aus 280 BGB deren Umfang nur im Einzelfall notfalls unter Heranziehen von 242 BGB bestimmt werden kann So muss der Anbieter Unterlagen und Datensicherungen zur ckgeben die er vom Kunden erhalten hat und die dieser weiterhin ben tigt Dritten darf der Anbieter dieses Material auch nachvertraglich nicht zug nglich machen 12 Kostensenkungen verhandeln Bei Wechsel von Hardware und insbesondere Eneset ten sollte auf Standardisierung und gut verhandelten Einkauf geachtet werden Der EA neuere Technologien macht die IT nicht notwendig in jedem Fall leistungsf higer entscheidend ist der jeweilige Einsatzzweck Beispiele Wechsel zu Duo Core Prozessoren bei einfachen Textverarbeitungsanwendungen bringt fast keine Beschleunigung wenn die Geschwindigkeit der Texteingabe durch den Menschen unver ndert bleibt Bei Software ist auf die M glichkeit der Wiederverwendbarkeit von Software teilen zu achten Template Verfahren deren Aussch pfen allerdings zur Konsequenz hat dass bestimmte Softwareteile z B Klassenbibliotheken fr her f r andere Kunden entwickelt und nun im aktuellen Auftrag nur wiederverwendet werden und insoweit 2 Ausf hrlich s Koch IT Projektrecht Rdn 355 ff Dietrich Schirra IT im Unternehmen 4 Shipto
73. ement erl utert Ziel ist dass alle Changes in kontrollf higer Weise gepr ft gebilligt implementiert und berpr ft werden Alle Changes sind nach Implementation auf Erfolg In ITIL werden Service Level Agreements definiert als A written agreement or contact between the customers and the IT provider which documents the agreed service levels for an IT service Typically it will cover service hours service availability customer support levels throughputs and terminal response time restrictions functionality and the service levels to be provided in a contingency It may also include security and accounting policy zit nach Victor G nther Optimiertes IT Management mit ITIL 107 Els sser ITIL einf hren und umsetzen 147 5 BocklMaceklOberndorfer Pumsenberger ITIL Zertifizierung nach BS 15000 1SO 20000 77 3 www itil org itil_071 html 8 Ausf hrlich Koch IT Projektrecht Rdn 728 Koch IT Projektvertr ge rechtssicher gestalten 81 oder Fehlschlagen zu berpr fen post implementation review ISO IEC 20000 2 Nr 9 2 2 Alle Changes sind nach ISO IEC 20000 1 Nr 9 2 3 Abs aufzuzeichnen und zu klassifizieren etwa als dringend urgent Notfall emergency major wesentlich minor geringf gig Sie sind abzustimmen zu berpr fen und in kontrollierter Weise zu implementieren Nr 9 2 5 Abs 82 Koch IT Projektvertr ge rechtssicher gestalten Literatur Schriften des BSI Bundesam
74. emma auf dass sich eine auf Werkvertragsrecht abzielende immer genauere Leistungsspezifikation und Pflichtenkonkretisierung immer weiter vom flexiblen Ansatz agiler Entwicklung entfernt Im Einzelfall zu pr fen ist freilich ob die etwa bei XP erforderliche Entwicklungsarbeit vor Ort beim und mit dem Kunden auf dessen Systemen berhaupt mit einer Lieferung 1 S v 651 Satz 1 BGB verbunden ist Geliefert wird hier allenfalls eine Basisfunktionalit t die dann mit dem Kunden iterativ angepasst wird Eine solche nderung des_ beim Kunden installierten Vorprodukts f llt nicht mehr unter 651 BGB E Auch das laufende Sammeln von Testf llen und entsprechende Dokumentieren kann als solche nderung anzusehen sein Auch greift 651 BGB nicht ein wenn die Mitarbeiter des Anbieters zwar nicht vor Ort beim Kunden t tig werden aber ihm ihre u U t glichen Releases online zur Pr fung a Zustimmung bertragen da dies keine Lieferung i S v 651 BGB darstellt 22 hnlich i E Redeker IT Recht 4 Aufl 2007 Rdn 417 Witte ITRB 2010 44 Koch Computer Vertragsrecht 7 Aufl 2009 S 475 73 2 Koch Computer Vertragsrecht 7 Aufl 2009 S 472 Schweinoch CR 2010 1 h lt eine Lieferung auch online f r m glich dies ergebe sich aus BGH Urt v 18 10 1989 VII ZR 325 88 CR 1990 24 Diese Entscheidung betrifft aber nur die zumal entsprechende Anwendung von Kaufrecht vom AbzG nicht 651
75. en Aus ihm muss der Kunde erkennen k nnen wann f r ihn welche Pflichten aktuell werden Dies dient zugleich zur auch vertraglich vom Anbieter geschuldeten Aufkl rung und Beratung des Kunden der z B a A und eine Abkl rung mit dem Betriebsrat terminlich abstimmen muss Der Anbieter muss die jeweils erforderliche Mitwirkung rechtzeitig abrufen z B eine Information ber Gegebenheiten im Auftraggeberbereich und bei erkennbarer Unklarheit oder Unvollst ndigkeit beim Kunden nachfragen Vorgeschlagen wird dass ner des Auftraggeber regelm ig ber den Projektfortschritt unterrichtet Zwingend erforderlich sind solche Berichte wenn der Auftragggeber zu einer bestimmten Mitwirkungshandlung oder einer Teil Abnahme aufzufordern ist x Koch Computer Vertragsrecht Rdn 669 x Streitz IT Projekte retten 56 K BGH Urt v 23 1 1996 X ZR 105 93 CR 1996 467 BGH Urt v 13 7 1988 VIII ZR 292 87 CR 1989 102 mit Anm K hler CR 1989 105 NJW RR 1988 1396 OLG Stuttgart Urt v 29 3 1994 6 U 203 93 CR 1994 222 Leitsatz BGH Urt v 13 7 1988 a a O 102 104 Koch IT Projektrecht Rdn 174 ai Streitz IT Projekte retten 63 Koch IT Projektvertr ge rechtssicher gestalten 25 bersicht ber wichtige typische kundenseitige Mitwirkungshandlungen e bermitteln aller ben tigten Informationen an den Anbieter etwa ber vorhandene Systemumgebung Schnittstellen Unternehmensabl ufe Gesch ftsproze
76. en der Verg tung 641 BGB bergang der Verg tungsgefahr 644 645 BGB Verj hrungsbeginn f r M ngelrechte 634 a BGB Verlust des Rechts auf Nachbesserung bekannter nicht vorbehaltener M ngel 640 Abs 2 BGB Entfallen nichtvorbehaltener Vertragsstrafen 341 Abs 3 BGB e Umkehr der Beweislast f r M ngel 8 Rechte an Programmformaten Bei Standardsoftware schuldet der AN ne die berlassung des ausf hrbaren Codes nicht aber der Sourcen Quellformate wenn nichts Abweichendes vereinbart wurde Bei voll verg teter Entwicklung von Individualsoftware erwirbt der Kunde grunds tzlich alle Nutzungsrechte am gesamten tanz also auch an Sourcen insbesondere bei geplanter eigener Weitervermarktung Solche Individualentwicklung ist aber heute eher die Ausnahme Anbieter verwenden insbesondere bei objektorientierter Programmentwicklung vielmehr bestimmte Software Teile z B ausf hrbare Programme aus anderen Auftr gen weiter Software Wiederverwendung Au erdem nehmen sie an komplexen Softwaresystemen etwa zur Unternehmenssteuerung oft nur Anpassungen vor Ausschlie liche Nutzungsrechte wird der Kunde hier nur an den individuell entwickelten oder angepassten Software Teilen erwerben k nnen an der jeweiligen Gesamtsoftware aber nur einfache Nutzungsrechte da der Anbieter seine Software sonst nicht Vet k nnte sondern immer wieder von Grund auf neu schreiben m sste Die Anbieterverpflichtung zur Heraus
77. engstenberg Risikomanagement in DV Projekten CR 1999 789 790 m w N 42 Koch IT Projektvertr ge rechtssicher gestalten b Projektsanierung Das Sanieren eines IT Projejtes setzt voraus dass die Ursache f r das drohende Scheitern identifiziert der verbleibende Gestaltungsteeuaum eingesch tzt und das M gliche realisiert wird ohne die Fehler zu wiederholen Ursachen des drohenden Scheiterns nach Streitz die Schieflage des Projekts sind etwa das Nichterreichen von Zielen die mangema yK zeptanz durch die Benutzer sowie Termins und Kosten berschreitungen genannt wobei freilich vorausgesetzt ist dass berhaupt konkrete Leistungstemine und Teil Verg tungen vereinbart sind Fehlen Terminsvereinbarungen m ssen zun chst angemessene Leistungsfristen gesetzt werden Von erheblicher Bedeutung ist aber auch Boll eine unzureichende Kommunikation zwischen IT Abteilung und Gesch ftsleitung Die Sanierung eines Projekts sollte mit der Feststellung des erreichten Projektstatus beginnen Dieser ist mit den Vorgaben aus dem Pflichtenheft f r den Soll Status zu vergleichen wobei die en Abweichungen nach ihrem Auswirkungsgrad klassifiziert werden sollten Wurde bereits mit dem Produktivbetrieb begonnen ist meist der Weg zur ck zur UESPTUNSLICHE L sung verbaut da eine R ckmigration der Daten nicht vorgesehen bzw m glich ist Die einzelnen Projektphasen sollten zeitlich und inhaltlich klar voneinander abgegrenzt und Rear
78. erater 7 2009 160 161 Balzert Lehrbuch der Softwaretechnik Softwaremanagement 2 Aufl 2008 568 Ausf hrlich s CMMI Website www sei cmu edu cmmi Ebert Systematisches Requirements Management 32 m w N SPICE steht f r Software Process Improvement and Capability Determination und soll der Bewertung der Software Entwicklung dienen Balzer Lehrbuch der Softwaretechnik Softwaremanagement 2 Aufl 2008 5829 Balzert Lehrbuch der Softwaretechnik Softwaremanagement 2 Aufl 2008 571 Koch IT Projektvertr ge rechtssicher gestalten 9 spezifisch auf Software zugeschnitten ist Der Kunde sollte bei der Auftragsausschreibung einen m glichst hohen Reifegrad der Organisation des zu beauftragenden Anbieters zugrundelegen denn je h her der Reifegrad ist desto geringere Schwankungsbreite weisen die erzielten Ergebnisse im Verh ltnis zu den Soll Ergebnissen auf Anzuraten ist eine entsprechende fallspezifische Kosten Nutzen Kalkulation Das Requirements Management ist erst ab Reifegrad 3 organisiert ee erwartbar aber Voraussetzung f r die Verfolgbarkeit von Anforderungen RM ist grunds tzlich auf das jeweilige gesamte en mit dessen Umgebung etwa im Netz ausgerichtet und nicht auf Software beschr nkt Im RM werden Anforderungen und L sungen unterschieden Alle Anforderungen d h Gesch fts Prozessanforderungen und funktionale wie nichtfunktionale Produktanforderungen m ssen definiert spezifiziert und verifiziert
79. ereit ist Dies ist typischerweise ein werkvertraglich einzuordnender Leistungserfolg Auch Dateitransfer kann Werkvertragsrecht unterliegen wenn die Strecke zu minimieren und das Volumen der zu bertragenden Daten zu maximieren ist Denkbar ist aber auch die Miete von RZ Leistungen und zwar immer dann wenn der Kunde selbst einen Teil des RZ zur Nutzung teilweise berlassen erh lt In Outsourcing Vertr gen ist meist eine Vielzahl von Einzelleistungen zu regeln Sie k nnen unterschiedlichen Vertragstypen folgen z B Dienstvertragsrecht bei begleitender Beratung ohne Zielvorgabe Diese Einzelvertr ge die oft die Form von Leistungsscheinen haben aber eigenst ndige Vertr ge sind lassen sich mit einem Rahmenvertrag b ndeln der gewisserma en die allen Einzelvertr gen gemeinsamen Regelungen vor die Klammer zieht z B zu Change Management Gew hrleistung und Haftung 4 OLG M nchen Urt v 22 4 1999 CR 1999 484 F r alle etwa Heymann CR 2000 23 26 7 Zur Zuordnung s oben S Koch IT Projektvertr ge rechtssicher gestalten 57 e Ausschreibung von Outsourcing als IT Projekt F r die Ausschreibung von Outsourcing Projekten im nicht ffentlichen d h Pay awanseHal leer n pereici werden folgende vertragsverhandlungsvorbereitende Stufen unterschieden e Das Versenden eines Request for Information RfI basiert auf einer Anforderungsanalyse und soll als erstes Anschreiben Dienstleister ber ein Vorhaben des Ab
80. erf gbar war zu der Zeit in der der Dienst theoretisch h tte verf gbar sein k nnen Braun Die Zul ssigkeit von Service Level Agreements 9 1 Bl selPechardscheck CR 2002 785 787 i Bei Reaktionszeiten ist zu differenzieren ob die Reaktion im Bereich Hotline User Help Desk Support etc erfolgt H rl H user CR 2003 713 715 Diekmann Pickert Computerwoche 46 1991 61 62 31 TowlelBruggeman CRi 2002 75 77 1 Koch IT Projektvertr ge rechtssicher gestalten 31 erwarten kann Die einzelnen Stufen sollten im Vertrag m glichst klar und vollst ndig vertraglich a ebenso die geschuldeten maximalen Zeiten f r die St rungsbeseitigung Kunden k nnen selbst Verfahren nutzen um im Rahmen eines sog User prientierten Servece Level Management SLM die Verf gbarkeit zu kontrollieren e Tracing des Netzverkehrs sog Network X Ray e Screen Capture Messung am Arbeitsplatz e Record Replay Messung anhand definierter MER und e Instrumentierung der Applikation mit Agenten Zu pr fen ist ob und welche pr ventiven proaktiven Kontrollen im System m glich sind etwa laufendes Monitoring von Service Levels automatische Informations bergabe an den Help Pisk Performance und Verf gbarkeitsprognosen automatische Fehlerkorrekturen etc Festgelegt werden sollten auch die jeweils zu erf llenden Mitwirkungsobliegenheiten des Auftraggebers so etwa bez glich des Bereitstellens
81. erg Graf v Westphalen DV Projektrecht 1994 128 1 OLG Bamberg Urt v 1 10 1985 5 U 57 85 DV R 3 34 ff gt OLG M nchen Urt v 22 11 1988 25 U 5810 86 CR 1989 283f das die Beweislast f r den Schaden z B Head crash die Pflichtverletzung und deren Kausalit t dem Kunden zuordnet 159 1 36 Koch IT Projektvertr ge rechtssicher gestalten 11 Regelungen zur Projektbeendigung a Parallelbetrieb von alter und neuer Anwendung Beendigungsunterst tzung Oft laufen alte und neue Anwendung eine Zeitlang parallel Dies ist etwa bei der Konvertierung von Altdaten auf das neue System der Fall aber auch bei zun chst nur probeweiser Nutzung des neuen Systems bzw der neuen Anwendung Lizenzrechtlich kann hier zu kl ren sein ob die bisherige Software nicht nur zur produktiven Nutzung benutzt werden darf sondern auch zu dem Zweck etwa einer Datenmigration auf andere Systeme Nach dem Lizenzvertrag k nnte hier der Bereich der zul ssigen bestimmungsgem en Benutzung berschritten sein Um diese Rechtsunsicherheit zu vermeiden sollte der Anbieter im IT Projektvertrag zur Beendigungsunterst tzung verpflichtet werden Hierzu geh rt die Zustimmung zu Nutzungsl ufen der Software zum Zweck der Migration zu anderen Systemen bzw auf andere Plattformen aber auch Herausgabe kundenseits ben tigter spezifischer Datenformate und ausf hrbarer Programmteile z B Klassenbibliotheken b Pflichten bei Projektabbruch Auch bei Proj
82. erst begonnen werden wenn die Vorphase beendet und abgenommen ist Auch sollte die jeweilige Teilverg tung erst mit erfolgter Abnahme f llig werden Soweit durchsetzbar sollten Vertragsstrafen f r das anbieterseitige berschreiten von Zeitvorgaben vereinbart werden Hier muss freilich intern sichergestellt werden dass Verz gerungen nicht durch Kundenw nsche verursacht wurden die der Anbieter nicht vorhersehen musste Zun chst ist der jeweils erreichte Leistungsstand festzustellen und gemeinsam verbindlich zu protokollieren Von diesem aus ist dann zu pr fen mit welchem Zusatz Aufwand das Projektziel in welcher Zeitdauer erreichbar ist Der Kunde muss zus tzlich pr fen ob die festgestellten Leistungsm ngel derart gravierend sind dass eine weitere Leistungserbringung durch diesen Anbieter f r den Kunden nicht mehr zumutbar ist In diesem Fall ist weiter zu pr fen ob es kosteng nstiger ist eine Drittfirma mit der Weiterentwicklung auf der Projektruine oder gleich mit einer vollst ndigen Neuentwicklung zu beauftragen immerhin erfordert die vorg ngige t Heuschele Sanierung von EDV Projekten CR 1988 591 R Heuschele a a O 592 ii Heuschele a a O 592 nennt hier eine vollkommene Irritation des Managements bez glich der widerspr chlichen und wenig nachvollziehbaren Aussagen der beteiligten Projektfachleute und ein Sichverschlei en in gegenseitigen Schuldzuweisungen Ber Streitz IT Projekte retten 69
83. ert oder schlechterf llenden Subunternehmern Unzureichende Qualifikation der beteiligten Mitarbeiter Unzureichende oder gar fehlende Qualit tssicherung Unzureichende Strategie f r die Business Continuity Aufrechterhalten des Gesch ftsbetriebs auch in kritischen Situationen oder Disaster Recovery zu der etwa automatische Datenspiegelung geh rt e Dauer des Parallelbetriebes von Alt und Neusystem Altsystem als R ckgriffs M glichkeit f r das aber entsprechend l nger Lizenzrechte und Wartung Pflege zu kontraktieren sind e Kostenm ig nicht klar kalkulierte Migrationsprojekte etwa von R 3 zu Folgeplattformen e Funktionen outsourcen um sie nicht verstehen zu m ssen e Unzureichende Einbeziehung von Mitarbeitern Eine Umfrage der Standish Group im Jahr 2000 ergab beispielsweise dass nur 28 der Projekte den versprochenen Leistungsumfang zum Beplaniet Zeitpunkt im geplanten Budget und mit der spezifizierten Qualit t erreichten Berichtet wird au erdem dass etwa 46 aller Softwareprojekte die Termine bis zu 24 Monaten und 59 den Einanzrahmen berschreiten w hrend 25 der Entwicklungen berhaupt scheitern Kaum Untersuchungen existieren zu der Frage wie sich solche Projekt Runaways R Glass auf die Wettbewerbsf higkeit des Kunden und letztlich die Marktpositionierung des Anbieters auswirken ur Zit nach Coldewey Warum viele Projekte scheitern Computerwoche 27 2002 36 M ller H
84. f a a O 153 Balzert Lehrbuch der Softwaretechnik Softwaremanagement 2 Aufl 2008 667 8 BleeklWolf Agile Softwareentwicklung 2008 153 68 Koch IT Projektvertr ge rechtssicher gestalten Fertigstellen als unsinnig herausstellen oder Inkonsistenzen auftreten k nnen Restrukturieren ist nur begrenzt m glich Anstelle des paarweisen Programmierens werden formale Inspektionen durchgef hrt hier kommt der Kunde einer Abnahme recht nahe sofern er st ndig in den Entwicklungsprozess einbezogen wird Freilich wirkt eine solche Billigung als im Wesentlichen vertragsgerecht nur f r den jeweils kundenseits pr fbaren Programmteil weshalb der Kunde selbst festhalten sollte wann er welche Teile mit gepr ft hat Der Kunde legt die Priorit ten bei den Gesch ftsprozessen fest der entwickelnde Anbieter die Priorit ten der Features 3 3 Methoden a Scrum Das oft erw hnte Scrum Gedr nge abgeleitet aus dem Rugby stellt keine spezifische sanwan Tee Entwicklungsmethode dar sondern einen Managementrahmen Dieser Ansatz erh ht die bersichtlichkeit da alle Anforderungen in einem Product Backlog anstatt in User Stories gesammelt werden gewisserma en ein lebendes Pflichtenheft Aus dem Product Backlog werden die im n chsten Entwicklungsschritt Sprint abzuarbeitenden Anforderungen im Sprint Backlog gesammelt im print als Umsetzung je einer Iteration bearbeitet und im Sprint Review berpr ft T
85. fang mit nderungen oder Erweiterungen rechnen und entsprechende M glichkeiten vorsehen Auch nach dem Kammergericht Berlin muss der Anbieter allerdings bezogen auf einen Fall eines fehlenden Pflichtenhefts mit gewissen nderungen zpchnen und sie in die Verg tung einpreisen das gilt auch bei Festpreisvereinbarung Er darf solche vorhersehbaren Changes also nicht zus tzlich berechnen was seinen Verg tungsanspruch und Gewinn erheblich reduzieren kann M ngelbeseitigungen m ssen vom Anbieter ohne zus tzliche Verg tung durchgef hrt werden F r jeden angeforderten Change sollte die Art des Change sowie die durch ihn ausgel sten Mehrkosten und m glichen SER enlebungen in einem Change Request Dokument festgehalten werden das beide Seiten unterzeichnen Dis Durchf hrung der Changes erfolgt nach den ITIL und ISO 20000 Spezifikationen Vor Durchf hrung eines Change sind die vorhersehbaren Auswirkungen des Change auf andere ne Anwendung zu pr fen sei es in Design Code Testplan oder Dokumentation Der Auftragnehmer muss au erdem pr fen ob seine Software bei Durchf hrung des jeweiligen Changes noch releasef hig ist also in der an alle Kunden ausgelieferten Grundfunktionalit t unver ndert bleibt und ob weitere Leistungstermine unver ndert eingehalten werden k nnen Eine AGB Klausel nach der sich der Kunde bei Durchf hrung von nderungs bzw Erg nzungsarbeiten also auch von Change Requests nicht mehr auf fr her Ve Ausf
86. flichtig wenn er die Pflichtverletzung nicht zu vertreten hat 280 Abs 1 S 2 BGB wof r er allerdings darlegungs und beweispflichtig ist Freilich scheidet Verzug ohnehin aus wenn kein Vertretenm ssen besteht 286 Abs 4 BGB In IT Projektvertr gen wird die Durchsetzung von Kundenrechten aus Verzug durch den Umstand erschwert dass nicht selten keine taggenau datierten Leistungsfristen vereinbart sind oder derart zun chst vereinbarte Leistungsfristen durch nachtr glich Koch IT Projektvertr ge rechtssicher gestalten 45 vereinbarte Leistungs nderungen oder M ngelbeseitigungen entfallen Im Rahmen des Change Managements sollten deshalb bei nderungen oder Erg nzungen unbedingt neue Leistungsfristen vereinbart werden bzw Aufforderungen zur M ngelbeseitigung grunds tzlich mit einer Fristsetzung verbunden werden 2 Kundenrechte aus M ngeln der Anbieterleistung IT Projekte umfassen meist eine Vielzahl von Einzelleistungen die unterschiedlichen Vertragstypen zuzuordnen sein k nnen die wiederum die M ngelrechte festlegen Der Erwerb von Serverrechnern kann Kaufrecht unterliegen oder als Leasing Mietrecht Die Erstellung oder nderung von Software aber etwa auch von Machbarkeitsstudien oder Feinkonzeptionen durch den Anbieter wird Werkvertragsrecht zuzuordnen sein ebenso das Projektmanagement als getrennt definierte Leistung die allerdings nicht auf einen bestimmten Zeitpunkt hin etwa den der Abnahme sondern w hrend
87. ftware zum aufwendigen Projekt werden Zu pr fen sind die tats chlichen Kosten einschlie lich Einweisungen bzw Schulungen tausender Mitarbeiter des Kunden bei nderungen der Benutzeroberfl che z B SAP GUI und Mitwirkung bei der Installation ebenso notwendige Anpassungen Changes der vorhandenen Anwendung durch Wegfall bisheriger individueller Erg nzungen bzw Erweiterungen Kostenfallen k nnen auch l ngere Testphasen sein ebenso die bernahme der Daten und eine eingeschr nkte Nutzung des bisherigen Release bis zum Beginn des Echtbetriebs Going live des Upgrades Die Durchf hrung des Migrationsprojekts muss in Phasen erfolgen etwa von der Vorstudie zur Ist Situation Analyse der optimalen Migrationsstrategie mit Einbinden bisher kundenindividueller Anpassungen und des neuen Release Implementierung Integrationstest und Produktivstart b Fristen zur Fehlerbeseitigung Reaktionszeiten Ein praxiswichtiges Leistungsmerkmal sind kurze Reaktionszeiten zwischen Fehlermeldung und Eintreffen des Servicepersonals des Anbieters Die Dauer dieser Reaktionszeiten ist in der Regel von der jeweiligen Anwendung abh ngig und bedarf entsprechender konkreter Vereinbarung Dies gilt im brigen auch f r Reparaturen die nur gegen gesonderte Verg tung erbracht werden m ssen Das Serviceunternehmen darf hierbei seine Leistung nicht von einer vorhergehenden Erkl rung des Kunden abh ngig machen die Kosten als zus tzliche zu bernehmen Die
88. ftwaremanagement 2 Aufl 2008 674 t F r eine bersicht s http de wikipedia org wiki Ruby_on_Rails Twitter wurde etwa mit Rails entwickelt Koch IT Projektvertr ge rechtssicher gestalten Web Applikationen on the Fly erlaubt und eine sofortige Visualisierung erm glicht aber nur eine Inline Dokumentation des Quellcodes 34 Auswirkung agiler Entwicklungsverfahren auf die Steuerung des IT Projekts F r jedes der nachfolgenden Projektmerkmale muss der Kunde projektspezifisch pr fen ob er daruf verzichten kann bzw ob die Anforderungen ausreichend konkret geregelt sind a Kein Lasten und IT Pflichtenheft Ein gewisser verborgener Widerspruch in der Sicht des Anbieters auf den Kunden scheint symptomatisch Einerseits soll der Kunde bzw der zust ndige Mitarbeiter fachlich kompetent st ndig pr sent und kooperationsbereit sein Andererseits wird das flexibel agile Entwickeln wohl meist nur dann erforderlich wenn der Kunde noch keine klaren Vorstellungen von der gew nschten Anwendung hat Eine Bemerkung aus der Praxis macht dies schlaglichtartig deutlich Mit Version 1 0 bekommt der Kunde eigentlich nicht was er will sondern das was im Vertrag steht Genau dieses Verwendungsrisiko etwa anderes vereinbart zu haben als er braucht ist freilich typischerweise dem Kunden zugeordnet Gegen ber einem solchen Kunden bleibt beim klassischen Vorgehen nur Schritt f r Schritt herauszufinden was der
89. g pr ft Ein Verzicht auf die Erf llung dieser Pflichten etwa durch Nichteinrichten eines Risikofr hwarnsystems gem 91 Abs 2 AktG w rde die Sorgfaltspflicht des Gesch ftsleiters verletzen Die Gesch ftsleitung hat ihre Ma nahmen schon aus Gr nden der M glichkeit einer Beweisf hrung aussagef hig zu dokumentieren Weiter darf die Gesch ftsleitung nicht ohne angemessenen Grund auf Rechtspositionen und Anspr che des Unternehmens verzichten Rechtsdurchsetzungspflicht BJ Hierzu geh rt etwa dass begr ndete Anspr che aus Nicht oder Schlechterf llung von IT Projektvertr gen gegen Anbieter in geeigneter Weise durchgesetzt werden m ssen um Schaden vom Gesellschaftsverm gen zu wenden Zur allgemeinen Sorgfaltspflicht der Gesch ftsleitung geh rt andererseits rechtzeitig noch bei den Verhandlungen ber den abzuschlie enden Projektvertrag f r eine ausreichende vertragsrechtliche Absicherung des Auftraggebers zu sorgen etwa Rodewald BB 2006 113 114 Koch IT Projektvertr ge rechtssicher gestalten 77 durch detaillierte und kontrollf hige Leistungsbeschreibung Definieren eines kompletten Projektzeitplans genaue Zuordnung von Verantwortlichkeiten etwa f r die Pflichtenhefterstellung Festlegen aussagef higer Abnahme Funktionspr fungs kriterien Absicherung gegen Leistungs bzw Nacherf llungs M ngelbeseitigungsverzug etwa durch Vertragsstrafen Vereinbaren eines Ausstiegs verfahrens bei Nic
90. gabe der Sourcen kann soweit sie berhaupt besteht in AGB abbedungen werden Au erdem schuldet der Anbieter auch bei Individualentwicklungen die Herausgabe der Sourcen solange nicht wie er noch Pflegeleistungen oder M ngelbeseitigungen an der OLG D sseldorf CR 1986 1091 H OLG M nchen Urt v 16 7 1991 25 U 2586 91 CR 1992 208 Keine Verpflichtung zur Sourcen Herausgabe da im Vertrag nur Objektcode erw hnt BGH Urt v 16 12 2003 X ZR 129 01 CR 2004 490 I Koch IT Projektrecht Rdn 208 114 LG K ln Urt v 15 4 2003 85 O 15 03 JurPC Web Dok 232 2003 Koch IT Projektvertr ge rechtssicher gestalten 29 Software zu erbringen hat oder diese weiterentwickeln soll Bei Ende der Pflege bzw Gew hrleistungsverpflichtung kann der Quellcode dann herauszugeben zu sein allerdings nicht in der alten bei Vertragsunterzeichnung vorhandenen nicht mehr uneingeschr nkt verwendbaren sondern in der aktuellen durch die Pflege angepassten Fassung dies bedarf aber besonderer Vereinbarung 9 Service Level Agreements Vereinbarungen abgestufter Anbieterleistungen F r die Pflege von Software aber auch die Wartung von Hardware etwa Web Serverrechner oder die Verf gbarkeitsmerkmale f r Internet Anbindungen werden oft nach Kenmzahlen abgestufte Service Levels vereinbart Anhaltspunkte f r Regelungen finden sich in den Regelwerken ITIL und ISO 20000 2 Pr zise und transparent sollten Qualit t z B Ve
91. h Auslgapnmng den zus tzlichen Aufwand f r Koordination und Kommunikation bersteigen Mit zunehmender Anpassung an spezifische Bed rfnisse wird die Leistung Sl und teurer und verlangt vom Auftraggeber h heren Steuerungsaufwand Der Steuerungs und Koordinationsaufwand steigt au erdem berproportional an wenn der Auftraggeber mit mehreren a tg abieterm arbeitet Multisourcing und zwischen diesen Partnern Schittstellen bestehen bzw erst hergestellt werden m ssen Beim Outsourcing werden Arbeits oder Gesch ftsprozesse einer Organisation ganz oder teilweise zu externen Dienstleistern ausgelagert damit aber auch Teile der oder die SAD Personaldatenverarbeitung Als typische Beispiele nennt das BSI GS Handbuch den Betrieb eines Rechenzentrums einer Applikation einer Webseite oder des Wachdienstes Um diese Leistungen ad quat in IT Vetr gen abbilden zu k nnen darf nicht nur der Zielstatus sondern muss auch der Prozess der Auslagerung detailliert und in kontrollf higen Schritten definiert werden Dietrichsweiler Kostensenkung in der denzentralen IT Infrastruktur in Dietrich Schirra IT im Unternehmen 139 153 Tiemeyer Organisation und F hrung im IT Bereich in Tiemeyer Hrg Handbuch IT Management 321 339 Gorritz Habermann Gezieltes und strukturiertes Outsourcing von IT in Dietrich Schirra IT im Unternehmen 235 245 A Gorritz Habermann a a O 235 247 Gorritz Habermann a a O 235 247 GS
92. h Verwaltungsaufwand f r Dokumentieren belastetes Entwickeln angeboten wird Auch dies ist nicht ohne Risiko wenn oder soweit dieses Vorgehen als Umgehen des Verbots aus 307 Abs 2 Nr 2 BGB gesehen werden kann Und schlie lich verlangen agile Methoden keinen vollst ndigen Verzicht auf das Dokumentieren Selbst energische XP Anh nger betrachten etwa bei Entwicklung und Test gar Komponente die Dokumentation als selbstverst ndlich dazu geh rend E Ein vollst ndiger en einer Dokumentationspflicht w rde deshalb das berma verbot verletzen Wenn der Verzicht aber nur f r bestimmte Dokumentationsteile gelten soll bleibt es grunds tzlich das Risiko des Anbieters diese Abgrenzung klar erkennbar zu ziehen und den Kunden ber die Auswirkungen dieses partiellen Verzichts aufzukl ren Der Anbieter tr gt damit das rechtliche Risiko sich nicht voll von seiner Dokumentationspflicht entlasten zu k nnen c Keine Qualit tssicherung Anbieter sind bei der Softwareentwicklung zur Qualit tssicherung verpflichtet auch sie ist mithin nicht umstandslos verzichtbar So auch Schneider ITRB 2010 18 21 1 S n her Schneider ITRB 2010 18 21 HruschkalRupp Starke Agility kompakt 2 Aufl 2009 90 14 Fuchs in Ulmer Brandner Hensen AGB Recht 10 Aufl 2006 307 Rdnr 106 71 3 Schneider Handbuch des EDV Rechts 4 Aufl 2009 E Rdnr 339 a Koch Computer Vertragsrecht 7 Aufl 2009 S 384 72 Koch
93. handelt werden Weicht die Gesch ftsleitung von den durch ITIL oder ISO Normen festgelegten Mindestanforderungen ab trifft sie also z B nicht bestimmte vertragliche Regelungen im Projektvertrag oder kontrolliert sie die Erf llung des vertraglichen Pflichtenprogramms des Anbieters nicht ausreichend tr gt sie die Beweislast daf r dass eine nachteilige Entwicklung unabh ngig von dieser Abweichung eingetreten w re F r den Leistungsbereich M ngelhaftung und Wartung Pflege relevant sind insbesondere das Incident Management und das Problem Management s unten Service Level Management Am Beispiel des Service Level Management SLM sei die ITIL Konzeption verdeutlicht Das SLM soll eine laufende Kontrolle der kontraktierten Service BSI ITIL und Standards f r IT Prozesse 9 16 S den berblick bei Steinberg Goodwin Computerwoche 2 2007 24 25 52 Gammel ITIL bringt IR Abteilungen auf Trab Computerwoche 17 2005 34 Zielkel berhorst Computerwoche 27 2005 14 Bundesamt f r Sicherheit in der Informationstechnik BSD ITIL und Informationssicherheit M glichkeiten und Chancen des Zusammenwirkens von IT Sicherheit und IT Service Management 2005 www bsi bund de 13 i Kopperger Kunsmann Weisbecker IT Servicemanagement in Tiemeyer Hrg Handbuch IT Management 115 134 Kopperger Kunsmann Weisbecker IT Servicemanagement in Tiemeyer Hrg Handbuch IT Management 139 Ausf hrlich Koch IT
94. haupts chlicher Risikobereich des Backsourcing sind Transferschwierigkeiten So k nnen ehemalige IT Mitarbeiter verpflichtet sein wieder zum alten Arbeitgeber zur ckzuwechseln Betriebsr ck bergang der auch 613 a BGB folgt aber dem R ck bergang widersprechen Auch kann der Outsourcing Kunde verpflichtet sein seinem bisherigen Anbieter entgangene Gewinne zu ersetzen Auch muss bei Anbieterwechsel der gesamte Ablauf der Auslagerung erneut durchgef hrt werden Hierzu kann geh ren dass neue IT Systeme und Softwarelizenzen erworben werden m ssen Schlie lich kann eine gewisse Zeit vergehen bis sich der neue Anbieter erforderliches Fachwissen angeeignet hat bergang von Arbeitnehmern Die bernahme der Arbeitnehmer ist im Outsourcing Vertrag zu regeln Hierbei ist zu beachten Die Aufgaben bertragung auf den Outsourcing Anbieter kann sich als Betriebs bergang im Sinne von 613a BGB darstellen Die bisher befassten Mitarbeiter werden hierbei zu Arbeitnehmern des Anbieters Dies wurde sogar f r die bertragung von fr her selbst wahrgenommenen Reinigungsaufgaben von einem Unternehmer auf einen en durch Vertrag bei Besch ftigung nur eines Arbeitnehmers anwendbar Der EuGH sieht auch eine reine Funktionsnachfolge als einen entsprechenden Betriebs bergang an 613 a BGB ist aber Bent anwendbar wenn der Auftragnehmer weder Arbeitsmittel noch Personal bernimmt Mit Wirkung seit dem 1 4 2002 muss der Betriebsve
95. hrung dieser R ckgabe n her spezifiziert werden Sinnvoll ist au erdem die Vereinbarung einer Funktionspr fung ob die Daten verarbeitungstauglich sind berhaupt noch nicht gerichtlich entschieden und deshalb unbedingt vertraglich klarzustellen ist ob der Anbieter diese Daten in einem bestimmten von ihm erarbeiteten und verwendeten Datenformat und modell herausgeben muss Deren Herausgabe sollte dann unbedingt vereinbart werden wenn sonst der Kunde diese Daten nicht oder nur mit unverh ltnism igem Aufwand bearbeiten k nnte Die Formate bzw Modelle sollten im Vertrag mit sp testem Herausgabezeitpunkt genau bezeichnet werden d Auf Outsourcing Projekte anwendbares Recht Dienstvertragsrecht ist f r allgemeine Betreuungsleistungen wie Beratung etc anwendbar Werkvertragsrecht f r alle Leistungen die auf Erbringung eine Leistungserfolges abzielen etwa das zielgerichtete Steuern von een z B das Lauff higmachen von Software das Installieren eines Update die Durchf hrung eines Backup und zielorientierte Supporti ungen Das berlassen von Rechnerkapazit t folgt grunds tzlich Mietvertragsrecht Der jeweilige Vertragstypus muss wie sonst auch von den Gegebenheiten des Falles gem 157 BGB bestimmt werden Ein typisches Beispiel f r eine werkvertragliche Leistung ist das Vorhalten eines Ausfall Rechenzentrums Service Der Service zielt hier darauf ab dass das Rechenzentrum im Notfall im vereinbarten Leistungsumfang einsatzb
96. hterreichen der Projektziele Bei Verletzung dieser Pflicht durch Nichtanwendung der erforderlichen Sorgfalt haften die Mitglieder der Gesch ftsleitung gegen ber dem Unternehmen f r das sie handeln pers nlich auf Ersatz entstandener Sch den 93 Abs 1 und 2 AktG f r Vorst nde hnlich 43 Abs 1 und 2 GmbHG f r Gesch ftsf hrer Voraussetzung der pers nlichen Haftung von AG Vorst nden oder GmbH Gesch ftsf hrern ist freilich dass durch die Pflichtverletzung unternehmensgef hrdende Risiken f r das Unternehmen entstehen und diese Pflichtverletzung von dem oder den Mitglied oder Mitgliedern der Gesch ftsleitung zu vertreten ist Dieser Fall kann eintreten wenn das Scheitern eines nicht ausreichend kontrollierten Projekts den Produktionsbetrieb des Unternehmens gef hrdet Der Aufsichtsrat einer AG hat gem 111 Abs 1 AktG kontrolliert die Gesch ftsf hrung und ordnungsgem e Pflichterf llung des Vorstandes zu kontrollieren 76 77 AktG Der Vorstand muss den Aufsichtsrat ber zu treffende Ma nahmen und grunds tzliche Fragen unterrichten 90 Abs 1 Nr 1 AktG Hierzu geh rt die Pr fung ob der Vorstand seinen Pflichten nachkommt und insbesondere gem 91 Abs 2 Tan ein Risikofr herkennungssystem eingerichtet und sinnvoll organisiert hat Die Durchf hrung von IT Projekten ist geradezu ein Musterbeispiel f r Risiken die jede Gesch ftsleitung fr herkennen und begrenzen muss Diese Projektrisiken wiegen
97. iche Einigung erfolgen Dies ist im Vertrag bzw Erg nzungs Sanierungsvertrag festzuhalten da das EM sonst als einseitiges Leistungsbestimmungsrecht des Anbieters nach 315 BGB ausgelegt werden k nnte Auch bei Vertragsverl ngerungen etwa von Software Pflegevertr gen kann das Einholen mehrere Angebote die Verhandlungsposition des Kunden st rken und ihm helfen Preisreduzierungen zu erreichen Allgemein ist ein Vertragsmanagement sinnvoll in dem regelm ig die jeweiligen Leistungspflichten im Vergleich zum aktuell beb tigten Leistungsumfang Vertragslaufzeiten und Ausstiegsklauseln berpr ft werden II Leistungsst rungen im Projekt Typische anbieterseitige Leistungsst rungen sind Verzug und Schlechtleistung Sie begr nden jeweils Kundenrechte die in der geeigneten Weise geltend zu machen sind Bei Vertretenm ssen surch den Anbieter kann der Kunde Schadensersatz verlangen 1 Kundenrechte aus Anbieterverzug Ger t der Auftragnehmer mit der Erbringung von Projektleistungen in Verzug stellt dies eine Pflichtverletzung dar 280 Abs 1 BGB Der Auftraggeber kann e die Zahlung einer vereinbarten Verg tung verweigern wenn er nicht vorleistungspflichtig ist 320 Abs 1 S 1 BGB oder e vom Vertrag zur cktreten 323 Abs 1 BGB und oder Ersatz des Verz gerungsschadens verlangen 280 Abs 1 BGB oder e nach Ablauf einer gesetzten Frist Schadensersatz statt der Leistung Der Auftragnehmer ist nicht schadensersatzp
98. in Redeker Hrg Handbuch der IT Vertr ge Abschnitt 5 4 Rdn 166 257 258 Koch IT Projektvertr ge rechtssicher gestalten 61 Festlegung der Mitwirkungspflichten des Auftraggebers einschlie lich Bereitstellen technischer Infrastuktur und Gew hrung von Zugang Regelm iger kKundenseitiger Check z B alle zwei Jahre etwa der kundenspezifischen Ausrichtung der Service Levels und der Einhaltung von Verf gbarkeiten Anpassungs und Weiterentwicklungspflicht des Anbieters M glichkeiten der Leistungs nderung Change Management Beauftragung von Subunternehmern durch Auftragnehmer nur bei Einwiligung des Auftraggebers Eventuell bereignung von Hardware des Auftraggebers an den Outsourcing Anbieter hier M ngelhaftung des Auftraggebers regeln Lizenzrecht des Anbieters zur Nutzung von Software die dem Kunden Auftraggeber von Dritten Lizenzgeber der Software berlassen wurde Stimmt der Lizenzgeber nicht der bertragung des Nutzungsrechts vom Kunden auf den Anbieter zu kann die Notwendigkeit entstehen dass der Anbieter selbst eine Lizenz erwerben muss Nutzungsrechte an vom Anbieter entwickelter Software etwa bei Wechsel des Kunden zu anderem Anbieter zwecks Erhalten der Kontinuit t der Datenverarbeitung Wartung Pflege des Anbietersystems Regelung f r Verzug bzw Teilverzug mit der Leistungserbringung Regelung unter welchen Voraussetzungen eine wiederholte bzw eine schwere Pflichtverletzung vorliegt M
99. in erh htem Ma e fehlergeneigte Verfahren anwendet Ihn trifft die Beweislast aiui dass der Fehler nicht in seinem Verantwortungsbereich entstanden ist Auch geh rt das R ckverfolgbarmachen der einzelnen Entwicklungsschritte zwecks Fehlerverfolgung zur Anbieterpflicht um etwa sicherzustellen dass Software gar nicht erst an Kunden ausgeliefert wird f r die andere Kunden bereits gar sicherheitsgef hrdende M ngel ger gt haben d Intensive und st ndige Kundenmitwirkung Kunden machen sich oft nicht klar a ihre Mitwirkung in agilen Entwicklungsprojekten deutlich intensiviert ist Sie m ssen m glichst st ndig als Ansprechpartner vor Ort sein das bindet Mitarbeiter Sie m ssen au erdem angesichts h ufiger Entwicklungszyklen laufend Programmfassungen berpr fen und akzeptieren oder ablehnen und hierzu entscheidungsberechtigt sein Schlie en sollten die beteiligten Mitarbeiter des Kunden Fachexperten der gew nschten Anwendung sein In manchen F llen kann zu fragen sein ob dieser Aufwand Murawski www inf fu berlin de inst ag sc teaching S AGILE 2004 ausarbeitungen Stefan_Murawski _agile_prozesse_ausarbeitungen_final pdf 7 Dieses Risiko tr gt auch der Kunde der agil entwickelte Software in seinen Produkten einsetzt etwa in Fahrzeug Bremssystemen so etwa BGH Urt v 9 5 1995 VI ZR 5 91 Mehrweg Mineralwasserflaschen ZIP 1995 1094 1097 3O Zur Kundenmitwirkung und m glichen Eskalationsregelungen
100. ion oder von Dokumentationsteilen Verwendete Systemumgebung soweit nicht aus der Abnahmespezifikation zu entnehmen Bezeichnung der getesteten Komponente Bezeichnung der Testprozedur mit zugeh riger Abnahmespezifikation Beschreibung der Abweichung mit erwartetem und tats chlichem Ergebnis Reproduzierbarkeit des Fehlers Er Aus der technischen Sicht Streitz IT Projekte retten 61 5 Streitz IT Projekte retten 61 Hier wird an das sog Pareto Prizip angekn pft nach dem 20 der Fehlerurachen 80 der Fehlerwirkungen erzeugen Liggesmeyer Software Qualit t 15 1 Koch IT Projektrecht Rdn 189 Nach Streitz IT Projekte retten 141 Ellenberger M ller Zweckm ige Gestaltung von Hardware Software und Projektvertr gen 66 Koch IT Projektvertr ge rechtssicher gestalten 27 e Auswirkungen des Fehlers z B Abbruch der Verarbeitung Inkonsistenz der Datenbank e Ausdrucke der Systemangaben bzw Fehlerbilder e Aufnahme der festgestellten Fehler in eine von beiden Seite gef hrte bzw kontrollierte Fehlerdatenbank deren Eintragungen nach Priorit ten abgearbeitet werden e Unterschriften vom Kunden und Anbieter Festzulegen ist auch das Abnahmeverfahren das meist die Form einer technischen und anwendungsbezogenen Funktionspr fung hat z B Anlage einer elektronischen Personalakte mit Alias Namen Hier m ssen die f r beide Vertragsparteien verbindlichen Abnahme bzw Funktionskriterien im Projektvertrag o
101. istungen inklusive Qualit tsstandards und Fristen im Einklang mit der vorhandenen Gesetzgebung festgelegt werden meist in der Form von Service Level Agreements SLA ebenso die genauen Modalit ten der Zusammenarbeit sowie Ansprechpartner Reaktionszeiten IT Anbindung Kontrolle der Leistungen Ausgestaltung der IT Sicherheitsvorkehrungen Umgang mit vertraulichen Informationen Verwertungsrechte Weitergabe von Information an Dritte etc Phase 5 Erstellung eines IT Sicherheitskonzepts f r den ausgelagerten IT Verbund Auftraggeber und Outsourcing Dienstleister m ssen in enger Zusammenarbeiz detailliertes Sicherheitskonzept ausarbeiten das ein Notfallvorsorgekonzept enth lt Der Betriebsrat sollte an dieser Ausarbeitung zumindest beratend beteiligt sein 92 BetrVG Phase 6 Migrationsphase Phase 7 Planung und Sicherstellen des laufenden Betriebs Besonders sicherheitskritisch bl Migrations oder bergangsphase die deshalb einer sorgf ltigen Planung bedarf g Abnahme von Outsourcing Leistungen Entscheidend f r die Festlegung von Abnahmekriterien ist der konkret vereinbarte Leistungsumfang Hierzu geh ren etwa die Verf gbarkeit des Outsourcing Systems oder bestimmte Systemkomponenten ebenso die Ausgestaltung des Datentransfer Streckenminimierung bzw Volumenmaximierung GS Handbuch M 2 253 Vertragsgestaltung mit dem Outsourcing Dienstleister GS Handbuch M 2 254 GS Handbuch M 6 83 7
102. le zur berpr fung der Wirksamkeit der Managementprozes sel An diesem Ma stab sind zum einen die Vereinbarungsinhalte von IT Projektvertr gen zu messen zm anderen die Pflichterf llung der Gesch ftsleitung ITIL beschreibt Prozesse w hrend ISO 20000 Kriterien festlegt die sich messen lassen etwa Umfang Art und Definition der Services Planung und Implementierung eines a Tr per ver nderten Service Von 216 befragten Unternehmen setzten 80 ITIL b52 ein ITIL beschreibt n mlich nur das Was nicht das Wieb gibt also eine Checkliste der erforderlichen Regelungspunkte legt aber nicht fest wie die konkreten Regelungen aussehen sollen was auch angesichts der Unterschiedlichkeit der Sachverhalte nicht viel Sinn machen w rde Sache des Auftraggebers ist f r die jeweiligen Regelungsthemen mit dem Anbieter Vereinbarungen auszugestalten die den spezifischen Unternehmensanforderungen entsprechen Dies bedeutet in der Vertragspraxis Wenn die ITIL Anforderungen f r das Change Management etwa ein berwachen des Umsetzungserfolgs verlangen so ist hiermit noch kein spezifischer Pr fprozess definiert Diese Definition und die konkrete Ausgestaltung der IT Prozesse m ssen die Vertragspartei vereinbaren Die ITIL Vorgaben k nnen also nicht fehlende Vereinbarungsinhalte ersetzen sondern nur helfen solche Vers umnisse zu vermeiden und zugleich sicherstellen dass in allen IT Projektvertr gen die jeweils erforderlichen Regelungen ver
103. leibt welche Leistungen geschuldet und welche erbracht sind Hierzu m ssen die zugrundeliegenden Anforderungs und L sungsbeschreibungen laufend fortgeschrieben werden Im RM werden die kundenseitigen Anforderungen im Zusammenwirken beider Vertragsparteien definiert spezifiziert und verifiziert analysieji vereinbart einem Projekt zugewiesen und in diesem mit allen nderungen verfolgt L Das RM sollte zwischen den Vertragsparteien als Form der Leistungserbringung vereinbart werden Das Pflichtenprogramm des Anbieters weitet sich hierdurch aus Er muss etwa sicherstellen dass die fachlichen Anforderungen des Kunden jedenfalls aus Anbietersicht vollst ndig korrekt konsistent testbar verst ndlich notwendig eindeutig umsetzbar und in einer einheitlichen Basis zusammengefasst sind und auch durch alle nderungen hindurch bleiben Keinesfalls darf der Anbieter Kundenanforderungen einfach identisch bernehmen da f r den Anbieter das Risiko zu gro ist eine L sung in die falsche Richtung zu implementieren F r die Gesamtheit der Streitz IT Projekte retten 23 Nach VDI 2519 beinhaltet das Lastenheft die quantifizierbare und pr fbare vom Auftraggeber als Ausschreibungs oder Vertragsgrundlage zu erstellende Beschreibung aller Anforderungen aus Anwendersicht einschlie lich aller Randbedingungen also das Was und Wof r hingegen das Pflichtenheft die Beschreibung der Realisierung des Lastenhefts also das Wie S
104. lichen Beratung nicht immer die urheberrechtlichen Besonderheiten aus der mittlerweile vorherrschenden objektorientierten Programmierung beachtet Sch pferisches Gestalten kann hier oft weitgehend entfallen wenn nur schematisch Festlegungen der Programmeigenschaften nach Kundenvorgaben erfolgen Zu regeln ist weiter welche Rechte der Kunde bei M ngeln der Anbieterleistung hat und wie er diese Rehte durchsetzen kann wann also etwa konkret mit einer M ngelbeseitigung sp testens zu rechnen ist Wird Software nur zeitlich begrenzt berlassen ist zu regeln ob etwa Programmkopien auf Datentr ger zur ckzugeben sind und ob Programmkopien in Rechnern gel scht werden m ssen bzw welche Kontrollrechte der Anbieter insoweit hat 1 Anforderungsanalyse Requirements Management Der Kunde muss bevor er Anbietern Leistungsauftr ge erteilt zun chst unter untersuchen welche Probleme er eigentlich mit der betrieblichen IT l sen will Dies klingt trivialer als es in der Praxis ist So sollte der Kunde zun chst kl ren ob bestimmte Gesch ftsprozesse die historisch gewachsen und unn tig Komplex sind vereinfacht bzw standardisiert werden k nnen Dieses Business Process Reengineering ist oft wesentlich kosteng nstiger und schneller durchzuf hren als ein individuelles Programmieren entlang vorfindlicher Anwendungsstrukturen Notwendig ist also eine Anforderungsanalyse blicherweise teilt sich diese Anforderungsanalyse in eine A
105. lnen oder allen IT Funktionen an externe Dienstleister Diese k nnen durch Skaleneffekte Leistungen kosteng nstiger durchf hren OuBoneine hat sich aus der Nutzung der Rechenzentren beauftragter Anbieter entwickelt ns Providing ASP wird als Auspr gung von Outsourcing verstanden Auf ASP wird nachfolgend Rdn eingegangen Grundidee hinter dem Outsourcing Konzept und dessen wesentlicher Vorteil ist dass sich der Auftraggeber auf Kernkompetenzen konzentriert und nicht hierzu geh rende Funktionen und Abl ufe auf Auftragnehmer auslagert Auch k nnen technische Neuerungen leichter und weniger aufwendig nutzbar gemacht werden Jedoch sollte der Auftraggeber mindestens so viel Kompetenz behalten Retained Organization dass er den Outsourcing Auftragnehmer noch kompetent steuern kann da Outsourcing Anbieter und allgemein Lieferanten in der Regel kaum Interesse daran haben nur einige Si Wenzel Betriebswirtschaftliche Anwendungen des integrierten Systems SAP R 3 35 i Koch Computer Vertragsrecht Rdn 1092 Typische Standardeinstellungen sind etwa Anlegen der Unternehmensstruktur Mandant Gesellschaften Buchungskreise Auswahl des Kontenplans etc s CDI Basissystem S 317 i ABAP steht f r Advanced Business Application Programming und ist eine Programmiersprache der 4 Generation 4GL die mit Early Prototyping arbeitet CDI Basissystem S 131 i Stahlknecht Hasenkamp Einf hrung in die Wirtschaftsi
106. ls Reduzierung der Verg tung in Anrechnung bzw Abzug gebracht werden Weist die kaufweise berlassene Software bei bergabe im Test Bunker ar aae M ngel auf ist eine Zur ckweisung wegen Vertragswidrigkeit m glich Dann ist auch keine Annahme als Erf llung im Sinne von 363 BGB erfolgt und kann der Kunde bis zur Beseitigung der Vertragswidrigkeit M ngel sein Zur ckbehaltungsrecht aus 320 Abs 1 S 1 BGB an der zu leistenden Verg tung geltend macht Bei gr eren Projekten kann bereits der Zinsgewinn deutlich zu Buche schlagen Voraussetzung ist freilich eine Staffelung der Verg tungszahlungen dergestalt dass bei bergabe noch eine ausreichend hohe Restzahlung offen bleibt Soweit der Anbieter sein Haftungsrisiko summenm ig begrenzt kann es sinnvoll sein f r das nicht abgedeckte Risiko eine Versicherung abzuschlie en und mit dem Anbieter die bernahme eines Teils der jeweils vereinbarten markt blichen Versicherungspr mie zu vereinbaren Vermieden werden sollten schlie lich typische Kostenfallen so etwa e die schleichende Erweiterung des Projektumfangs Das Projekt sollte auf Kernanforderungen reduziert werden Nice to have Anforderungen k nnen gestrichen oder zur ckgestellt werden e berentwickelte Graphic User Interfaces GUIs Die GUI Entwicklung sollte erst erfolgen wenn ein endg ltiges Format feststeht e Der Big Bang Ansatz des Projekts Statt eines komplexen Gesamtprojekts sollten mehrere
107. ls dann wenn Fehlerursachen und auswirkungen etwa bei Software Dritter nicht vorhersehbar sind nach 307 Abs 2 Nr 1 BGB unwirksam sein da dem Anbieter ein nicht kalkulierbares Leistungsrisiko aufgelastet w rde Zu pr fen ist hier aber ob nicht im Einzelfall tats chlich eigentlich zwischen den Vertragsparteien eine Instandhaltungsverpflichtung vereinbart worden ist bei der der Anbieter Vorkehrungen schuldet dass Fehler gar nicht erst auftreten Insoweit bernimmt der Anbieter auch das Risiko des Auftretens von Fehlern Eine solche Vereinbarung eines Leistungsinhaltes unterliegt nach 307 Abs 3 S 1 BGB nicht der AGB rechtlichen Kontrolle Das Werk Wartung gilt bez glich der Systeminstandhaltung als mangelhaft wenn die Anlage in einen Zustand ger t in dem St rungen zu erwarten sind T wenn dieser Zustand auf ungen gende Wartungsarbeiten zur ckzuf hren sind Gleiches gilt f r Software sinngem Nicht nur bei der urspr nglichen Implementierung der Software sondern auch bei erforderlichen Pflegema nahmen treffen den Kunden fallspezifisch unterschiedliche Mitwirkungsobliegenheiten Der Kunde hat grunds tzlich alle Anstrengungen zu unternehmen um eine reibungslose Pflege zu erm glichen und alles zu unterlassen was diese Ma nahmen erschweren oder unm glich machen k nnt So muss der Kunde etwa umgehend auftretende St rungen an Hardware und Software mitteilen die aufgetretenen Fehler soweit machbar in einer f r den
108. ltung Eine andere Unterscheidung differenziert nach Grundtypen e Bei Plattform oder Rechenzentrums Outsourcing wird der vollst ndige Aufgabenumfang des Rechenzentrumsbetriebs bzw des Network Services PC Services vom Outsourcing Anbieter bernommen e Beim Application Service Providing ASP stellt der ASP Anbieter Server Betriebs und Anwendungssoftware zur Verf gung die mit dem Kunden ber Kommunikationsnetze verbunden sind e Beim Business Process Outsourcing werden komplette Gesch ftsprozesse z B Logistik Vertrieb Buchhaltung einschlie lich der hierf r notwendigen IT Services ausgelagert Auch sonstige Prozesse oder einzelne Funktionen k nnen ausgelagert werden Outtasking c Risiken von Outsourcing Projekten Outsourcing Vorhaben sind nach den Erfahrungen der Praxis besonders komplex und damit in erh htem Ma e risikogef hrdet Es fehlen ausreichende Absicherungen um die Vertragserf llung zu Kontrollieren bzw durchzusetzen Au erdem besteht ein wesentliches Risiko in einer Abh ngigkeit vom beauftragten Outsourcing Anbieter da eine R cktrittsentscheidung nur schwer umsetzbar und wenig realistisch ist zumal bei freiwilliger Aufgabe von IT Management Know how Noch gravierender ist das Risiko wenn auch Produktionssteuerungsprozesse ausgelagert werden da hier auch Fachkompetenz aufgegeben wird die teilweise nicht mehr r ckholbar ist Tiemeyer Organisation und F hrung im IT Bereich
109. mentierenden und laufend zu aktualisierenden Project Reports sollten alle Anpassungen mit Vereinbarungsdatum und Status in Bearbeitung zur ckgewiesen etwa bei nicht best tigbaren M ngelbehauptungen zur ckgestellt behoben und verifiziert mit automatisierten statistischen Auswertungen aufgelistet werden Im Idealfall ist so f r den Kund zu jedem beliebigen Zeitpunkt der jeweils aktuelle Bearbeitungsstand abfragbar Das RM ist grunds tzlich vom Anbieter zu steuern Dies stellt eine werkvertragliche Leistung des Anbieters dar die vorsorglich gesondert vereinbart werden sollte Anhand klar definierter Kriterien muss f r beide Seiten schnell feststellbar und entscheidbar sein ob eine nderung noch zum Leistungsumfang geh rt einem zugelassenen Sonderwunsch zuzuordnen ist oder eine nur gegen Zusatzkosten und oder Terminsverl ngerung durchzuf hrende Auftragserweiterung darstellt Voraussetzung hierf r ist dass eine spezifische Konfigurationsbasis Baseline definiert und abgenommen ist hier im T ek peit die nur durch einen formalen Anderungsprozess ge ndert werden kann Gekl rtt und schon bei Vertragsschluss vereinbart werden muss welche Anwendungsf lle mit welchen Datentypen zu testen sind und welche Testdaten der Kunde bis zu welchem Datum vorzugeben hat Testf lle und daten m ssen alle vereinbarten Anforderungen abdecken Es kann erforderlich sein zun chst ein komplettes Testsystem zu ins
110. mhaus erworben das die Systemsoftware selbst zugeliefert erhalten hat und ist die Upgrade Klausel nicht im Vertrag mit diesem Systemhaus enthalten kann der Anbieter der Systemsoftware mangels Vertragsbeziehung den Kunden weder aus Urheberrecht noch aus Vertrag wirksam in Anspruch nehmen 165 LG Coburg Urt v 29 1 2002 22 O 398 01 JurPC Web Dok 346 2002 38 Koch IT Projektvertr ge rechtssicher gestalten In Service Level Agreements sollten die laufenden Geb hren sowie deren Erh hungen in die Kostenkontrolle und Wirtschaftslichkeitspr fung einbezogen sein Auch m ssen een berwacht werden ebenso die Anzahl der tats chlich unterst tzten Ger te f amp berpr ft werden sollte ob Service Levels mit sehr hohem Verf gbarkeitsgrad tats chlich ben tigt werde Premium IT Ein Wechsel zu neuen Releases kann dann unzumutbar sein wenn hierf r h here Hardware und andere Anforderungen erf llt sein oder vorhandene Anwendungen propriet re Erweiterungen z B mittels ABAP 4 kostenaufwendig integriert m ssen ohne dass der Kunde einen Vorteil in der Nutzung zieht Das Auslaufen der Unterst tzung und die K ndigung von Wartungs Pflegevertr gen ist nicht frei m glich Entscheidend ist die vereinbarte Laufzeit des Vertrages Die nderung a ee A eines Anbieters allein rechtfertigt keine au erordentliche EIER 167 Eu K ndigung ebensowenig die Weigerung eines Kunden bei Rense eine Upgrade Geb hr in H he von
111. n Turtschi Entsprechung und Beweglichkeit als Programm wertorientierter IT Strategie in Dietrich Schirra IT im Unternehmen 13 22 Koch IT Projektvertr ge rechtssicher gestalten 37 naheliegenderweise dem Kunden keine ausschlie lichen Nutzungsrechte einger umt werden k nnen Der Kunde wird dann freilich auch nicht den Preis f r eine komplett ausschlie liche Rechteinr umung bezahlen wollen Bei der anstehenden Verl ngerung von Vertr gen kann eine Reduzierung der Verg tung durchsetzbar sein wenn etwa Wartungs Pflegeleistungen nicht in dem urspr nglich vorausgesehenen Umfange in Anspruch genommen wurden Eine Verg tungsreduzierung l sst sich hier u a damit begr nden dass auch die Vorhaltekosten des Anbieter f r das Vorhalten qualifizierter Leistung entsprechend geringer sind Sinnvoll kann auch das rechtzeitige Einholen von Parallelangeboten sein um den markt blichen Preis f r eine bestimmte Leistung zum aktuellen Zeitpunkt festzustellen Demgegen ber sind m gliche zuweilen nicht unbetr chtliche Migrationskosten zu ber cksichtigen die die Verg tungsdifferenz bersteigen k nnen Meistbeg nstigungsklauseln des Vertrages sollten auch in der Laufzeit genutzt werden Hierdurch lassen sich Verg tungsreduzierungen erreichen wenn anderen Kunden des Anbieters f r die gleiche Leistung eine niedrigere Verg tung angeboten wird Hier k nnen Kontakte in User Groups f r bestimmte Software n tzlich sein Monatliche Wartu
112. nach Schneider v Westphalen Witzel Software Erstellungsvertr ge F Rdn 139 x M ller Hengstenberg Der Vertrag als Mittel des Risikomanagements CR 2005 385 389 Koch IT Projektvertr ge rechtssicher gestalten 17 2 Abschluss des Projektvertrags Der IT Projektvertrag muss geeignete Mittel wie ein regelm iges Reporting Teilabnahmen Verg tung nach Milestones etc vorsehen die eine zeitnahe regelm ige Kontrolle dieser Pr fpunkte erlauben Diese Fortschritts berwachung kann etwa durch Terminlisten oder Balkendiagramme durchgef hrt werden die im Intranet gef hrt und durch taggenaue Eintragung des Projektleiters aktuell gehalten werden den jeweiligen Soll und Ist Status aufzeigen geplante und tats chlich erreichte Termine und von der Gesch ftsleitung online jederzeit abgefragt werden K nnen Der Kunde sollte nach M glichkeit alle Leistungen aus einer Hand beziehen Schlie t er getrennte Vertr ge mit verschiedenen Anbietern tr gt er das volle Risiko deren Leisrungen zu koordinieren Werden mehrere Nutzungsrechte an der Software ben tigt sollten die Anzahl der Lizenzen Lizenz als Kurzbezeichnung verstanden im Sinne von urheberrechtlichen Nutzungsrechten und der jeweilige genaue Zeitpunkt des Beginns der Nutzungsberechtigung festgelegt werden ebenso die M glichkeiten und Kosten einer regul ren Nachlizenzierung Lizenzmanagement Zu kl ren und festzulegen ist auch auf welche u U automatisie
113. nagement Das gilt f r die Absicherung allgemein der betrieblichen IT und besonders der Webanbindungen die Angriffstore ffnen k nnen wobei das Risiko bei Wireless Komponenten besonders hoch ist Im Vertrag mit dem Dienstleister sind die Service Levels spezifisch f r jeden Security Bereich zu definieren Die Kostenkalkulation f r Outsourcing Projekte birgt erh hte Risiken da die Kosten f r Transaktionen Transformation und die enge Bindung an den Anbieter deutlich steigen k nnen und Kostenvorteile erst nach einer Anlaufzeit eintreten Auch die einzelnen Kostenpositionen sollten bereits anl sslich der Ausschreibung vergleichbar formuliert werden etwa Preis f r Mainframe Betrieb pro Stunde Help Desk pro Anruf oder pro Anwender im Monat pro PC im Monat pro Server mit 100 GB 700 GB 1 5 TB pro Monat Auch das Erstellen einer Ist und Soll Analyse und die Beschreibung und gar Erstanalyse vorhandener Gesch ftsprozesse sowie das Erarbeiten von Kontrollverfahren und en erfordert personellen und zeitlichen sowie kostenm igen Aufwand Zu kl ren kann auch sein wieviele Change Request noch von der vereinbarten Verg tung abgedeckt sind und welche Kosten f r zus tzliche Change Requests anfallen Beim Auslagern von IT gest tzten Organisationsprozessen werden die IT Systeme und Netze der auslagernden Organisation und ihres Outsourcing Dienstleisters in der Regel eng miteinander verbunden so dass Teile von internen Gesch ftsproze
114. nalyse des Ist Zustands und der Soll Anforderungen Soll Konzept auf Koch IT Projektvertr ge rechtssicher gestalten 5 Ist Analyse In der Ist Analyse sind die eingesetzten IT Komponenten und bestehenden Abl ufe mit den erkennbaren Schwachstellen z B zu sp te Rechnungsstellung h ufige Differenzen in der Vertrieb Me hohe Durchlaufzeiten in der Fertigung und lange Lieferzeiten im zu beschreiben Weiter sollte eine Bewertung es Ist Zustands erfolgen In der Beschreibung sind u a folgende Fragen zu beantworten Welche Gesch ftsprozesse wie z B Ausf hrung eines Fertigungsauftrags Abwicklung einer Kundenbestellung werden im Unternehmen eingesetzt M ssen dieselben Kundendaten mehrfach eingegeben werden Mit wievielen derartiger Auftr ge pro Zeiteinheit Tag Woche Monat Quartal ist zu rechnen und wird in der n heren Zukunft bei Nachfragesteigerungen zu rechnen sein um Reserven im Mengenger st festzulegen F r alle verwendeten Formulare und Belege sind die Datenfelder mit Bezeichnung von Inhalt und L nge Sortierkriterien Nummernsysteme z B Identnummern Aufbewahrungsfristen etc festzuhalten Zu kl ren ist welche Gesch ftsprozesse mit kosten a Standardsoftware in welchem Umfang abgedeckt werden k nnen Wer ist f r diese Prozesse zust ndig Aus welchen Komponenten besteht die IT Infrastruktur Welche Clients und Server sind vorhanden Wie sind diese konfiguriert Mengenger st Wo fallen welche D
115. nd nichtabschlie end auflisten Typische Risiken sind etwa e Vers umen einer unabh ngigen technischen Bewertung des Projektvorschlages u U zweites Angebot anderer Firma mit Angabe zur technischen Realisierung oder Kurzgutachten einholen Fehlerhafte Termins und Aufwandssch tzung Unrealistische oder nicht ausreichend gekl rte Projektziele Unverbindliche bzw vom Projektteam nicht akzeptierte Projektpl ne Unvollst ndige Ermittlung und Festlegung von Anforderungen keine Erstellung von Fachkonzept bzw Leistungsbeschreibung Kein einheitliches Verst ndnis der Kundenanforderungen und erwartungen e Festlegen von Aufwand Zielvorstellungen Vorgehen und Zeitplan bevor der Projektinhalt vollst ndig bekannt ist e Fehlendes oder unvollst ndiges bzw widerspr chliches Pflichtenheft e Fehlende oder unklare Vereinbarung ber die Modalit ten der Funktionspr fung z B vorg ngige Schulung bzw Einweisung Anwesenheit von Vertretern beider Vertragsparteien und F hren eines beiderseits zu unterzeichnenden Protokolls Erg nzungspr fung von Nacherf llungsarbeiten e Festpreisvereinbarungen ohne Anpassungsm glichkeiten e Fehlende Ressourcen beim Projektstart e bersch tzen der Leistungsf higkeit von Standardsoftware die mehr als erwartet Anpassungen notwendig macht und zu Kosten und Termins berschreitungen f hrt 7 Buchta EullSchulte Croonenberg Strategisches IT Management 72 Buchta EullSchulte Croonenbe
116. ne St rungsmeldung auf die n chsth here Stufe verwiesen wird F r jeden Level sind also etwa Rahmenbedingungen der DE aeebrmenns Voraussetzungen Ausnahmen Servicequalit t Verf gbarkeit Zuverl ssigkeit Antwortzeiten zwischen Ein und Ausgabe Zeit f r die Bearbeitung von Transaktionen etc Messmethodik H ufigkei ethode Verantwortung und Reporting Zeit Art Verantwortlichkeit festzulegen ebenso Arbeits und Bereitschaftszeiten sowie en ON ZEN von der St rungs Fehlermitteillung bis zum Beginn Bearbeitung und eine mittlere Zeitdauer f r die L sung von Benutzerproblemen bzw zul ssige Werte f r ein Degrading des Service f r die Dauer von Daten bertragungen die bertragungsgeschwindigkeit der Datendurchsatz Zeiteinheit und die Antwortzeit zwischen Eingabe eines Zen yud seine Wiedergabe auf dem Bildschirm oder die Dauer von M ngelbeseitigungen zu definieren F r den Kunden ist hierbei freilich letztlich nicht die Stufenfolge als solche entscheidend sondern nur ob und wann sp testens sowie unter welchem Kostenaufwand er eine Probleml sung Gadatsch IT Controlling in Tiemeyer Hrg Handbuch IT Management 359 375 Schneider CR 2004 241 246 Koch IT Projektrecht Rdn 228 a Koch Computer Vertragsrecht Rdn 949 Towle Bruggeman CRi 2002 75 76 Koch IT Projektrecht Rdn 229 127 2 boi IE Eu 2 SOR Verf gbarkeit wird definiert als Verh ltnis der Zeit in der der Dienst v
117. nformatik 451 mit dem Hinweis dass der Begriff Outsourcing aus outside und resource kombiniert wurde G Heymann Lensdorf Outsourcing Vertrag in Redeker Hrg Handbuch der IT Vertr ge Abschnitt 5 4 Rdn 2 StahlknechtlHasenkamp Einf hrung in die Wirtschaftsinformatik 452 2 Dietrich Schirra IT im Unternehmen 7 N N Koch IT Projektvertr ge rechtssicher gestalten 53 wenige durchg ngige Standards zu implementieren wird dachi an jedem zus tzlichen Programm und an jeder zus tzlichen Schnittstelle verdient Das gilt erst recht f r Auftraggeber die selbst in Zulieferketten integriert sind aber auf punktgenaue just in time erfolgende Produktionssteuerung mittels IT angewiesen sind Weiterer Vorteil ist eine bessere Steuerbarkeit der IT Kosten bzw Senkung dieser Kosten Abw lzung von Risiken auf den Outsourcing Anbieter Einsparung eigener p Praal Nachteile sind eine teilweise irreversible Abh ngigkeit vom Anbieter der teilweise Verzicht auf eigene IT Kompetenz sowie eine Verschlechterung der Verst ndigu wischen Fachabteilungen und Informationsverarbeitung die in fremden H nden liegt Naheliegend ist Outsourcing bei relativ eigenst ndigen Aufgaben etwa Auslagerung der IT Security in Managed Security Services z B Perimetersicherung Firewall Management Intrusion Detection Service Gateway Antivirenschutz sowie Bedrohungs und Patch Warnungen Identity und E Mail Service Ma
118. ng zwischen kundenseits zu erstellendem Lastenheft und anbieterseits zu erstellendem IT Pflichtenheft Schlie lich muss der Anbieter die erarbeitete L sung mit dem Kunden abstimmen allein schon weil die Beschreibung der L sung zu neuen Fragen und weiteren Anforderungen f hren kann In Business Cases bzw Use Cases Benutzerszenarien sollten alle m glichen Interaktionen mit dem System ber u ere Schnittstellen beschrieben werden Festzustellen ist welche Abh ngigkeiten zwischen Anforderungen bestehen Zu verfolgen ist au erdem ob alle Anforderungen in L sungsbeschreibungen und Testf llen abgebildet werden W hrend der Projektdurchf hrung sind auf jeder Stufe bestimmte Umsetzungsprozesse oder merkmale zu verfolgen 1 Projektdefinition Quellen f r nderungen 2 Systemanalyse Entwurf Analysestatus und Abdeckung 3 Implementierung Verifikation Status in Entwurf Code und Verifikation bei 1 bis 3 au erdem die nderungsh ufigkeit 4 Integration Status Qualit t 5 Systemtest Abnahme Status Abdeckung Akzeptanz 6 Auslieferung Wartung Feldfehler nderungen Diese Stufen sollten im IT Projektvertrag ausdr cklich vereinbart werden Die Durchf hrung von nderungen erfolgt als Change Management grunds tzlich nach ITIL und ISO IEC 20000 Als Change gilt jede Anderung an der IT Infrastruktur eines Uneren E Chanse Management soll die nderungsantr ge Requests for Change
119. ngs Pflegeverg tungen sollten wenn ein unterschiedlicher T tigkeitsumfang zu erwarten ist nicht pauschal sondern grunds tzlich mit Stundennachweis der Aktivit ten abgerechnet werden Erh hungen m ssen nicht in jeder H he akzeptiert werden Erh ht ein Anbieter nach Abschluss des Wartungsvertrages die Wartungsgeb hren um 700 ist dem Kunden nach 242 BGB ein Festhalten am Vertrag nicht zumutbar sondern besteht insoweit ein 165 Leistungsverweigerungsrecht Die Anzahl der tats chlich genutzten Lizenzen sollte genau kontrolliert werden nicht nur um unzul ssiges zus tzliches Vervielf ltigen zu verhindern sondern auch um bei Nichtaussch pfen eines gegebenen Rahmens eine Verg tungsreduzierung zumindest bei Vertragsverl ngerungen durchsetzen zu k nnen Upgrade Geb hren haben keine Grundlage im Urheberrecht wenn sie etwa bei einem erforderlichen Hardware Wechsel f r die Systemsoftware berechnet werden ohne dass f r den Kunden eine zus tzliche oder intensivierte Nutzung m glich ist Allerdings ist zu unterscheiden Hat der Kunde eine direkte Vertragsbeziehung zum Anbieter der Systemsoftware kann er aus dem berlassungsvertrag dennoch verpflichtet sein n mlich mit rein schuldrechtlicher Wirkung wobei bei Vorliegen eines Formularvertrages aber zu pr fen sein kann ob der Kunde durch eine solche Upgrade Verg tungsregelung i S v 307 Abs 2 BGB unangemessen benachteiligt wird Hat der Kunde hingegen ber ein Syste
120. nomieanforderungen e ben tigte Erweiterungsm glichkeiten Wird vom Auftraggeber das von ihm zu erbringende Lasten Pflichtenheft nicht erstellt scheitert hieran wie beim Unterbleiben der Spezifikation einzelner Funktionen die Auftragsausf hrung durch den Auftragnehmer nicht Der Auftragnehmer ist vielmehr gehalten eine Leistung zu erbringen die nach den En Grunds tzen dem Stand der Technik bei mittlerem Ausf hrungsstandard entspricht Zur Ausf llung be hender L cken ist auf die gew hnliche Verwendung der Software zur ckzugreifen die freilich bei l ckenhaft definierter individueller Anpassung ebenfalls schwer feststellbar ist Site Vorgaben an die Anwendung muss die Software vereinbarungsunabh ngig erf llen Checkliste zur Erstellung des fachlichen Lastenhefts Zielyorgabend e Vollst ndigkeit Sind alle relevanten Punkte gekl rt und notwendigen Informationen eingeholt e Korrektheit Sind die eingeholten Informationen von dritter Seite best tigt und im Lastenheft zutreffend dokumentiert e Aktualit t Sind die verwendeten Informationen Dokumente und Technologien aktuell Teilweise nach M ller Hengstenberg BVB Computersoftware 177 Balzert Lehrbuch der Software Technik Software Entwicklung 62 BGH Urt v 24 9 1991 X ZR 85 90 CR 1992 543 Vergessenes Pflichtenheft A Schneider v Westphalen Redeker Software Erstellungsvertr ge D Rdn 285 i Schneider v Westphalen Redeker Software E
121. o etwa das OLG K ln CR 1994 212 OLG K ln Urt v 29 7 2005 19 U 4 05 JurPC Web Dok 16 2006 OLG K ln NJW RR 1995 51f 1993 1529f 4 OLG K ln Urt v 29 7 2005 a a O Ausf hrlich s Koch Requirements Management IT Rechtsberater 7 2009 160 E Ebert Systematisches Requirements Management 17 Ebert Systematisches Requirements Management 39 Tiemeyer Hrg Handbuch IT Management 110 8 Koch IT Projektvertr ge rechtssicher gestalten Anforderungen ist mit dem Kunden eine Priorisierung durchzuf hren bei der die erfolgsentscheidenden Anforderungen vorangestellt werden Nach der berpr fung sollen im RM die so gepr ften und berarbeiteten Anforderungen selbst als verbindlich vereinbart und im sp ter auf dieser Basis zu erstellenden IT Pflichtenheft dokumentiert werden Alle w hrend des Projekts durchzuf hrenden Anforderungs nderungen sind ausdr cklich zu vereinbaren wobei der Anbieter auch das von ihm erstellte Pflichtenheft zu aktualisieren und die nderung in der Ausf hrung zu dokumentieren hat Parallel sollte der Kunde das von ihm erstellte Lastenheft regelm ig aktualisieren da es f r ihn die einzige Grundlage der Leistungsabnahme ur Bei l ngerlaufenden Projekten k nnen mehrere Anpassungsl ufe erforderlich werden amp Das Erstellen von Lasten und IT Pflichtenheften ist kein starr fixierter Ablauf sondern erfolgt bei Anbieter und Kunden jeweils in einem komplexen Prozess Diese Prozesse m
122. ogramm nderungen auf ihre m glichen Auswirkungen auf andere Teile des Programmes bzw auf andere Komponenten des Systems hin zu untersuchen Diese und sonstige Ma nahmen der Qualit tssicherung sind auch f r die Software Pflege durchzuf hren und zu dokumentieren Die Verg tung f r die Pflegeleistungen enth lt zumeist zwei Komponenten n mlich eine Pauschale f r regelm ige Kontrollen und das sonstige Instandhalten der Anlage und eine anlassbedingt berechnete Forderung aus Sonderkosten f r Material und Anfahrt Eins tze au erhalb der blichen Gesch ftszeit oder die Instandsetzung bei Fehlfunktionen die vom Kunden zu vertreten sind Die Pauschale f r die Pflege wird auch dann f llig wird wenn keine Leistung im jeweiligen Abrechnungszeitraum erforderlich war bzw der Kunde auf Wartungsleistungen verzichtet hat Werden Leistungen nicht in Anspruch genommen kann also der Kunde keinen Erstattungsanspruch geltend machen da das vertraglich geschuldete Werk die Erhaltung des m glichst wenig st ranf lligen Zustandes ist bzw das Vorhalten qualifizierter Leistungsbereitschaft ist c Auf Wartungs und Pflegeleistungen anwendbares Recht M ngelhaftung Leistungen aus Software Pflegevertr gen folgen immer dann Werkvertragsrecht wenn ein individuell definierter Leistungserfolg etwa eine Fehlerbeseitigung oder eine regelm ige Aktualisierung geschuldet ist Dienstyertragsrecht hingegen wenn eine qualifizierte T tigkeit zu er
123. olidierung von Datenbanken durch Zusammenlegen 12 IT Konsolidierung ist auch beim Merger von Unternehmen erforderlich da hier IT Abl ufe vereinheitlich werden k nnen und m ssen um etwa bi Gadatsch IT Controlling in Tiemeyer Hrg Handbuch IT Management 359 362 7 Zutreffend Welker Schmidt CR 2002 873 874 8 OLG Koblenz Urt v 27 5 1993 5 U 1938 92 CR 1993 626 NJW 1993 3144 LG K ln Urt v 16 10 1997 83 O 26 97 CR 1999 218 Unter einem Releasewechsel wird meist das Wechseln auf eine h here Version einer Standardsoftware verstanden Mit dieser Erh hung werden Fehler entfernt und Leistungsumfang und oder f higkeit erh ht 17 Ehrle Bukowski Computerwoche 17 2003 38 17 Sprott Froeber Computerwoche 25 2003 40 Koch IT Projektvertr ge rechtssicher gestalten 39 Inkompatibilit ten zu beseitigen und sich Synergien aussch pfen sowie etwa der Einkauf b ndeln lassen IT Konsolidierung ist als eigenst ndiges Projekt durchzuf hren Hierbei sind unter Ber cksichtigung der gesamten Nutzungsdauer Ist und erwartbare Soll Kostenstruktur zu vergleichen Sind im Vertragsverlauf fter M ngelbeseitigungen am System oder m ngelbedingte Updates erfolgt die jeweils eine Minderung gerechtfertigt haben 441 638 BGB so kann eine Verg tungsreduzierung im Umfange dieser Minderung durchsetzbar sein Gleiches gilt bei Einschr nkungen der Verf gbarkeit von Systemen Verwirkte Vertragsstrafen k nnen a
124. onvertierungsprogramme geschrieben werden sollten deren Erstellung mitunter mehr kostet als eine sonst in Betracht kommende Anpassung von Standard Applikationen Systemeinf hrungen und anpassungen sollten deshalb vom Punden genutzt werden um Hardware Applikationen Daten und Prozesse zu konsolidieren Bereits bei Vertragsschluss muss gekl rt sein ob der Anbieter f r die gesamte geplabte wirtschaftliche Nutzungsdauer ausreichend qualifizierte Hardware Wartungs bzw Software Pflegeleistungen vorhalten und zu markt blichen Konditionen anbieten wird Der zu beauftragende Anbieter muss deshalb f r diesen gesamten Zeitraum seine vorzuhaltende qualifizierte Leistungsbereitschaft im Systemvertrag garantieren und notfalls durch Erf llungsb rgschaften sichern Checkliste zur Erstellung des IT Pflichtenhefts Die Leistungsbeschreibung bzw das IT bezogene Pflichtenheft muss festlegen e die vom Auftragnehmer zu erbringenden Leistungen e die f r Abnahmef higkeit zu erf llenden Leistungsmerkmale e die Reihenfolge der Projektstufen mit Zeitplan Diese Inhalte lassen sich in folgender Weise aufgliedern Feinspezifikation der Funktionen Kosten Nutzensch tzung Projektwertanalyse Festlegung der Teilprojekte Arbeitspakete Unterlieferanten Verfeinerung der Projektpl ne endg ltige Leistungsbeschreibung Tiemeyer IT Architekturen planen und managen in Tiemeyer Hrg Handbuch IT Management 98ff Teilweise
125. operative Medien 2007 19 http mc informatik uni hamburg de konferenzbaende mc2007 konferenzband mc2007_04_Obendorf pdf 70 Koch IT Projektvertr ge rechtssicher gestalten Der Verzicht auf Pflichtenhefte bedeutet freilich nicht dass Entwickler einfach ins Blaue hinein codieren sollen bzw d rfen Vielmehr wird eine gemeinsame Grundvorstellung von der gew nschten Anwendung bzw den Gesch ftszielen vorausgesetzt deren Bezeichnung mit unscharfen Begriffen als Vision oder Metapher in XP freilich f r manche gew hnungsbed rftig ist Diese Zielvorgabe sollte soweit konkretisiert werden dass sich aus den Gesch ftszielen Anforderungen formulieren lassen und in etwa die Anzahl voraussichtlicher Iterationen absehbar und f r beide Vertragspartner kalkulierbar wird Bisher war dieses Ergebnis als fachliche Feinspezifikation bekannt Auch mit dieser Konkretisierung verbleiben Risiken Teilt man ein Projekt in viele Einzelschritte ohne bergeordnetes Gesamtdesign auf entsteht leicht das Risiko sich im Kes zu bewegen und dem ben tigten Programm zu langsam k n her zu kommen b Lauff hige Software statt Dokumentation IT Vertragsrechtler sind quasi von Anfang an mit der fundamentalen Bedeutung der Dokumentation sozialisiert worden Entsprechend schwer wird es ihnen fallen pauschal das Dokumentieren als verzichtbar behandeln zu m ssen Bei berlassung einer Standardsoftware ist der Anbieter grunds tzlich zur
126. pr fung und Vertragsstrafen Unver ndert bleiben hingegen meist Gew hrleistungs und Haftungsregelungen F lligkeitsvereinbarungen Nutzungsrechte und allgemeine Bestimmungen etwa zum Gerichtsstand 18 Koch IT Projektvertr ge rechtssicher gestalten Rahmenvertr ge werden in den F llen verwendet in denen meist gleichbleibende Regelungen quasi vor die Klammer gezogen werden Solche Rahmenvertr ge sind in der Regel allgemeine Gesch ftsbedingungen Rahmenvertr ge stellen aber noch keinen Auftrag dar sondern m ssen grunds tzlich durch Einzelauftr ge oder vertr ge ausgef llt werden Der Abschluss allein eines Rahmenvertrages begr ndet n mlich noch keine Leistungspflicht und verpflichtet als solcher auch nicht zur Erteilung bestimmter Einzelauftr ge Wird aber mit einem Vertrag unter dem Titel Rahmenvertrag eine st ndige Gesch ftsbeziehung aufgebaut und in ihm die Grundlage hierf r sowie die Abnahme einer Mindestzahl von Waren geregelt so liegt entgegen der Vertragsbezeichnung bereits eine verbindliche Bestellung vor Normalerweise regeln RAnIneny Trage n mlich nur bestimmte Einzelheiten erst k nftig abzuschlie ender Vertr ge i 3 Dokumentation der Anbieterleistung Der Anbieter muss die Abl ufe und Ergebnisse seiner Erstellungsleistungen dokumentieren Festzulegen ist welche Dokumentation der Auftraggeber beanspruchen kann Hier we zumindest f r gr ere Anwendungen vier Dokumentationstypen unterschie
127. r u erer bzw der Betriebserwerber bei einem Betriebs teilJ bergang die betroffenen Arbeitnehmer in Textform ber die in 613 a Abs 5 BGB aufgef hrten Punkte unterrichten Die 2 Vieh fer Selbst ist die Belegschaft ZEIT Nr 47 v 13 11 2003 22 Heise online 29 4 2003 Sechs Milliarden Euro durch IT Outsourcing verschwendet www heise de newsticker data ola 29 04 03 002 EN Vieh fer a a O en Grundlage ist die Ratsrichtlinie 77 187 EWG vom 14 2 1977 zur Angleichung von Rechtsvorschriften der Mitgliedstaaten beim bergang von Unternehmen Betrieben oder Betriebsteilen a EuGH Urt v 14 04 1994 Rs C 392 92 BB 1994 1500 Christel Schmidt er BAG AP BGB 613 a Nr 173 NZA 1998 536 Dieterich Hanaw Schaub Preis Erfurter Komm zum Arbeitsrecht 230 BGB 613 a Rdn 37 77 Gesetz zur nderung des Seemannsgesetzes und anderer Gesetze v 23 3 2002 BGBl 2002 I 1163 in Umsetzung von Art 7 Abs 6 der Richtlinie 2001 23 EG des Rates v 12 3 2001 zur Angleichung der Rechtsvorschriften der Mitgliedsstaaten ber die Wahrung von Anspr chen der Arbeitnehmer bei bergang von Unternehmen Betrieben oder Unternehmens oder Betriebsteilen ABl EG Nr L 82 v 22 3 2001 16 64 Koch IT Projektvertr ge rechtssicher gestalten Unterrichtung Set desArbeitgebers und begr ndet einen einklagbaren Auskunftsanspruch Zugleich haben Arbeitnehmer seit dem 1 4 2002 ein gesetzliches MIBETSDENCHSTECHE das freilich bereits von der Recht
128. r wechselseitigen Information und Absliniming E e Beendigungsunterst tzung durch Auftragnehmer bei Auslaufen des Vertrages or dentlicher K ndigung fristloser K ndigung Wechsel der Plattform Verpflichtung zur R ckgabe der Daten Sicherstellen der Remigrationsf higkeit Bereitstellen migrationsf higer Daten formate une R ck bernahme der Funktionen Backsourcing s unten eine Trennung vom Anbieter wird damit selbst zum Projekt Hier sind in der Praxis am h ufigsten Regelungsdefizite zu finden Hat sich der Auftraggeber im Wege des Betriebs Teil J bergangs von IT kompetenten Mitarbeitern getrennt kann ein Point of no return erreicht sein ab dem ein Backsourcing nicht mehr m glich ist Zu regeln ist auch ob eine R ck bertragung von Software erforderlich sein wird e Besondere Regelungen bei grenz berschreitendem und gar weltweitem Outsourcing etwa zu Leistungsort W hrung jeweils anwendbarem Recht und Gerichtsstand e Anwendbares Recht e Gerichtstand mie Sr Typische Fehler in Outsourcing Projekten Unvollst ndige oder unklare Leistungsbeschreibung unzureichende Beschreibung von Prozessen und Schnittstellen Auslagern ungel ster Probleme zu enger Zeithorizont unzureichend spezifizierte Projektziele und Messkriterien ungen gende Vorbereitung der Mitarbeiter insbesondere der IT Abteilung zu lange Vertragsbindung ungen gende Gr e des Dienstleisters unklare bzw unvollst ndige Regel
129. rf gbarkeit und Leistungszeitpunkte geregelt werden ebenso die Kontrolle mittels Reporting M glichkeit der jederzeitigen kundenseitigen Abfrage ber den aktuellen Stand durchgef hrter Ma nahmen das schnelle Beseitigen von BEISUHBESSUOUn SEN Reaktions und Wiederherstellungszeiten und Eskalationsprozesse geregelt werden Notwendig ist au erdem eine e klare Abgrenzung der verschiedenen Service Levels Leistungsspezifikation und der berg nge zwischen diesen F r jeden Level ist eine Qualit t oder einen Quantit tsstandard als messbare genau zu definieren e Festlegung von Sanktionen Verg tungsminderung bei kleinen Vertragsstrafen pauschalierter Schadensersatz bei mittleren und fristlose K ndigung bei erheblichen en bei Nichteinhaltung der f r die jeweiligen SLs geschuldeten Leistungsmerkmale z B Verf gbarkeiten Die Sanktionen k nnen entsprechend dem Ma der Abweichung gestaffelt werden von der relativ kleinen Verg tungsminderung ua gr ere Vertragsstrafen bis zur fristlosen K ndigung und oder Schadensersatz Weiter sind in SLAs zu regeln e Termine Fristen z B f r die Beseitigung kritischer St rungen e Konditionen Verg tungen Vertragsstrafen s o e Nachweis der Leistungserbringung durch Messung nachpr fbare Aufzeichnungen ber Art und Umfang der Leistungen e Reporting des Anbieters in regelm ige eitabst nden inwieweit vereinbarte Leistungsmerkmale eingehalten worden sind BGH Ur
130. rg Strategisches IT Management 145 152 1 Nach Dietrich Schirra IT im Unternehmen 66 67 Ausf hrlich s Koch IT Projektrecht Rdn 378 Teilweise nach M ller Hengstenberg Risikomanagement in DV Projekten CR 1999 789 f Streitz IT Projekte retten 70 163 Schneider v Westphalen Witzel Software Erstellungsvertr ge F Rdn 101 Koch Typische Risiken der Vertragsgestaltung f r EDV Projekte WiB 1997 178 HindellH rmann M ller Schmied Basiswissen Software Projektmanagement 30 Koch IT Projektvertr ge rechtssicher gestalten 4 e Untersch tzung der Komlexit t einer ben tigten L sung e Risiko zu langer Realisierungsphasen dass Anforderungen sich zwischenzeitlich mehrfach ndern Moving Targets oder neue Releases von Systemsoftware eingef hrt werden m ssen und hierdurch Anpassungen erforderlich werden Nichtbeachten der Abh ngigkeit der Projektphasen voneinander Unzureichende Durchf hrung Kontrolle der einzelnen Phasen Fehlen von nderungsverfahren Change Management Unzureichende Abnahmeregelungen Einsatz neuer Technologien ohne Referenzprojekte Nicht vorhandenes oder unzureichendes Krisenmanagement Gesamtfestpreis f r mehrstufige Projekte mit nicht klar abgegrenztem Leistungsumfang e Unklar definierte oder unzureichende kontrollierte Kundenmitwirkung z B unzureichend Schulung von Mitarbeitern oder unzureichende Aufr stung vorhandener Rechner Abh ngigkeit von verz g
131. rstellungsvertr ge D Rdn 286 Koch Handbuch Software und Datenbank Recht 5 Rdn 13 Nach Grevent Kr mker Unklare Ziele gef hrden Projekte Computerwoche 2 2005 30 14 Koch IT Projektvertr ge rechtssicher gestalten e FEindeutigkeit Werden die Begriffe einheitlich und eindeutig verwendet Werden sie von den Vertragspartnern in derselben Weise verstanden e Detaillierungsgrad Sind die Anforderungen ausreichend detailliert IT Pflichtenheft Auf der Basis des Lastenheft hat der Anbieter das technische Systemkonzept in der Form eines auf die IT bezogenen Pflichtenhefts zu erstellen Diese Erstellung ist entweder Teil des System oder Software Vertrags oder Gegenstand eines separaten Vertrages sein Im zweiten Fall muss die Auftragsausf hrung zus tzlich vereinbart werden Das Pflichtenheft legt die Sollbeschaffenheit der vom Anbieter geschuldeten Leistung fest 2 Das IT bezogene Pflichtenheft ist integraler Teil der Erstellungs oder Anpassungsleistung des Anbieters und kann meist nicht als getrennt abnahmef hige Teilleistung behandelt werden Der Kunde kann beim blo en Studium allein des IT Pflichtenheft n mlich oft nicht entscheiden ob es die zu erbringende Leistung richtig festlegt Zu vereinbarende Teilzahlungen sollten deshalb nicht an der Abnahme des IT Pflichtenhefts ankn pfen sondern an dessen bergabe nderungen des Inhalts des Pflichtenhefts en nur im klar geregelten nderungs Change Request verfahren
132. rte Weise zus tzliche Lizenzen in Benutzung genommen werden k nnen und die M glichkeit nicht mehr ben tigte Lizenzrechte m glichst rasch zu terminieren etwa durch K ndigung Auch die Herausgabe bzw Hinterlegung der dokumentierten Sourcen Quellformate der Software m ssen in der Verhandlungsphase vereinbart werden da ein diesbez gliches Nachverhandeln oft teuer kommt bzw ganz ausgeschlossen wird Herausgabe bzw Hinterlegung erledigen sich in den F llen in denen etwa eine Webseitenerstellung auf XML Basis erfolgt da der generierende Code jderzeit am Bildschirm im Browser eingesehen werden kann Sie scheitert au erdem soweit der Anbieter selbst Standardkomponenten Dritter einsetzt und hierf r ber keine Sourcen verf gt Der Abschluss des Projektvertrages setzt das Projekt in Gang und mit diesem die Haftung des Auftragnehmers f r die Erf llung der von ihm bernommenen Leistungspflichten Im abzuschlie enden Projektvertrag sollte erkennbar sein welche Regelungen individuell ausgehandelt wurden also nicht der Kontrolle nach AGB Recht unterliegen Dies kann dadurch geschehen dass vorbereitende Dokumente wie Ausschreibungsunterlagen Leistungsbeschreibungen oder Protokolle aus Verhandlungen etc dem Projektvertrag als Anlagen beigef gt werden Individuell ausgehandelt werden meist der Leistungsumfang die Leistungstermine Projektmanagement Qualit tskriterien und Qualit tssicherung Abnahmeverfahren Funktions
133. rung geholfen ist Berechnet das Programm z B Br ckenstatiken falsch ist das Minderungsrecht offensichtlich ungeeignet e Der Kunde kann Schadensersatz verlangen 634 Nr 4 1 Alt 636 280 281 283 311 a BGB oder Ersatz vergeblicher Aufwendungen 634 Nr 4 2 Alt 284 BGB Der Kunde muss pr fen welchen Weg er hier geht St tzt er seinen Schadensersatzanspruch auf die 634 Nr 4 281 BGB verlangt er Schadensersatz statt der Leistung Folge ist dass der Besteller keine weitere Projektleistung mehr verlangen kann 281 Abs 4 BGB Soll das Projekt weiterlaufen k nnen darf er also nur Schadensersatz aus den 634 Nr 4 280 BGB verlangen also neben der Leistung b Kundenrechte aus Kauf Der Kunde kann bei Anwendbarkeit von Kaufrecht Nacherf llung verlangen 437 Nr 1 439 BGB Der Kunde kann aus seiner K uferposition Mangelbeseitigung oder Lieferung einer mangelfreien Sache verlangen 439 Abs 1 BGB Der Anbieter hat kein Wahlrecht Er muss die erforderlichen Aufwendungen f r die Nacherf llung tragen 439 Abs 2 BGB W re die Nacherf llung nur mit unverh ltnism igem Aufwand m glich kann er sie verweigern 439 Abs 3 S 1 BGB 1 OLG K ln Urt v 14 2 2001 19 U 176 95 JurPC Web Dok 31 2002 48 Koch IT Projektvertr ge rechtssicher gestalten Bei Verweigerung Fehlschlagen oder Unzumutbarkeit der Nacherf llung wegen der Nacherf llungskosten kann der Kunde e vom Vertrag zur cktreten
134. senders informieren und Gelegenheit geben ihr Interesse an der Durchf hrung des Projekts zu erkl ren e Einen Request for Proposal RfP erhalten diejenigen Dienstleister die auf den Rfl geantwortet haben Der RfP soll die Regeln und den Ablauf des Auschreibungsverfahrens sowie die Entscheidungskriterien und Projektdaten wie Leistungsparameter Standorte Qualit tsanforderungen und Preiskonzepte mitteilen Konkrete Vertragverhandlungen werden vorbereitet Anbahnungsphase 311 Abs 2 Nr 1 BGB e Im Rahmen einer Due Diligence werden in der n chsten Phase s mtliche projektrelevanten Informationen und Vertr ge offengelegt wodurch besonderes Vertrauen in Anspruch genommen wird Der Dienstleister kann weitere erforderliche Informationen einholen und seine Leistungs nd Kostensch tzung konkretisieren e Nach Bewertung der Angebote wird in kompetitiven Vertragsverhandlungen mit einem oder zwei Finalisten bis zum Vertragsschluss verhandelt Die Auswahl des Outsourcing Anbieters sollte u a nach folgenden Kriterien erfolgen Vergleichbare erfolgreiche Referenzprojekte ITIL basierte Leistungsangebote Standortn he ausreichende Anzahl kompetenter Mitarbeiter gesicherte Kapitalst rke des Anbieters Die Leistungsbeschreibung sollte eine Auflistung aller betroffenen Assets umfassen f Phasen von Outsourcing Projekten Bei IT a pen Outsourcing Projekten werden zwei grundlegende Stufen unterschieden pu Der berleitungsteil
135. sponse Measurement Standardisierung der CECMG Central Europe Computer Measurement Group r Wesseler Computerwoche extra 5 6 7 2001 8 9 7 B rner Buhl HellmichlKlettIMoos Leitfaden IT Recht 57 8 ThurneriDal Cin Schneewei Verl lichkeitsbewertung komplexer Systeme Informatik Spektrum 21 1998 318 319 e Thurner Dal Cin Schneewei a a O 319 Baum CR 2002 705 707 Koch IT Projektrecht Rdn 241 32 Koch IT Projektvertr ge rechtssicher gestalten 10 _ Software Pflege und Hardware Wartung a Updates Versionen Upgrades F r Software Leistungen ist zu unterscheiden zwischen M ngelbeseitigungen im Rahmen der Gew hrleistung Fehlerbeseitigung als Pflegeleistung und kleinere Erweiterungen der Funktionalit t M ngelbeseitigungen und kleinere nderungen werden von Anbietern meist als Updates ausgeliefert Neue Versionen enthalten hingegen auch wesentlich neue Funktionsmerkmale Upgradesn demgegen ber Programmanpassungen f r leistungsst rkere Hardware oder Systeme Updates erfolgen meist einheitlich gegen ber der Gesamtheit der Kunden und nicht terminsgebunden damit die jeweilige Software Version einheitlich bleibt und weitergepflegt werden kann Soweit Fehler unter einer laufenden Gew hrleistung als M ngel zu werten sind kann in dem Zeitraum zwischen Mitteilung und Brnebung durch Update der Lauf der Verj hrungsfrist gehemmt sein 203 BGB In gr eren u ven jedes Upgrading von So
136. sprechung ausgebildet worden war Bei wirksamer und rechtzeitiger Aus bung des Widerspruchsrechts galt die Zustimmung zum bergang des Arbeitsverh ltnisses auf den neuen Petigbsinhahns als verweigert und bestand das alte Arbeitsverh ltnis zum Betriebsver u erer fort Das gilt auch nach neuem Recht wobei allerdings nun die einmonatige Widerspruchsfrist erst ab Zugang der ordnungsm igen Unterrichtung l uft 613 a Abs 6 S I BOB dies gilt auch dann wenn die Unterrichtung erst nach Betriebs bergang erfolgt Eine zeitliche Obergrenze wurde nicht umgesetzt Ist die Unterichtung also unvollst ndig oder berhaupt nicht erfolgt bleibt l ngerfristig ungewiss wieviele Arbeitnehmer bei dem Ver u erer bleiben Angeraten wird van gt enmi f r den Zugang eine Empfangsbest tigung unterzeichnen zu lassen F r den Widerspruch wird Schriftform verlangt 126 BGB also eigenh ndige Unterzeichnung 3 Agile Softwareentwicklung 3 1 Grunds tze a Risiken der Grundprinzipien Agile Softwareentwicklung soll helfen den Entwicklungsprozess zu beschleunigen und zugleich flexibler zu gestalten Im Manifesto Agile Software Development werden hierf r vier Grundprinzipien formuliert aa Dokumentation Eher formale Elemente wie vordefinierte Prozesse Dokumentationen Vertragsinhalte und Pl ne treten in den Hintergrund Risiko Die die Vertragsparteien verlieren mangels Pflichtenheft und Dokumentation das 7 WillemsenlLembke NI
137. sse fachliche Anforderungen e Mitwirken bei Tests Stellen von qualifizierten Personal insbesondere Projektleiter und Testdaten e Schaffen der erforderlichen Installationsvoraussetzungen und Internet Anbindungen etwa bei Outsourcing e Beschaffen erforderlicher Systemkomponenten soweit nicht vom Anbieter geschuldet Teilnahme ausreichend qualifizierter Mitarbeiter an Schulungen durch den Anbieter Vorbereiten und Durchf hren der Abnahme Umgehende vollst ndige Fehlermiteilungen auf Anbieterformularen Gew hrleisten von Datenschutz und sicherheit sowie Know how Schutz 7 Projektabnahme Die Projektdurchf hrung folgt grunds tzlich Werkvertragsrecht Die Werkleistung muss mit der Folge der F lligkeit der Verg tung und des Beginns des Laufes der Verj hrungsfrist vom Kunden abgenommen werden wenn sie im wesentlichen vertragsgerecht erbracht wurde 640 Abs 1 S 1 BGB Teile der Projektleistungen m ssen nur abgenommen werden wenn sie selbst ndig pr ff hig sind Am Projektende sollte dann eine Schlussabnahme erfolgen In einem Integrationstest ist festzustellen ob die verschiedenen Teile bzw Module der Anwendung miteinander lauff hig sind Die Wirkung fr herer Teilabnahme Billigung von Leistungsteilen als im wesentlichen vertragsgerecht kann r ckwirkend entfallen wenn der Integrationstest scheitert oder wenn nachtr glich Anpassungen an erbrachten Leistungsteilen durchgef hrt werden m ssen Im Rahmen
138. ssen Bei Customizing erfolgen die 714 Zu dem Problemkreis s Niemann Lizenzmodelle versagen bei indirektem Zugriff Computerwoche 22 2003 14 5 d h von Modulen bzw bei objektorientierten Programmen von Komponenten Stahlknecht Hasenkamp Einf hrung in die Wirtschaftsinformatik 298 52 Koch IT Projektvertr ge rechtssicher gestalten Se En allein durch Eintragen von Parametern in eine Vielzahl von Tabellen M glich ist aber teilweise auch erg nzende Programmierung cc Anwendbares Recht Die berlassung auch von ERP Software wird Kaufrecht jedenfalls in SREDIE ENGE Anwendung folgen wenn keine oder keine wesentlichen Anpassungen erfolgen M glich ist auch die Begr ndung einer vertraglichen Nebenpflicht zur Einrichtung Steht hingegen das Erstellen und Einrichten eines individuell definierten Gesch ftsprozesses im Vordergrund wird Werkvertragsrecht auf die Herbeif hrung dieses Zielstatus anzuwenden sein hnlich unterliegen auch individuelle Weiterentwicklungen etwa mit ABAP 4 unter R 3 Werkvertragsrecht Soweit Werkvertragsrecht anwendbar ist bedarf die jeweilige Leistung der Abnahme Sinnvollerweise ist diese Abnahme im Systemvertrag als Funktionspr fung auszuspezifizieren und festzulegen 2 Outsourcing a Grundkonzeption Als Outsourcing wird die Vergabe urspr nglich selbst wahrgenommener Aufgaben eines Unternehmens an andere Unternehmen bezeichnet als IT Outsourcing die Vergabe von einze
139. ssen unter Leitung und Kontrolle eines externen Dienstleisters ablaufen Ebenso findet auf personeller Ebene ein intensiver Kontakt statt Grunds tzlich Gleiches gilt f r die Ausgr ndung also die Auslagerung auf ein hierf r en eig Tochterunternehmen oder eine Beteiligungsgesellschaft Inhouse Outsourcing In beiden F llen sollte sichergestellt sein dass ausreichend fachliches Know how auf den Dienstleister bergehen kann ohne dass dieser freilich pl tzlich zum Marktkonkurrent wird Je Dietrich Schirra IT im Unternehmen 59 Hansen Neumann Wirtschaftsinformatik 1 130 Stahlknecht Hasenkamp Einf hrung in die Wirtschaftsinformatik 451 f O Verf Outsourcing will gut vorbereitet sein Computerwoche 38 2004 34 T Schott Die Kosten des Outsourcing Computerwoche 17 2006 34 5 Klotz Dorn Vertragsmanagement in der Informationsverarbeitung 21 54 Koch IT Projektvertr ge rechtssicher gestalten mehr Know how bergeht und je geringer die verbleibende IT Kompetenz ist desto gr er Kann die Abh ngigkeit vom Anbieter und ein Wechsel zu einem anderen Anbieter manchmal fast unm glich werden b Formen des Outsourcing Es k nnen sehr unterschiedliche Aktivit ten durch Outsourcing auf Dritte bertragen werden so etwa die Entwicklung von speziellen Applikationen die Auslagerung von von Datensicherungsabl ufen auf Auftragnehmer Storage und Archivierung Back up oder die Ausf hrung von Aufgaben ee Lohnbuchha
140. stem des Anbieters ist im Projektvertrag zu regeln und im Pflichtenheft darzulegen W hrend die Einrichtung des QS Systems allgemein den Normen EN ISO 9000 folgt m ssen f r die Software Erstellung fachspezifische Qualit tsnormen f r bestimmte Anwendungsbereiche gesondert bezeichnet und vereinbart werden Die Bedeutung einer Qualit tspr fung wird schnell deutlich wenn man ber cksichtigt dass Fehlerkosten etwa 80 bis 90 der gesamten Qualit tskosten ausmachen und die Kosten f r das Auffinden und Beseitigen von Fehlern in den Phasen Entwurf Realisierung Systemtest und Betrieb im Verh ltnis zu 1 8 15 60 stehen also geradezu exponentiell ansteigen Aus dem IT Pflichtenheft sind nun die S pezitkatipnen als Aufgabenstellungen f r die Programmierung auszuarbeiten IT Feinkonzept Dies ist typische Aufgabe des Anbieters Ziel muss es sein die IT optimal an die vorgegebenen fachlichen Anforderungen des Unternehmens anzupassen um dessen Wettbewerbsf higkeit zu sichern und m glichst zu verbessern IT Alignment Dies bedeutet freilich nicht den IT Einsatz auf das N tigste zu beschr nken und Projekte zur Neu und Weiterentwicklung radikal zusammenzustreichen da hierdurch gon die langfristigen strategischen Ziele des Unternehmens unterst tzt werden Allgemein m ssen die technischen und organisatorischen Strukturen der IT die Unternehmensziele optimal unterst tzen und die geplante k nftige Entwicklung des nn f rdern IT
141. t das Projekt in Projektphasen aufzuteilen in denen jeweils berpr fbare Leistungsergebnisse erzielt werden Im Vordergrund stehen hier weniger Neuerstellungs als Anpassungsarbeiten z B Parametrisierung und zus tzliche Programmierung Mit der n chsten Phase darf erst begonnen werden wenn die vorherige Phase durch den Anbieter nachgewisen erfolgreich abgeschlossen wurde b Vermeidung der bernahme historisch gewachsener Abl ufe Die Ion von einzelentwickelten historisch gewachsenen teils undokumentierten Abl ufen oft EDV Inseln genannt sollte m glichst vermieden werden da sie zu erheblichem Mehraufwand f hren kann teilweise sogar zu st ndigen Fehlerquellen an den Schnittstellen zur Standardsoftware etwa bei unterschiedlichen jedes Mal erst zu konvertierenden Datenformaten Soweit diese Integration aber unverzichtbar erscheint m ssen der mit ihr verbundene Aufwand etwa auch zur Erstellung erforderlicher Schnittstellen und die voraussichtlichen Auswirkungen auf Antwortzeiten der gesamten Applikation gepr ft werden c Vertragsgestaltung ERP Vertr ge sind meist komplex Oft werden Rahmen und Einzelvertr ge kombiniert teilweise auch Leistungsverzeichnisse und oder scheine angef gt Die Pr fung auf Vollst ndigkeit Widerspruchsfreiheit und AGB rechtlicher Zul ssigkeit muss hier grunds tzlich Klausel f r Klausel erfolgen Einzelne Klauseln werden oft individuell ausgehandelt z B ber Verf gbarkeiten
142. t f r Sicherheit in der Informationstechnik BSD ITIL und Informationssicherheit ITIL und Informationssicherheit Aspekte der Integration von Incident und Security Management Version 1 0 1 2006 Version 1 0 1 Sept 2006 www bsi bund de zit als BSI ITIL und Standards f r IT Prozesse Bundesamt f r Sicherheit in der Informationstechnik BSD ITIL und Standards f r IT Prozesse Prozess Standards f r die Entwicklung der IT Service Organisation gem ITIL Best Practices Version 1 0 1 herausgegeben von der Koordinierungs und Beratungsstelle der Bundesregierung f r Informationstechnik in der Bundesverwaltung KBSt Brief 1 2006 Okt 2006 www bsi bund de zit als BSI ITIL und Informationssicherheit Weitere Literatur Balzert Lehrbuch der Software Technik Software Entwicklung 2 Aufl 2001 Bettinger Scheffelt Application Service Providing Vertragsgestaltung und Konfliktmanagement CR 2001 729 Bl selPechardscheck Die rechtliche Absicherung von IT Outsourcing Projekten CR 2002 785 787 Blume Projektkompass SAP Arbeitsorientierte Planungshilfen f r die erfolgreiche Einf hrung von SAP Software 2 Aufl 1998 Bock Macek Oberndorfer Pumsenberger ITIL Zertifizierung nach BS 15000 ISO 20000 2006 B rner Buhl Hellmich Klett Moos Leitdaten IT Recht Ein Handbuch f r die Unternehmenspraxis2004 Braun Die Zul ssigkeit von Service Level Agreements am Beispiel der Verf gbarkeitsklausel 2006 Br ssler Siedersleben
143. t v 30 1 1986 I ZR 242 83 NJW 1987 1259 H Koch IT Projektrecht Rdn 210 u Schneider v Westphalen Peter Software Erstellungsvertr ge G Rdn 359 372 er Br utigam CR 2004 248 251 Braun Die Zul ssigkeit von Service Level Agreements 16 H rl H user CR 2003 713 717 Schreibauer Taraschka CR 2003 557 561 1 Koch IT Projektrecht Rdn 228 7 Gadatsch IT Controlling in Tiemeyer Hrg Handbuch IT Management 359 374 Schreibauer Taraschka CR 2003 557 560 30 Koch IT Projektvertr ge rechtssicher gestalten e Zul ssige Ausrei erquote e Einschwingphase Anlaufzeit in der SLA Kriterien noch nicht anwendbar sind Hinzukommen k nnen e die Verpflichtung zur Auslieferung von Updates in bestimmten zeitlichen Abst nden e zul ssige Wartungsfenster e Hotline e Bonus Regelung f r besonders gute Einhaltung der Leistungspflichten SLAs sehen vor dass St rungsmitteilungen auf verschiedenen definierten Kompetenzebenen Service Levels abgearbeitet bzw je bern St rungsart und komplexit t auf die n chst h here Ebene weiterreichen und als Leistungen unterschiedlich abrechnen Die Leistungen k nnen etwa auf Netzwerke Dr Hostuns Anwendungssoftware oder Kundenbetreuung Help Desks bezogen sein In solchen SLAs muss transparent festgelegt sein welche Levels angeboten und welche Leistungen auf welchem Level erbracht werden und unter welchen Voraussetzungen und in weicher Zeit sp testens f r ei
144. tallieren bevor das System in die Phase der produktiven Nutzung bergehen kann Go live Die en nanon ist wenn sie vom Anbieter durchzuf hren ist dessen zu verg tende Leistung S Leistungsbeschreibung Die Leistungsbeschreibung ist neben dem Projektvertrag das wichtigste Dokument im Projekt Die Leistungsbeschreibung sollte grunds tzlich m glichst alle relevanten Leistungsteile erfassen und konkret regeln Der Kunde muss Position f r Position durchpr fen und kontrollieren k nnen ob der Anbieter die jeweilige Leistung erbracht hat Auch der Auftragnehmer muss Interesse an einer solchen Leistungsbeschreibung haben da sie nicht nur festlegt was er zu leisten hat sondern auch was nicht mehr zum Ebert Systematisches Requirements Management 179 188 a Koch Requirements Management IT Rechtsberater 7 2009 160 162 Koch a a O 163 Koch a a 0 163 12 Koch IT Projektvertr ge rechtssicher gestalten Leistungsumfang geh rt und deshalb nur als zus tzlich zu verg tende Leistung erbracht zu werden braucht Ebenso sind die sp testen Leistungstermine mit Datum festzulegen Die Feststellungen aus dem Soll Status sind in die Leistungsbeschreibung aufzunehmen soweit die Leistungen vom Anbieter zu erbringen sind Vom Auftraggeber zu erbringende Mitwirkungsleistungen sind getrennt hiervon im Vertrag oder in einer Anlage zu diesem festzuhalten der Auftragnehmer sollte hier im eigenen Interesse diese Mitwirkungshan
145. tzen soll Mangelhaft ist die werkvertragliche Wartungs Pflegeleistung wenn die Anlage da System aufgrund der unzureichenden Arbeiten in einen st ranf lligen Zustand ger t das gilt auch f r Software Bei vereinbarter Instandhaltung Erhalten eines definierten Status der Funktionsf higkeit stellt bereits das Auftreten eines Fehlers einen Leistungsmangel dar Bei vereinbarter Instandsetzung l st der Fehler nach seiner kundenseitigen Mitteilung hingegen berhaupt erst die Leistungspflicht des Anbieters aus Von Wartungs Pflegearbeiten zu unterscheiden sind M ngelbeseitigungs ma nahmen die im Rahmen der M ngelhaftung f r die Erstellung berlassung der Software erbracht werden kostenfrei zu erbringen sind 635 Abs 2 439 Abs 2 BGB 7 F r die Anwendbarkeit von Dienstvertragsrecht auf sorgf ltig und regelm ig zu erbringende Wartungsleistungen s OLG Hamm Urt v 22 11 1988 25 U 5810 86 CR 1989 283f 8 LG Hagen Urt v 26 4 1988 21 O 159 87 CR 1989 814 So wurde etwa die ber einen Zeitraum geschuldete Bauaufsicht werkvertraglich eingestuft BGH NJW RR 1998 1027 Im EDV Bereich kann das Erhalten oder Wiederherstellen eines m glichst wenig st ranf lligen Zustandes ein werkvertraglicher Erfolg sein Palandt Sprau 59 A 2000 Einf v 631 Rdn 1lexplizit auch f r Wartung ber l ngere Zeit hinweg ebenso KG CR 1986 772 Computerwartungsvertr ge als Werkvertr ge mit Dauerwirkung M ller Hengstenb
146. u erdem st ndig vor Ort sein On site Customer und als Ansprechpartner f r fachliche Fragen permanent zur Verf gung stehen um in den kurzen u U t glichen Release Zyklen R ck u erungen geben zu k nnen Ein Pflichtenheft existiert nicht Es wird durch die Kundenantworten ersetzt Damit kann das Anforderungsprofil der Software und die Kostenkontrolle ins Flie en geraten Die Programmierung wird immer durch zwei Entwickler durchgef hrt von denen der eine codiert der andere berpr ft und analysiert Pair Programming Im Zweifel k nnen beide Entwickler Zeugen gegen den Kunden sein der deshalb u U doch den Inhouse Aufwand treiben muss seine u erungen gegen ber dem Anbieter zu dokumentieren oder akustisch aufzuzeichnen Die Entwicklung erfolgt testgetrieben Programm Units und Unit Tests werden stets parallel entwickelt die Tests also vor Implementieren des jeweiligen Der Ansatz wurde 2004 zu XP2 weiterentwickelt t BleeklWolf Agile Softwareentwicklung 2008 142 Hruschka Rupp Starke Agility kompakt 2 Aufl 2009 85 Hruschka Rupp Starke Agility kompakt 2 Aufl 2009 87 u HindellH rmann M ller Schmied Geplante Selbstorganisation in iX Kompakt IT Projekte 3 2009 80 83 j Bleek Wolf Agile Softwareentwicklung 2008 86 Balzert www w3l de W3lmedia W3L Medium164417 folien Wikipedia http de wikipedia org wiki Testgetriebene Entwicklung Koch IT Projektvertr ge rechtssi
147. ungen zur anbieterseitigen Unterst tzung bei Vertragsbeendigung e kein klar definiertes Reporting j Backsourcing Zutreffend wurde bemerkt dass eine R cknahme des Outsourcing au erordentlich schwierig ist tS Macht ein Unternehmen die Auslagerung von Aufgaben wieder r ckg ngig spricht man von Backsourcing bzw teilweise auch von Insourcing Gr nde sind mit Outsourcing verbundene Qualit tseinbu en h here Managementkosten durch mehr Koordinations und Ber uunssbedar l ngere Lieferzeiten und hierdurch bedingt kostspielige Lagerhaltung Beim Outsourcing Auftraggeber k nnen Kontroll und Informationsverluste eintreten und noch gravierender Kernkompetenzen in 9 HeymannlLensdorf a a O Abschnitt 5 4 Rdn 271f l Bj selPechardscheck CR 2002 785 790 2 Computerwoche 17 2004 28 29 7 Srahlknecht Hasenkamp Einf hrung in die Wirtschaftsinformatik 453 764 Etscheit Vorreiter des Insourcing ZEIT Nr 20 v 12 5 2005 32 Koch IT Projektvertr ge rechtssicher gestalten 63 I chen wie Rechnungswesen oder Informationstechnik abhanden kommen Im IT Bereich waren in 2001 noch 86 der Pr mit den Ergebnissen eines Outsourcing zufreiden in 2003 aber nur noch 50 Diese Schwierigkeiten finden auch zunehmend bei Controllern und B rsenanalysten Beachtung Nach einigen Untersuchungen soll jedes vierte Unternehmen an Fremdirmen vergebene Aufgaben wieder zur ckholen rezentralisieren m Ein
148. vertrag gilt die Verg tung dann als geschuldet wenn die Leistungserbringung nur gegen Verg tung zu erwarten ist 632 Abs 1 BGB Fehlt eine Vereinbarung zur Verg tungsh he so gilt die taxm ige Verg tung als vereinbart 632 Abs 2 BGB Grunds tzlich wird die Verg tung erst mit Abnahme f llig 641 Abs 1 S 1 BGB Der Anbieter kann jedoch f r in sich geschlossene und erbrachte Teile des Werkes Abschlagszahlungen verlangen 632 a BGB also etwa f r selbst ndig nutzbare Software Module die allerdings im wesentlichen mangelfrei sein m ssen Der Kunde wird die Vereinbarung von Festpreisen zu erreichen versuchen Festpreise werden meist nur f r mehr oder weniger standardisierte Leistungen etwa ein Customizing angeboten nicht aber f r vom Aufwand her schwer kalkulierbare Vorhaben individueller Software Erstellung oder etwa Altdaten bernahmen Allerdings besteht auch bei solchen Festpreisvereinbarung die M glichkeit einer ffnung Kommen n mlich zu den urspr nglich vereinbarten Leistungen erhebliche zun chst nicht vorgesehene Zusatzleistungen auf Veranlassen des Bestellers hinzu begr ndet dies unabh ngig Ka entsprechenden erg nzenden Einigung einen zus tzlichen Verg tungsanspruch n Zahrnt Projektmanagement von IT Vertr gen 25 E BuchtalEul Schulte Croonenberg Strategisches IT Management 60 Koch IT Projektrecht Rdn 113 ff Palandt Sprau B rgerliches Gesetzbuch 632 a
149. von Daten auf den verschiedenen Stufen eines Gesch ftsprozesses Ein Teil dieser Optimierungen kann durch Umorganisation erfolgen Business Reengineering die vor Erstellung des Lasten Pflichtenhefts durchzuf hren ist damit dieses nicht von einer inzwischen berholten Basis ausgeht Ein anderer Teil wird durch zu beschaffende neue Applikation zu leisten sein Die Anforderungen an diese m ssen komplett in der Leistungsvorgabe f r den Anbieter erfasst sein Die Ergebnisse aus dieser Soll Analyse sind in einem Fachkonzept darzulegen In das Fachkonzept sind alle Gesch ftsprozesse einzubeziehen Die Abl ufe m ssen aus der fachlichen Sicht m glichst genau beschrieben werden So muss es etwa m glich sein einem Besteller eine vorhandene Kundennummer zuzuordnen wenn der Besteller bereits fr her Bestellungen get tigt hat Weiter muss die Bearbeitung des Auftrags auch dann m glich sein wenn nur ein Teil der bestellten Produkte vom Lager ausgeliefert werden kann und der Rest erst nach Anlieferung durch den Zulieferer Soll der Kunde den Weg seiner Bestellung in ihrer Bearbeitung internetgest tzt mitverfolgen k nnen muss dies zus tzlich implementiert und gegen Bene Zugriffe oder gar unberechtigte nderungen abgesichert werden Unterschiedliche Formate der Kundendaten sind zu vereinheitlichen sind um sie durchg ngig bearbeiten zu K nnen Hieraus werden dann prim r die fachlichen Vorgaben und Anforderungen in einem Lastenheft im Sinne
150. w hrend gr ere Regelungsbereiche z B zu Nutzungsrechten Haftung Schutzrechten und anwendbaren Recht unver ndert bleiben und voll weiter AGB rechtlicher Kontrolle unterliegen Sd Zum Problem s Gadatsch IT Controlling in Tiemeyer Hrg Handbuch IT Management 359 399 401 Koch IT Projektvertr ge rechtssicher gestalten 51 Manche Begriffe bleiben in Anbietervertr gen unzureichend gekl rt Hierzu geh rt etwa der Begriff des indirekten Zugriffs auf die Programme also der Zugriff auf Daten mittels Drittsoftware etwa CRM Software Hier ist zu pr fen ob die Klausel durch Verwendung eines unzureichend definierten Begriffs intransparent und deshalb gem 307 Abs 1 S 2 BGB unwirksam ist Dies ist etwa denkbar wenn sich f r den Kunden nicht erkennen l sst I ie ein indirekter Zugriff ist und wie viele Benutzerlizenzen hierf r erforderlich sind e Customizing als Teil der vertraglichen Projektleistung aa Business Reengineering Erfahrungsgem treten bei ERP Projekten immer wieder Schwierigkeiten auf die vom ERP Softwareanbieter geschuldete Leistung zu definieren und von Beraterleistungen abzugrenzen wenn gleichzeitig auch Ma nahmen zum Business Re Engineering BE durchzuf hren sind Durch solche BE Ma nahmen wird n mlich h ufig die Ausgangsbasis ge ndert von der aus die Einsatzbedingungen f r die ERP Software festzulegen ist Die Anpassung der ERP Software an die Kundenbed rfnisse Customi
151. zel Betriebswirtschaftliche Anwendungen des integrierten Systems SAP R 3 1996 Gr fin v Westerholt Berger Der Application Service Provider und das neue Schuldrecht CR 2002 81 Zahrnt Projektmanagement von IT Vertr gen 2002
152. zing durch Wahl vorgegebener Parameterwerte ber Eintragung in ns im Bildschirmdialog Konfigurierung Auswahl gew nschter Programmbausteine amp in das Softwarepaket oder durch erg nzende Programmierung m ssen zur Vermeidung von unn tigen Wiederholungen des Customizing auf den Gesch ftsprozessen in ihrer re engineerten Form aufsetzen F hrt ein Berater zun chst bestimmte BE Ma nahmen durch sind die erzielten Ergebnisse genau und vollst ndig zu dokumentieren da die BE Ma nahmen die Ausgangsbasis f r das Customizing ndern Dem Anbieter m ssen bei seinem Leistungsbeginn derartige BE Ma nahmen mitgeteilt worden sein wenn er sie nicht selbst durchf hrt entdeckt er sie erst im Prozess der Leistungserbringung l sen solche Abweichungen in der Regel zus tzlich kostenpflichtige Changes aus Die Dokumentation des BE Zielstatus ist die Grundlage f r die ERP Projektimplementierung Diese Verkn pfung muss nicht nur organisatorisch soft waretechnisch sondern auch in den Vertr gen mit dem Berater und dem Software Anbieter tragf hig verkn pft werden M ngel oder L cken in der Dokumentation k nnen unmittelbar in die Projektrealisierung durchschlagen Die Beraterhaftung ist an diese Konstellation anzupassen sie sollte f r die Dauer des IT Projekts fortbestehen bb Customizing und Anpassungsprogrammierung ERP Software liefert gewisserma en Raster f r Gesch ftsprozesse die sich unternehmensspezifisch ausgestalten la
153. zwecks Installation geh ren nicht aber ein Bearbeiten Weiter Verbreiten oder ffentliches Zug nglichmachen Vorzuziehen ist freilich eine klarstellende Regelung welche Nutzungen in der Testphase durchgef hrt werden d rfen Festzulegen ist hier etwa auch die Anzahl der zugelassenen Arbeitspl tze bzw gleichzeitigen Zugriffsrechte im Testbetrieb Der Regelung bedarf auch das Vorgehen bei Scheitern der Abnahme das zu einem restlosen De Installieren der Software f hrt also etwa auch dem physikalischen L schen der Client Software auf den Arbeitspl tzen Erweist sich das Werk also insbesondere die Software oder deren nderung in der Abnahme Funktionspr fung als im wesentlichen vertragsgerech muss der Auftraggeber das Werk abnehmen 640 Abs 1 S 1 BGB Wegen unwesentlicher M ngel darf die Abnahme nicht verweigert werden 640 Abs 1 S 2 BGB freilich 8 Koch IT Projektrecht Rdn 191 m Schneider v Westphalen Redeker Software Erstellungsvertr ge D Rdn 236 28 Koch IT Projektvertr ge rechtssicher gestalten bestehen Nacherf llungsanspr che fort 634 Nr 1 635 BGB Dies muss grunds tzlich auch f r Teilabnahmen gelten Vorausgesetzt sind ausreichende PIOEDOSTEDRE N zumindest m ssen Probel ufe ein zufriedenstellendes Ergebnis erbracht haben Die Abnahme bewirkt e Konkretisierung des abgenommenen Werks Verlust des Rechts auf Neuherstellung bergang von Erf llungs zu M ngelanspr chen F lligwerd

2011 - Anwaltskanzlei Koch

Contents

Download Pdf Manuals

Related Search

Related Contents