IT-Vertragsrecht und agile Vorgehensmodelle –ein Widerspruch? · Auf einen Vertrag, der die...

Berlin DoSE 2012

IT-Vertragsrecht und agile Vorgehensmodelle – ein Widerspruch?

11. September | Berlin

Prof. Dr. Manfred Mayer | RA Günther Pinkenburg, LL.M.

INFORA Rechtsanwaltsgesellschaft mbH | München

2© INFORA Rechtsanwaltsgesellschaft mbH | München 2012


Agenda

• Die Erstellung von Individual-Software als IT-Projekt• Die Erstellung von Individual-Software als IT-Projekt

• Relevante (IT-) Vertragsformen• Relevante (IT-) Vertragsformen

• Die Verträge der öffentlichen Hand• Die Verträge der öffentlichen Hand

• Software-Entwicklungsmethoden• Software-Entwicklungsmethoden

• Umgang im Vergabeverfahren• Umgang im Vergabeverfahren


Agenda






5© INFORA Rechtsanwaltsgesellschaft mbH | München 201210.12.1010 5

Begriff des IT-Projekts

� keine klare Begrifflichkeit

� aber klare Vorstellungen der Beteiligten von IT-Projekten

� typische Inhalte� Lieferung Standardsoftware

� Herstellung von Individual-Software

� Anpassung von Software (ggf. mit Lieferung der anzupassenden Standardsoftware oder Beistellung der Standardsoftware durch den Kunden)

� Sonstige Zusatzleistungen, z.B. • Schulung/Einweisung

• Implementierung

6© INFORA Rechtsanwaltsgesellschaft mbH | München 201210.12.1010 6

Begriff des IT-Projekts

Tendenz der Praxis geht :

� weg von der Entwicklung von Individualsoftware (speziell füreinen Kunden)

� hin zur Anpassung und Implementierung von Standardsoftware.

� zu immer mehr neuen Projektmethodiken

� in Ablösung der klassischen Vorgehensmodelle

� oftmals schwerlich mit den rechtlichen Rahmen vereinbar



Vorgehensweise beim Phasenmodell

Ein typisches phasenweises Vorgehen, das sich an der Zweiteilung von Planung und Realisierung orientiert, kann – angelehnt auch an das „Phasenkonzept“ der BVB-Erstellung – wie folgt als lineares Phasenschema aussehen[1]:

(I) Planung - bislang Dienst-, nun Werkvertrag?(1) Idee, Gründung des Projekts

(2) Vorstudie(3) Grobkonzept

(4) Machbarkeitsstudie(5) Ist-Analyse

(6) Schwachstellenanalyse(7) Machbarkeit II (?)

(8) Fachliche Grobkonzeption(9) Technische Grobkonzeption ?

(10) Fachliche Feinspezifikation ( = Pflichtenheft?)(11) Technische Feinspezifikation (hier oder

bei Realisierung?)

[1] Siehe auch BVB-Erstellung; Müller-Hengstenberg, BVB/EVB-IT-Computersoftware, Erich Schmidt Verlag, 7. Auflage 2008;


Vorgehsweise beim Phasenmodell

(II) Realisierung - bislang Werkvertrags-, nun Kaufrecht?Evtl. erst hier: Technische Feinspezifikation/Realisierungsplanung

(12) "Programmierung" Quellcode(13) Einzeltests/Schreibtischtest

(14) Kompilierung/Object-Code(15) Integrationstests

(16) Dokumentation, Implementierung(17) Tests auf Testsystem (des Auftraggebers?)

(18) Tests auf Produktivsystem?(19) Abnahme-/Abschlussprüfung

Die vorstehenden Phasen veranschaulichen, wie lange der Weg zum Pflichtenheft sein kann.



„Pflichtenheft“

� Auftraggeber ist verantwortlich für die Beibringung des „Pflichtenhefts“ im Sinne von fachlichen Anforderungen

� Was ist ein "Pflichtenheft" im juristischen Sinne?

� Was ist ein Lastenheft, was ist eine Leistungsbeschreibung?


Lastenheft

Lastenheft:

� Beschreibt nach DIN/VDI die quantifizierbaren und prüfbaren Anforderungen aus Anwendersicht einschließlich aller Randbedingungen

�

� definiert: „Was und wofür soll der Anbieter eine Lösung erarbeiten

� erstellt Auftraggeber oder wird in dessen Auftrag erstellt.

� dient als Angebots- und Vertragsgrundlage, ebenso als Grundlage einer vergaberechtlichen Ausschreibung.


Pflichtenheft

Pflichtenheft :

nach DIN 69905:

• Festlegung des Auftragnehmers, wie er die vom Auftraggeber im Lastenheft beschrieben und geforderten Leistungen erbringen will

• Umfang kann variieren von reinem Projektstrukturplan (Minimum) bis zur vollständigen und detaillierten Projektplanung (ggfls. incl. Termin- Ressourcenpläne)


Typische „Projektsünden“

1. unklare Vertragstypologie

2. fehlende Projektstruktur

3. fehlendes, unvollständiges Pflichtenheft

4. Übernahme der Verantwortung für das Pflichtenheft durch den Auftragnehmer

5. unrichtiges Pflichtenheft / Prüfungspflicht des Auftragnehmers

6. fehlende Abnahmekriterien

7. fehlende Mitwirkung

8. fehlendes Änderungsmanagement

9. fehlende Dokumentation

Wann benötigt man einen Juristen? Wenn es Probleme gibt!


Agenda







IT-VertragsformenÜbersicht

�Beschaffung• Kauf

• Miete

• Lizenzerwerb

� Leistungserbringung• Werkvertrag

• Dienstvertrag

�Mischformen• Wartung

• Leasing

• Outsourcing, Outtasking

• Providing, Hosting

�Allgemeine Geschäftsbedingungen (AGB), besondere AGBs


Konstitutive Merkmale eines Werkvertrages

Werkvertrag

Folge

Erfolgsverant-wortung AN

Mitwirkungs-pflicht AG

Abnahme-prüfung

Leistung =abschließend

Zahlung nachAbnahme

Mängel-haftung


Werkvertrag, § 631 BGB

�Definition nach § 631 BGB(1) Der Unternehmer hat dem Besteller das Werk frei von Sach- und Rechtsmängeln zu verschaffen.(2) Das Werk ist frei von Sachmängeln, wenn es die vereinbarte Beschaffenheit hat. Soweit die Beschaffenheit nicht vereinbart ist, ist das Werk frei von Sachmängeln, 1. wenn es sich für die nach dem Vertrag vorausgesetzte, sonst 2. für die gewöhnliche Verwendung eignet und eine Beschaffenheit aufweist, die bei Werken der gleichen Art üblich ist und die der Besteller nach der Art des Werks erwarten kann. Einem Sachmangel steht es gleich, wenn der Unternehmer ein anderes als das bestellte Werk oder das Werk in zu geringer Menge herstellt. ...

�Abgrenzungsfragen• Zum § 651 BGB

• Zum Dienstvertrag § 611 BGB



Werkvertrag

Folge

Erfolgsverant-wortung bei AN

Mitwirkungs-pflicht des AG

Abnahme-prüfung


Zahlung nachAbnahme

Mängel-haftung


Werkvertrag, § 651 BGB

§ 651 Anwendung des Kaufrechts

�Auf einen Vertrag, der die Lieferung herzustellender oder zu erzeugender beweglicher Sachen zum Gegenstand hat, finden die Vorschriften über den Kauf Anwendung. § 442 Abs. 1 Satz 1 findet bei diesen Verträgen auch Anwendung, wenn der Mangel auf den vom Besteller gelieferten Stoff zurückzuführen ist. Soweit es sich bei den herzustellenden oder zu erzeugenden beweglichen Sachen um nicht vertretbare Sachen handelt, sind auch die §§ 642, 643, 645, 649 und 650 mit der Maßgabe anzuwenden, dass an die Stelle der Abnahme der nach den §§ 446 und 447 maßgebliche Zeitpunkt tritt.


Dienstvertrag, § 611 BGB

�Definition nach § 611 BGB(1) Durch den Dienstvertrag wird derjenige, welcher Dienste zusagt, zur Leistung der versprochenen Dienste, der andere Teil zur Gewährung der vereinbarten Vergütung verpflichtet.(2) Gegenstand des Dienstvertrags können Dienste jeder Art sein.

�Abgrenzungsfragen• Zum Werkvertrag

• Bezüglich Ergebnisverantwortung



Allgemeine und besondere Geschäftsbedingungen

Folge

Erfolgsverant-wortung AN

Mitwirkungs-pflicht AG

Abnahme-prüfung


Zahlung nachAbnahme

Mängel-haftung


Agenda







„Wirrwarr“ bei IT-Verträgen?

EVB-ITÜberlassung Typ A

EVB-ITÜberlassung Typ B

EVB-ITKauf

EVB-ITPflege S EVB-IT

InstandhaltungEVB-IT

Systemvertrag

BVB Planung

BVB PflegeBVB Miete

VOL/B ZVB

EVB-ITDienstleistung

EVB-IT System-lieferungsvertrag


Bezug EVB-IT im Internet www.cio.bund.de


EVB-IT Systemvertrag als Werkvertrag

Voraussetzung für Anwendung des EVB-IT Systemvertrages

�Schwerpunkt der vertraglichen Leistungen liegt beim EVB-IT Systemvertrag in der Erstellung (Werk) eines IT-Systems

• Herstellung von Produkten nach individuellen Vorgaben

• Integration von verschiedenen Leistungen

• Einbindung neuer Leistungen in vorhandene Systemumgebung

• Herbeiführung der Funktionsfähigkeit des Gesamtsystems

�Anwendungsbereich des EVB-IT Systemvertrages

• wenn Wert dieser (Werk-) Leistungen mehr als 16 % der Gesamtleistungen (= ca. ein Sechstel)

• falls Anpassungsleistungen eine essentielle Rolle spielen, ohne die das IT-System nicht oder nicht sinnvoll nutzbar ist

• Erstellung Individualsoftware


Überblick EVB-IT Systemvertrag

EVB-IT System – Vertragswerk

EVB-IT System(AGB)

Muster 3: Leistungs-nachweis

EVB-IT Systemvertrag Muster 4: Änderungs-verfahren

Muster 1:Vergütungs-

zusammenfassung

Muster 2: Störungsmelde-

formular


Gesamtverantwortlichkeit

Gesamtverantwortlich-keit des AN

1 2

43

� Leistungen des Nachunternehmers

� Seine eigenen Leistungen

� Leistungen des AG ?� Leistungen der Lieferanten


EVB-IT Systemvertrag – Inhalte (I)

�Gegenstand und Bestandteile des Vertrages

�Überblick

�Art und Umfang der Leistung

�Systemumgebung des Gesamtsystems/ Beistellungen

� Leistungen des Auftragnehmers zur Erstellung Gesamtsystem

�Systemservice: Aufrechterhaltung/Wiederherstellung der Betriebsbereitschaft

�Weiterentwicklung und Anpassung des Systems

�Ergänzende Vergütungsvereinbarungen bei Vergütung nach Aufwand

�Termin- und Leistungsplanung

�Zahlungsplan


EVB-IT Systemvertrag – Inhalte (II)

�Projektmanagement

�Weitere Pflichten des Auftragnehmers

�Mitwirkung des Auftraggebers

�Abnahme

�Mängelhaftung (Gewährleistung)

�Haftung

�Vertragsstrafen bei Verzug

�Weitere Vereinbarungen


Agenda








Neue ProjektmethodenWasserfall

Wasserfall-Modell

Das Wasserfallmodell ist ein lineares (nicht iteratives) Vorgehensmodell in der Softwareentwicklung, bei dem der Softwareentwicklungsprozess in Phasen organisiert wird. Dabei gehen die Phasenergebnisse wie bei einem Wasserfall immer als bindende Vorgaben für die nächsttiefere Phase ein.

Im Wasserfallmodell hat jede Phase vordefinierte Start- und Endpunkte mit eindeutig definierten Ergebnissen. In Meilensteinsitzungen am jeweiligen Phasenende werden die Ergebnisdokumente verabschiedet. Zu den wichtigsten Dokumenten zählen dabei das Lastenheft sowie das Pflichtenheft. In der betrieblichen Praxis gibt es viele Varianten des reinen Modells. Es war wohl das traditionell am weitesten verbreitete Vorgehensmodell.


Wasserfallmodell

Der Name „Wasserfall“ kommt von der häufig gewählten grafischen Darstellung der fünf bis sechs als Kaskade angeordneten Phasen. Bildlich lässt sich das Wasserfall-Modell daher wie folgt darstellen[1]:

[1] Vgl. http://de.wikipedia.org/wiki/Wasserfallmodell


V-Modell


V-Modell

Das V-Modell XT[1] (XT= Extreme Tailoring) ist ein flexibles Modell zum Planen und Durchführen von Systementwicklungsprojekten. Im Februar 2005 wurde das erste Release des V-Modell XT fertig gestellt und löste das V-Modell 97 ab.

Das V-Modell XT ist seit dem 15. Mai 2012 in der Version 1.4 erhältlich. Das V-Modell XT hat seit dem letzten Release nur wenige inhaltliche Änderungen erfahren, darunter die maßgebliche Überarbeitung des Vorgehensbausteins zur Systemsicherheit. Das V-Modell XT orientiert sich nun stärker an den Empfehlungen des Bundesamtes für Sicherheit in der Informationstechnik (BSI).

[1] Vgl. http://www.cio.bund.de/cln_093/DE/IT-Methoden/V-Modell_XT/v-modell_xt_node.html s.a. zu news: http://www.v-modell.iabg.de/

(Quelle: http://ftp.tu-clausthal.de/pub/institute/informatik/v-modell-xt/Releases/1.4/V-Modell-XT-Gesamt.pdf)


Agile Software-EntwicklungDefinition

„Agile Softwareentwicklung

ist der Oberbegriff für den Einsatz von Agilität (lat. agilis: flink; beweglich) in der Softwareentwicklung. Je nach Kontext bezieht sich der Begriff auf Teilbereiche der Softwareentwicklung – wie im Fall von Agile Modeling – oder auf den gesamten Softwareentwicklungsprozess – exemplarisch sei Extreme Programming angeführt.

Agile Softwareentwicklung versucht mit geringem bürokratischen Aufwand, wenigen Regeln und meist einem iterativen Vorgehen auszukommen“

Quelle: http://de.wikipedia.org/wiki/Agile_Softwareentwicklung


Agile Softwareentwicklung

Das Ziel agiler Softwareentwicklung ist es, den Softwareent-wicklungsprozess flexibler und schlanker zu machen, als das bei den klassischen Vorgehensmodellen der Fall ist.

Man möchte sich mehr auf die zu erreichenden Ziele fokussieren und auf technische und soziale Probleme bei der Softwareentwicklung eingehen.

Die Agile Softwareentwicklung ist eine Gegenbewegung zu den oft als schwergewichtig und bürokratisch angesehenen traditionellen Softwareentwicklungsprozessen wie dem V-Modell oder dem Rational Unified Process (RUP)



Inzwischen gibt es eine Vielzahl von agilen Prozessen. Zu denbekanntesten zählen unter anderem:

� Adaptive Software Development (ASD)� Crystal� Dynamic System Development Method (DSDM)� Extreme Programming (XP)� Feature Driven Development (FDD)� Pragmatic Programming� Scrum� Software-Expedition� Universal Application� Usability Driven Development (UDD)� Testgetriebene Entwicklung


Quelle: http://de.wikipedia.org/wiki/Agile_Softwareentwicklung




kurze Planungs- und Entwicklungsphasen wechseln sich ab.



Besonders wichtig: möglichst frühzeitiger Systemeinsatz



Scrum

Scrum (engl. für Gedränge) ist ein Vorgehensmodell mit

� Meetings,

� Artefakten,

� Rollen,

� Werten und

� Grundüberzeugungen, das beim Entwickeln von Produkten im Rahmenagiler Softwareentwicklung hilfreich ist. Teammitglieder organisierenihre Arbeit weitgehend selbst und wählen auch die eingesetztenSoftware-Entwicklungswerkzeuge und -Methoden. .......[1]

[1] http:// de.wikipedia.org/wiki/Scrum; s.a. http:// crum-master.de/


Scrum

Bei Scrum-Vorgehensmodellen sind folgende Begrifflichkeiten von wesentlicher Bedeutung:

Rollen: � Product Owner� Team� Scrum Master

Hierbei ist wiederum zu beachten:� Zusammenspiel� Zertifizierung


Scrum

Zyklusmodell:� Sprint – Umsetzung eines Iterationsschritts�Review�Retrospektive

Der Prozess:� Product Backlog (Produktanforderung des Kunden) >

> Sprint backlog >> Sprint >

> Working Increment.


Scrum

Bildlich lässt sich dieser Prozess wie folgt zusammenfassen:


Scheitern von IT-Projekten

Weitgehender oder gänzlicher Verzicht auf Pflichtenhefte

Ersetzung durch „gemeinsame Erarbeitung des Leistungskatalogs“, teils direkt am System selbst.

These:

Bei agilen Projektmethoden werden die Ursachen für das Scheitern zum Prinzip!


Zusammenfassung

Was muss man bei der Verwendung agiler Projektmethoden beachten:

1. Bezeichnung und Beschreibung der Software,zumindest nach Kernfunktionalitäten, Designanforderungen und dem mit der Software vom Auftraggeber verfolgten Zweck

2. Festschreibung des Verfahrens agiler Softwareerstellung nebst anzuwendender Methoden und der zu beachtenden Werte oder Prinzipien, insbesondere im Umgang der Beteiligten miteinander,


Zusammenfassung

3. Art und Umfang der Dokumentation, insb. bei einem ausdrücklichen Verzicht oder dem Erfordernis einer „klassischen“ Benutzer- und Entwicklerdokumentation,

4. Organisatorischer und zeitlicher Rahmen für die vom Auftraggeber einzubringenden Anforderungen, insbesondere bei Änderungsanforderungen, ggf. Festlegung von Fristen(Redaktionsschluss) und Freigabeverfahren,

5. Umfang, Anforderungen und Verantwortlichkeit für den Projektplan, ggf. nebst Aktivitäten- und Fristenplan, einschließlich Prozeduren, Abläufen und Verantwortlichkeiten (Entscheider, Kontrollgremium),


Zusammenfassung

6. Vom Auftraggeber konkret geschuldete Mitwirkungspflichtennach Art, Dauer, Häufigkeit und Umfang,

7. Anforderungen und Vorgehen bei Abnahme der Software, insbesondere Prüfungsmaßstab beim Verzicht auf Dokumentation, ggf. Festschreibung von Teilabnahmen und Gesamtabnahmeeinschließlich der Testszenarien und Testkriterien,

8. Risikoverteilung wegen nicht realisierbarer Funktionalitäten oder Designanforderungen, ggf. einschließlich Haftung des Auftragnehmers bei mangelnder Qualitätssicherung und Ausstiegsmöglichkeiten für den Auftraggeber,


Zusammenfassung

9. Vergütung nebst Regelungen über ggf. erforderliche Erhöhung bei bestimmten Änderungsanforderungen, die über den Vertragszweck hinausgehen oder nach Ablauf der vereinbarten Fristen geltend gemacht werden

10. Vorgaben für Datenschutz, IT-Sicherheit und Compliance beim Auftraggeber, die zwingend vor Beginn der Erstellung zu definieren und dem Auftragnehmer vorzugeben sind, sowie

11. Verfahren zur außergerichtlichen Streitschlichtung (Schieds- oder Schlichtungsverfahren) oder Mediation.


Zusammenfassung

12. Folgende vertragliche Regelungen werden empfohlen:

1. Vertragsgegenstand:

� Bezeichnung und Beschreibung der Software zumindest nach Kernfunktionalitäten, Designanforderungen zum vertraglich vereinbarten bzw. vorausgesetzten Zweck

� Konkrete Ausprägung, Verweis auf Anlagen, "Pflichtenheft" oder statt dessen auf das verwendete Verfahren

� Vertragstyp bzw. Kriterien für den Vertragstyp


Zusammenfassung

2. Zusammenarbeit der Vertragspartner, Projektorganisation, Projektvorgehen:

� Generell: Risikoverteilung

� Festschreibung des Verfahrens, hier agile Methodik nebst konkret anzuwendender Methoden

� Projektteams

� Lenkungsausschuss

� (De-)Eskalationsregelungen


Zusammenfassung

3. Mitwirkung des Auftraggebers, der generell zur Mitwirkung verpflichtet ist, auch wenn keine besonderen Regelungen hierfür im Vertrag zu finden sind.

� Wirkungspflichten und deren Ausprägung

� Mitwirkung im einzelnen zu regeln

� Regelungen, dass die Mitwirkung rechtzeitig abzurufen ist.


Zusammenfassung

4. Abnahme

� wer stellt das Testsystem,

� wann sind die Testcases/Szenarien zu zuliefern,

� welche Verbindlichkeit haben diese bzw. die Ergebnisse u.ä. Evtl. enthält der Vertrag noch. Damit ist die Schwäche der gesetzlichen Regelung der Mitwirkung nicht kompensiert, dass es sich insoweit nicht um Hauptpflichten handelt

� umso wichtiger wäre die exakte Regelung möglichst vieler Mitwirkungspflichten im Rahmen des Aktivitäten- und Fristenplans.


Zusammenfassung

5. Änderungsanforderungen, Verfahren zur Durchführung von Änderungen (Referenz?)

6. Fristen, Termine, Zeitplan

� Festlegung von Fristen

� Projektplan, Aktivitäten- und Fristenplan, Angabe der Verantwort-lichkeiten/Lead

7. Rechte, Rechtseinräumung + Übergaben, u.a. auch Quellcode


Zusammenfassung

8. Freigabe und Abnahmen

� Freigabeverfahren

� Teilabnahmen

� Gesamtabnahme

9. Vergütung und Zahlungsbedingungen

� Art der Vergütung

� Fälligkeit der Vergütung

10. Laufzeit, Kündigung, Beendigung und Folgen


Zusammenfassung

11. Sach- und Rechtsmängelhaftung

12. Schadensersatz

13. Rahmenbedingungen,

� u.a. Datenschutz (§ 11 BDSG) und Sicherheit

� Geheimhaltung

********************************

Pflichtenheft und Dokumentation

- Pflichtenheft entfällt

- Dokumentation entfällt


Agenda







Begrifflichkeiten der VOL/A 2009

VergabeunterlagenVergabeunterlagen

AnschreibenAnschreiben Bewerbungs-bedingungenBewerbungs-bedingungen

Beschreibung der

Durchführung des Verfahrens

Beschreibung der

Durchführung des Verfahrens

ggf. Angabe der Zuschlags-kriterien

ggf. Angabe der Zuschlags-kriterien

Eignungsan-forderungenEignungsan-forderungen

Vertrags-unterlagenVertrags-

unterlagen

Leistungs-beschreibung

Leistungs-beschreibung

Vertrags-bedingungen

Vertrags-bedingungen


LeistungsbeschreibungRechtlicher Hintergrund

§ 7 VOL/A – Die Leistungsbeschreibung

(1) Die Leistung ist eindeutig und so erschöpfend zu beschreiben, dass alle Bewerber die Beschreibung im gleichen Sinne verstehen müssen und das miteinander vergleichbare Angebote zu erwarten sind (Leistungsbeschreibung).

(2) Die Leistung oder Teile derselben sollen durch verkehrsübliche Bezeichnungen nach Art, Beschaffenheit und Umfang hinreichend genau beschrieben werden.

(…)


Leistungsbeschreibung

Kernstück der Vergabeunterlage

�Die Regelung der §§ 7, 8 EG VOL/A zählt zu den Zentralnormen des Vergaberechts. Sie stellt nicht nur inhaltliche Anforderungen an die Beschreibung der Leistung, die als "invitatio ad offerendum" den wesentlichen Inhalt des zu schließenden Vertrages bestimmt, sie hat auch maßgebliche Bedeutung für die Auslegung der Vertragspflichten (BGH, Urteil v. 11.5.2009 – VII ZR 11/08)

� § 8 EG Abs. 1 VOL/A ist darüber hinaus unmittelbarer Ausfluss der in § 97 Abs. 1 und 2 GWB enthaltenen Grundsätze einer transparenten, die Bieter gleich behandelnden Vergabe im Wettbewerb (2. VK Hessen, B. v. 26.04.2007 - Az.: 69 d VK - 08/2007).


Rechtlicher Hintergrund

� Die Vorschrift zielt darauf ab, den Bietern eine klare

Kalkulationsgrundlage zu liefern

� Zugleich hat sie den Zweck, die Vergleichbarkeit der Angebote zu

sichern. Soweit Leistungen wegen ersichtlicher Unausführbarkeit

nicht verlässlich kalkuliert werden können, stellen sie keine

hinreichende Basis für einen Vergleich der Angebote dar.

� Eine unzutreffende Leistungsbeschreibung kann insoweit

Bieterrechte verletzen

(VK Südbayern, B. v. 08.06.2006 - Az.: 14-05/06)


Leistungsbeschreibung –Kernstück der Vergabeunterlage

� Alle beeinflussenden Umstände müssen angegeben sein!

� Möglichst keine Auslegungsmöglichkeiten aus Bietersicht

� Chancengleichheit und realistische Kalkulationsbasis

� Unklarheiten führen zu Risikoaufschlägen

Die Leistung ist eindeutig und so erschöpfend zu beschreiben, dass alle Bewerber die Beschreibung im gleichen Sinne verstehen müssen und das miteinander vergleichbare Angebote zu erwarten sind (Leistungsbeschreibung).


Funktionale Leistungsbeschreibung (I)

�Befolgung des Grundsatzes, dass Ausschreibungen durch eine

Darstellung ihres Zwecks, also aufgabenbezogen, erfolgen

�Hauptmerkmal: Die Vergabestelle gibt eine Übersicht der geforderten

Funktionen vor

�Empfehlenswert, wenn die Vergabestelle nicht in der Lage ist, die

gewünschte IT-Leistung technisch näher zu beschreiben

�z.B. Beschaffung systemnaher Software wie Dienstprogramme,

Entwicklungswerkzeuge (Tools) oder Beschaffung größerer IT-Objekte

(etwa komplettes Client-Server- / Workflow-System)


� Im Ergebnis wird nicht die Art und Weise der technischen Umsetzung

vorgegeben, sondern die geforderte Funktion oder das erwartete

Ergebnis

(z.B. performanter Betrieb einer zu liefernden HW und SW in einer

bestimmten technischen Umgebung) durch eine detaillierte

Beschreibung erläutert

Funktionale Leistungsbeschreibung (II)


Relevante Vergabearten

VergabeartenVergabearten

EU-weitEU-weit NationalNational

offenes Verfahrenoffenes Verfahren

nicht offenes Verfahrennicht offenes Verfahren

VerhandlungsverfahrenVerhandlungsverfahren

Öffentliche AusschreibungÖffentliche Ausschreibung

Beschränkte AusschreibungBeschränkte Ausschreibung

Freihändige VergabeFreihändige Vergabe

Wettbewerblicher DialogWettbewerblicher Dialog DirektkaufDirektkauf


Vergabe-vorbereitung

Beschaffungsbedarf

Markterkundung, Marktübersicht

Festlegung der Vergabeart; hier: Verhandlungsverfahren

Festlegung der Beschaffungsstrategie Phasen? Abschichtung? Verhandlungsgegenstand?

Vergabeunterlagen, Leistungsbeschreibung, Vertragsentwurf, Bewertungsschema, Wertungskriterien

Ablauf des Verhandlungsverfahrens


Vergabe-durchführung

Bekanntmachung

Teilnahmewettbewerb

Eignungsprüfung und Bieterauswahl

„Angebotsphase“ ggf. mit Abschichtungen

Bewertung, Verhandlungsrunden und Endbewertung der Angebote unter dem Aspekt der Wirtschaftlichkeit

Ablauf des Verhandlungsverfahrens


� Ausnahmeverfahren in der VOL/A gemäß § 3 EG Abs. 3 und 4 VOL/A

� Achtung:Sorgfältige Prüfung der Voraussetzungen

� Dokumentation der Begründung für die Auswahl der Vergabeart ist erforderlich

� Regelverfahren in der VOF (§ 3 VOF)

� Grundsätzlich mit Teilnahmewettbewerb (Vergabebekanntmachung)

� In Ausnahmefällen kann auf den Teilnahmewettbewerb verzichtet werden. (Ausnahmefälle: siehe § 3 EG Abs. 4 VOL/A bzw. § 3 Abs. 2 VOF)

� Grundsätzlich besteht die Pflicht zur Durchführung von Verhandlungen!

Ausnahmetatbestände für die Anwendung des Verhandlungsverfahrens

Verhandlungsverfahren


Grundsätze des Verhandlungsverfahrens

Besondere Kennzeichen des Verhandlungsverfahrens

� Besonders geeignet für komplexe Vergabeverfahren� Beschränkter Bieterkreis (mindestens 3)� im Wesentlichen formlose Durchführung �� Auftraggeber kann Verfahrensphasen selbst definieren

� ABER: i.d.R. längere Verfahrensdauer mit höherem Aufwand für Durchführung und Dokumentation

� VERHANDLUNGEN über den Auftragsinhalt und über die Preise sind Pflicht �� ABER: Der einzelne Bieter hat keinen Anspruch auf Verhandlungen

� Stärkere Flexibilität sowohl auf Auftraggeber- als auch auf Auftragnehmerseite


Unterschiede zu förmlichen Verfahren

• Leistungsgegenstand ist noch nicht von Beginn an unabänderlich festgelegt

• Angebote können verändert und verhandelt werden• Trotzdem müssen die Grundprinzipien des Vergaberechts eingehalten

werden!

�� Besondere Anforderungen an Dokumentation und Mitteilungspflichten

• Transparenz

• Gleichbehandlung / Chancengleichheit

• Wettbewerb

• Keine Diskriminierung

Grundsätze des Verhandlungsverfahrens


Durchführung von Verhandlungen

Was sind Verhandlungen?

� Verhandlungen = Diskussion zwischen AG und AN über Auftragsinhalte, Rahmenbedingungen, Konditionen etc. mit dem Ziel, die konkrete Leistung und den Angebotspreis verbindlich festzulegen

� Leistungsgegenstand, Preise und Angebote können während der Verhandlungen abgeändert werden

� Kein Bieter hat einen Anspruch auf Verhandlungen �� AG hat Ermessensspielraum, wer an Verhandlungen beteiligt wird

� ABER: Basis sind Gleichbehandlung, Transparenz und Diskriminierungsfreiheit


Durchführung von Verhandlungen

Worüber darf verhandelt werden?

� Über Angebote der Bieter, die konkretisiert werden; alternativ Vergabeunterlage, in welche Bieterangebotspassagen integriert werden

� Vertragswerk

� Preisblätter

� Wichtig: Nach Zuschlag wird Vertrag zum führenden Dokument

� Auftragsgegenstand muss zwar nicht zu Verfahrensbeginn komplett definiert sein, aber Eckpunkte sind zu fixieren

� Es darf nicht eine andere Leistung bezuschlagt werden, als ausgeschrieben wurde

� Angebote sind an veröffentlichter Bewertungsmatrix zu messen!


Relevante Vergabearten

VergabeartenVergabearten

EU-weitEU-weit NationalNational

offenes Verfahrenoffenes Verfahren

nicht offenes Verfahrennicht offenes Verfahren

VerhandlungsverfahrenVerhandlungsverfahren

Öffentliche AusschreibungÖffentliche Ausschreibung

Beschränkte AusschreibungBeschränkte Ausschreibung

Freihändige VergabeFreihändige Vergabe

Wettbewerblicher DialogWettbewerblicher Dialog DirektkaufDirektkauf


Wettbewerblicher Dialog- § 3 EG Abs. 7 VOL/A -

�Wettbewerblicher Dialog• nur für „besonders komplexe“ Leistungen

• EU-weites Verfahren

• zulässig, wenn AG objektiv nicht in der Lage ist, die technischen Mittel anzugeben, mit denen seine Bedürfnisse und Ziele erfüllt werden können oder

• die rechtlichen oder finanziellen Bedingungen desVorhabens anzugeben

• Ablauf in 3 Phasen (Teilnahmewettbewerb, Dialogphase, Angebotsphase)

�Wichtig:• Wenn beim wettbewerblichen Dialog die Zahl der Bieter verringert

werden soll, so ist dies in der Bekanntmachung anzukündigen.


Wettbewerblicher Dialog

Kriterien PRO: Besondere Komplexität von IT- und Outsourcingprojekten

1. Umfangreiche Forschungs- und Entwicklungskomponenten(keine Lösung von der Stange; z. B. Aufbau spezieller Verwaltungsnetzwerke, E-Government-Applikationen)

2. Vorliegen vieler verschiedener Wege zur Lösung der Aufgabe(je größer das Spektrum der Lösungsansätze, desto umfassender die Evaluierung und damit die Komplexität der Ansätze)

3. Erhöhtes Maß an Unsicherheit(Tempo und Dynamik der technischen Entwicklung bei HW und SW)

4. Großes Maß an Kooperation zwischen den Beteiligten(großer Abstimmungsbedarf zwischen Vertragspartnern z.B. bei Abbildung & Neugestaltung von Verwaltungsprozessen in einer IT-Architektur)


Wettbewerblicher Dialog

Phasen

Ermittlung des wirtschaftlichsten Angebotes

Teilnahmewettbewerb (Eignung)Fachkunde, Leistungsfähigkeit, Zuverlässigkeit,

Gesetzestreue

Teilnahmewettbewerb (Eignung)Fachkunde, Leistungsfähigkeit, Zuverlässigkeit,

Gesetzestreue

Dialogphasemit den geeigneten Unternehmen zur Ermittlung und

Festlegung der besten Bedarfsbefriedigung, Bestimmung der Einzelheiten des Auftrags

Dialogphasemit den geeigneten Unternehmen zur Ermittlung und

Festlegung der besten Bedarfsbefriedigung, Bestimmung der Einzelheiten des Auftrags

AngebotserstellungAngebotserstellung

AngebotsbewertungAngebotsbewertung


Fazit

Die Entwicklung von Individual-Software mittels agiler Methoden

und

das geltende Vergaberecht

schließen sich nicht gegenseitig aus!

Keine Scheu vor Ausschreibungen der öffentlichen Hand!


Agenda






Vielen Dank für Ihre Aufmerksamkeit!

Prof. Dr. Manfred Mayer

RA Günther Pinkenburg, LL.M.

INFORA

Rechtsanwaltsgesellschaft mbH

Willy-Brandt-Platz 6

81829 München

Tel 089 45108896-0

Fax 089 45108896-9

[email protected]

www.infora-rag.de

Date post:	09-Jun-2020
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

IT-Vertragsrecht und agile Vorgehensmodelle –ein Widerspruch? · Auf einen Vertrag, der die...

Documents