E-Vergabe – Wem sind Probleme bei der elektronischen Angebotsabgabe zuzurechnen?

VergaberechtIn Zeiten der Papiervergabe war es ein Standardproblem – Angebote, die nicht rechtzeitig vorlagen. Die rechtliche Lösung war einfach: Das Übermittlungsrisiko beim postalischen Versand hatte der Bieter zu tragen, d.h., auch für Fehler des Postunternehmens musste der Bieter die Konsequenzen tragen. Der Postdienstleister war Erfüllungsgehilfe (§ 278 BGB) des Bieters. Nur wenn die Zustellungsschwierigkeiten ausnahmsweise in der Sphäre des Auftraggebers begründet waren, weil z.B. eine postalisch nicht existierende Adresse genannt wurde oder die Angebote in der Hauspost des Auftraggebers verloren gingen, hatte der öffentliche Auftraggeber die Folgen zu verantworten.

Theoretisch dürften verspätete Angebote bei der E-Vergabe nicht mehr vorkommen. Weder sollten in der elektronischen Kommunikation unkalkulierbare Postlaufzeiten auftreten, noch Angebote verloren gehen. Aber die Praxis lehrt uns: Auch in Zeiten der E-Vergabe kann es bei der Angebotsabgabe zu Problemen kommen. Der folgende Beitrag von Hrn. Prof. Dr. Christopher Zeiss (Fachhochschule für öffentliche Verwaltung NRW) und Hrn. Carsten Klipstein (u.a. Geschäftsführer der cosinex) will aufzeigen, wer bei der E-Vergabe für Probleme bei der Abgabe von E-Angeboten in unterschiedlichen Fallkonstellationen haftet.

1. Fehler des Bieters

Einfach ist die Beurteilung, wenn die Verspätung auf einem Fehler des Bieters oder eines seiner Erfüllungsgehilfen beruht. Dies betrifft etwa Fälle, bei denen der Bieter erst die sprichwörtlichen fünf Minuten vor Ende der Angebotsfrist mit der Übermittlung umfangreicher Datensätze beginnt, einen nicht vom Auftraggeber bzw. dessen Vergabeportal vorgesehenen (und später ggf. nicht XVergabe-kompatiblen!) Bieter-Client oder eine veraltete Version des Bieter-Clients verwendet (sofern die eingesetzte E-Vergabeplattform dies nicht unterbindet). Für solche Organisations- und Bedienungsfehler haftet natürlich – wie in Zeiten der Papiervergabe – der Bieter.

In der E-Vergabe trifft den Bieter möglicherweise auch die Obliegenheit, ggf. den Bieter-Client bzw. das „Bieter-Cockpit“ der E-Vergabe-Lösung zuvor zu testen. In einer Entscheidung der VK Baden-Württemberg (Beschl. v. 30.12.2016 –1 VK 51/16 – dazu: http://blog.cosinex.de/2017/04/07/vk-baden-wuerttemberg-kein-ausschluss-von-angeboten-bei-technischen-problemen/ – auf die wir noch mehrfach zurückkommen werden) hatte der Bieter sich jedenfalls vorbildlich verhalten. So hat die VK wiederholt darauf abgestellt, dass der Bieter bereits in der Vergangenheit erfolgreich Angebote elektronisch über die gleiche E-Vergabeplattform eingereicht hatte und zwei Tage vor Ablauf der Angebotsfrist nochmals einen Test durchführte.

Auch wenn der vorgenannte Beschluss der VK Baden-Württemberg letztlich – hier aber aus anderen rechtlichen Erwägungen – vom OLG Karlsruhe (Beschl. v. 17.03.2017, 15 Verg 2 / 17) „kassiert“ (dazu unten 8.) wurde, gibt er wichtige Hinweise für die Praxis.

2. Störungen des Internetanschlusses des Bieters

Der Bieter haftet auch für Funktionsstörungen seines Internetanschlusses – oder wenn er noch immer eine zu langsame Internetverbindung hat. Wie in Zeiten der Papierabgabe trägt der Bieter grundsätzlich das Übermittlungsrisiko. Wer weiß, dass er einen langsamen oder störanfälligen Internetanschluss hat, darf Angebote nicht erst „auf den letzten Drücker“ absenden, sondern muss rechtzeitig mit den Übermittlungsversuchen beginnen.

Was eine „rechtzeitige“ Angebotsabgabe ist, lässt sich im Zweifel erst anhand der Umstände des konkreten Einzelfalls beurteilen. Immerhin ist aber auch hier der bereits oben erwähnten Entscheidung der VK Baden-Württemberg ein Musterbeispiel für Bieterverhalten zu entnehmen. Der Bieter hatte seine ersten Versuche zur Übermittlung des Angebots bereits am Tag vor Ende der Angebotsfrist gestartet.

3. Funktionsstörungen des E-Vergabeportals

Zwar trägt der Bieter auch in Zeiten der E-Vergabe das Übermittlungsrisiko, aber nicht mehr bis zum physisch-realen Briefkasten des Auftraggebers, sondern nur bis zu dessen virtuellen Briefkasten– und dieser kann in Gestalt des E-Vergabeportals bzw. dessen Bieter-Client gleichsam im Büro des Bieters stehen. Im Klartext: Fehler des Vergabeportals sind jedenfalls dem Auftraggeber zuzurechnen (VK Baden-Württemberg, Beschl. v. 30.12.2016 –1 VK 51/16 – dazu: http://blog.cosinex.de/2017/04/07/vk-baden-wuerttemberg-kein-ausschluss-von-angeboten-bei-technischen-problemen/). Das Vergabeportal entspricht dem Briefkasten des Auftraggebers. Bei der Papiervergabe war es dem Auftraggeber zuzurechnen, wenn sein Briefkasten nicht zu erreichen war, weil z.B. die Adresse postalisch nicht existierte oder eine Baustelle den Zugang unmöglich machte. Ebenso ist es in Zeiten der E-Vergabe dem Auftraggeber zuzurechnen, wenn der virtuelle Briefkasten in Gestalt des Vergabeportals nicht zu erreichen ist.

An dieser Bewertung ändert es auch nichts, dass möglicherweise den Anbieter der E-Vergabesoftware oder den Betreiber des Rechenzentrums, in dem das Vergabeportal gehostet ist, im Innenverhältnis zum Auftraggeber die Verantwortung für die Probleme des Portals trifft. Dies ist eben nur eine Frage des Innenverhältnisses des Auftraggebers zu seinen Dienstleistern. Im Außenverhältnis zu den Bietern trifft die Verantwortung den Auftraggeber, E-Vergabe-Anbieter und Rechenzentrumsbetreiber sind im Verhältnis zum Bieter (lediglich) Erfüllungsgehilfen. Etwaiges Verschulden ist dem Auftraggeber zuzurechnen (§ 278 BGB).

4. Funktionsstörungen im Bieter-Client des E-Vergabeportals

Wenn der Bieter sich des Bieter-Clients bedient, der vom Vergabeportal bereitgestellt wird, ist die Haftungsfrage auch betreffend Fehlern im Bieter-Client isoliert und juristisch betrachtet leicht geklärt: Fehler des von der jeweiligen E-Vergabeplattform bereitgestellten Bieter-Clients sind dem Auftraggeber ebenso zuzurechnen, wie Fehler im Vergabeportal.

Faktisch wird es hier aber zu schwierigen Abgrenzungsfragen kommen, schließlich läuft der Bieter-Client in der IT-Infrastruktur des Bieters. Beispielsweise kann die Übermittlung des Angebots an verschiedenen Software-Versionen, Sicherheitseinschränkungen bzw. Firewall oder einem Proxy-Server liegen. Ob die Probleme also von der IT-Infrastruktur des Bieters oder dem Bieter-Client verursacht werden, wird sich nur anhand der Umstände des konkreten Einzelfalls klären lassen.

Dabei kann den Auftraggeber (bzw. E-Vergabeportal-Anbieter als Erfüllungsgehilfe des Auftraggebers) aber in Ausnahmefällen durchaus eine Garantenstellung gegenüber dem Bieter treffen. Beispielsweise wäre es eigentlich dem Bieter zuzurechnen, wenn die Übermittlung des Angebots an einem Proxy-Server in der IT-Infrastruktur des Bieters scheitert. Allerdings kann den Auftraggeber auch in einem solchen Fall ausnahmsweise eine Garantenpflicht treffen. Dies etwa dann, wenn der Bieter rechtzeitig den technischen Support des Auftraggebers bzw. E-Vergabeportals eingeschaltet hat, der Support bzw. Anbieter bereits aus anderen Fällen Kenntnis über das konkrete Problem hatte und keine geeigneten Maßnahmen ergreift, dieses zu beheben – wie etwa durch die Bereitstellung einer neuen Version oder eines geeigneten „Workarounds“.

5. Probleme mit einem XVergabe-kompatiblen, aber fremden Bieter-Client

Auch juristisch unübersichtlich wird die Lage, wenn der Bieter sich zukünftig eines XVergabe-kompatiblen, aber aus Sicht des Betreibers der E-Vergabeplattform fremden Bieter-Clients bedient. Man könnte argumentieren, dass der Bieter nun wiederum das volle Übermittlungsrisiko tragen muss. Jedoch ist zu bedenken, dass sich E-Vergabe-Anbieter auf den XVergabe-Standard einigen wollen – und Auftraggeber bei der Beschaffung einer E-Vergabe-Lösung zukünftig sicher auch die Kompatibilität zu diesem Standard fordern werden. Zudem ist die Etablierung dieses Standards erklärtes Ziel der Politik (vgl. § 10 Abs. 2 VgV). Vor diesem Hintergrund spricht vieles dafür, die Risikosphäre des Auftraggebers und dessen Erfüllungsgehilfen jedenfalls auf die Fähigkeit der jeweiligen E-Vergabeplattform auszudehnen, mit spezifikationsgemäß funktionierenden XVergabe-konformen Bieter-Clients arbeiten zu können.

Eine derartige Ausdehnung einer Garantenstellung ist im deutschen Recht nicht ungewöhnlich: Beispielweise haftet ein Autohersteller auch dafür, dass das von ihm in den Verkehr gebrachte Fahrzeug mit den als kompatibel bezeichneten Reifentypen bzw. -dimensionen funktioniert – auch wenn diese von einem anderen Hersteller stammen und später separat zugekauft werden. Diese Ausdehnung der wechselseitigen Verantwortlichkeiten in der Autobranche ist dadurch gerechtfertigt, dass PKW- und Reifenhersteller das gemeinsame Ziel verfolgen, den Absatz ihrer PKW und Reifen zu fördern.

Vergleichbar verhält es sich beim XVergabe-Standard. Alle Beteiligten wollen den Standard etablieren: Dann muss aber auch der Auftraggeber, der die Nutzung „fremder“ XVergabe-kompatibler Clients ermöglicht, dafür haften, dass die Plattform mit einem fremden Tool funktioniert. Wenn es bei dieser grundlegenden Kompatibilität zu Fehlern kommt, haftet der Auftraggeber bzw. sein Portalbetreiber grundsätzlich ebenso, wie in dem Fall, dass der „eigene“ Bieter-Client verwendet wird. Dies setzt allerdings voraus, dass das fremde Tool selbst funktioniert – und dem aktuellen Standard der X-Vergabe-Spezifikationen entspricht.

Aus dieser Bewertung dürfte für die Auftraggeber (und damit für die E-Vergabe-Anbieter) folgen, dass diese ihre XVergabe-kompatiblen Produkte zukünftig wechselseitigen Kompatibilitätstests unterziehen sollten. Um erneut das Beispiel aus der PKW-Branche aufzugreifen: Auch Fahrzeug- und Reifenhersteller müssen ihre Produkte fortlaufend auf ihre Kompatibilität testen: Schließlich könnte der Endverbraucher jederzeit einen neuen Reifen auf einem bereits in den Verkehr gebrachten PKW montieren.

Diese erweiterte Haftung bedeutet nicht, dass der Auftraggeber (bzw. der Betreiber der E-Vergabeplattform) auch technischen Support für ein fremdes Tool übernehmen muss. Bespielweise braucht ein (fremdes) Bietertool nicht vom E-Vergabeanbieter „gewartet“ zu werden. Gemeint ist also nur, dass die Plattform mit einem fremden Tool funktionieren muss, vorausgesetzt, dass das Tool selbst funktioniert – und dem aktuellen Standard der X-Vergabe-Spezifikationen entspricht. Auch hierzu können wir zur Veranschaulichung auf das Beispiel mit der Produkthaftung des PKW-Herstellers für fremde Reifen zurückkommen: Der Autoherstellers haftet nur, wenn der Reifen selbst nicht mangelhaft ist und den Spezifikationsanforderungen des Herstellers genügt.

Zudem ist klarzustellen, dass Auftraggeber (bzw. E-Vergabe-Anbieter) nur die Kompatibilität für Clients gewährleisten können, die sie kennen. Dies wird daher wohl nur für die zukünftig „offiziell“ als XVergabe kompatibel gelisteten Lösungen gelten. Daher brauchen Auftraggeber (und E-Vergabeanbieter) z.B. nicht für die Komptabilität eines (fremden), etwa portugiesischen, Bieter-Clients zu garantieren, wenn dieser aktuell nicht offiziell als XVergabe kompatibel gelistet ist. Auch hier das Beispiel aus der KFZ-Branche zur Veranschaulichung: Der KFZ-Hersteller braucht nicht für die Verwendung von Reifen zu haften, die er nicht kennt oder noch nicht kennen kann.

Auftraggeber (und ihre Erfüllungsgehilfen, die E-Vergabe-Anbieter bzw. technischen Betreiber einer E-Vergabeplattform) können ihr Haftungsrisiko reduzieren, indem sie ausdrücklich die Verwendung bestimmter Clients empfehlen. Auch hierfür gibt es im PKW-Markt eine Parallele: Insbesondere im Bereich der Premiumfahrzeuge werden ausdrücklich bestimmte Reifenmodelle zu Verwendung empfohlen. Besondere Garantien werden dann nur bei Verwendung der empfohlenen Reifenmodelle gegeben (z.B. Porsche-Kennungen für Reifen N0, N1 …).

6. Störungen und Fehler im Internetanschluss und den IT-Systemen des Auftraggebers

Für Störungen und Fehler im Internetanschluss und den IT-Systemen des Auftraggebers haftet der Auftraggeber. Dies betrifft auch Fälle, in denen die Verbindung ins Internet ge- oder gar zerstört wird (z.B. weil bei Bauarbeiten im Gebäude des Auftraggebers das Internetkabel beschädigt wird). Dies ist nicht anders als in der Papiervergabe: Geht beispielsweise das Angebot trotz korrekter Beschriftung in der Hauspost des Auftraggebers verloren, so haftet der Auftraggeber für dadurch entstandene Verzögerungen.

7. Störungen der Internetinfrastruktur

Bleibt abschließend noch zu klären, wie mit einer längeren Störung der Internet-Infrastruktur umzugehen ist. In Zeiten häufiger Cyber-Attacken ist dies leider auch keine rein theoretische Überlegung mehr. Bereits ein banaler „Unfall“ durch einen Bagger an einem zentralen Internetknoten kann eine längere, zumindest regionale Störung des Internets bewirken (z.B. Internetausfall im gesamten Stadtgebiet Dortmund). Derartige Totalausfälle sind wohl als höhere Gewalt zu behandeln und können grundsätzlich weder dem Auftraggeber noch dem Bieter zur Last gelegt werden, soweit sie objektiv nachweisbar sind. Daher müsste die Angebotsfrist nach einer längeren Störung der Internetinfrastruktur entsprechend angemessen verlängert werden. Aber Achtung: Nur mehrstündige oder ganztägige Ausfälle der Internetinfrastruktur zum Ende der Angebotsfrist machen eine Verlängerung der Angebotsfrist erforderlich. Mit kleineren Ausfällen und Verzögerungen muss der Bieter rechnen. Fälle, in denen der Bieter erst fünf Minuten vor Ende der Angebotsfrist mit der Übermittlung umfangreicher Datensätze beginnt, sind hiervon sicher nicht erfasst. Diese stellen vielmehr ein Organisationsverschulden des Bieters dar, für welches dieser (wie oben unter 1. erläutert) haftet.

8. Praxistipps für Bieter

Zunächst sollten alle Interessenten und Bieter sicherstellen, dass es nicht zu Störungen kommt. Daher sollten rechtzeitig vor Angebotsabgabe Testläufe genutzt werden. Mit Hilfe interner oder externer Experten sollten allgemein bekannte oder in den Testläufen identifizierte Schwachpunkte beseitigt werden (z.B. Beschränkungen von Dateigrößen, veraltete Softwareversionen, Proxy-Server).

Auch elektronische Angebote sollten rechtzeitig vor Ende der Angebotsfrist übermittelt werden. Kommt es dabei zu Problemen muss Gelegenheit bestehen, ebenfalls noch vor Ende der Angebotsfrist interne oder externe IT-Experten sowie ggf. den technischen Support des Auftraggebers, des Bieter-Clients bzw. des jeweiligen E-Vergabeportals einzubinden. Wenn auf diese Weise noch nicht geholfen werden kann, sollte auf eine „Eskalation“ in einen höheren Service Level hingewirkt werden.

Falls (noch) Angebote in Papierform zugelassen sein sollten, kann ggf. auf ein entsprechend formgültiges Papierangebot (im verschlossenen Umschlag!) ausgewichen werden. Von der „ersatzweisen“ Übersendung des Angebots mittels einer einfachen E-Mail wird dringend abgeraten. Mangels Verschlüsselung muss das Angebot ausgeschlossen werden (§§ 57 Abs. 1, 53 Abs. 1,  10 Abs. 1 VgV; §§ 16 EU Nr. 2, 13 Abs. 1 Nr. 2 VOB/A). Daher hat das OLG Karlsruhe die eingangs zitierte Entscheidung der VK Baden-Württemberg „kassiert“. Das OLG lässt den Umgang mit den technischen Problemen des E-Vergabe-Portals offen, weil bereits die ersatzweise Übersendung des formungültigen (per E-Mail übermittelten und so unverschlüsselten) Angebots das verspätete, verschlüsselte und „formgerechte“ Angebot „infiziert“ hat (OLG Karlsruhe, Beschl. v. 17.03.2017, 15 Verg 2 / 17).

Wenn der Bieter vermutet, dass die Übermittlungsprobleme auf Problemen der Internetinfrastruktur oder Fehlern in der Risikosphäre des Auftraggebers beruhen, muss er dies entsprechend protokollieren, um im Streitfall seiner Darlegungs- und Beweislast genügen zu können und dies ggü. dem Auftraggeber rügen. Eine entsprechende Protokollierung und ggf. Rüge empfiehlt sich auch bei Ausfällen des Internets, auch wenn Großstörungen publik (vgl. z.B. https://www.heise.de/netze/netzwerk-tools/imonitor-internet-stoerungen/) und damit die späteren Nachweismöglichkeiten vereinfacht werden.

9. Praxistipp für Auftraggeber

Wir brauchen hier keine Eulen nach Athen zu tragen: Auftraggeber wissen, dass sie eine hochverfügbare E-Vergabe-Lösung implementieren müssen. Dabei darf die E-Vergabe-Lösung auch nicht regelmäßig tageweise oder gar ganze Wochenenden zu Wartungszwecken abgestellt werden.

Für Auftraggeber gilt im Vergaberecht in besonderem Maße „tue Gutes und rede darüber“: Anstrengungen im Hinblick auf eine hohe Verfügbarkeit und einen qualifizierten Support (= Erfassung eines höheren Service-Levels) sowie weitere Hilfestellungen für die Bieter (z.B. die Möglichkeit von Testangeboten) sollten deutlich dokumentiert werden. Diese Dokumentationen können im Streitfall belegen, dass die Gründe für eine etwaige Verspätung in der Sphäre des Bieters liegen.

10. Quo vadis XVergabe?

Zum Abschluss möchten wir eine provozierende Frage stellen: Unter welchen Umständen und Anforderungen ergibt es Sinn, in unveränderter Weise am derzeitigen Konzept des XVergabe-Standards festzuhalten? Für Auftraggeber (und die Portalanbieter) entstehen zukünftig in der Praxis erhebliche Haftungsrisiken und mindestens potentielle Unsicherheiten, weil sie die Kompatibilität auch zu „fremden“ Clients gewährleisten müssen (dazu oben 5.). Technisch dürfte der Trend ohnehin immer mehr zu webbasierten Bieter-Clients gehen, soweit diese auch eine „Ende-zu-Ende-Verschlüsselung“ sicherstellen. Der ursprünglich hinter der XVergabe stehende Gedanke, dass Bieter nicht „genötigt“ werden sollen, eine Vielzahl verschiedener Clients lokal zu installieren, erledigt sich absehbar in den kommenden Jahren durch den technischen Fortschritt.

Vielleicht könnte an die Stelle des derzeitigen Dateiaustauschstandards zumindest eine verlässliche Kompatibilitätsliste, ggf. sogar ein Standard für die Bedienkonzepte der Bieter-Clients, treten. Dann würde der Bieter in Zukunft jede E-Vergabe mit dem jeweils richtigen, empfohlenen und webbasierten Bieter-Client bestreiten. Jedenfalls Übermittlungsprobleme aufgrund von Kompatibilitätsproblemen zwischen Client und E-Vergabeplattform verschiedener Hersteller wären dann ausgeschlossen. Wenn die Bieter-Clients webbasiert sind und die Bedienkonzepte der Bieter-Clients angeglichen werden, wäre der regelmäßig Wechsel zwischen den Bieter-Clients auch zumutbar.

Um auch als „Rausschmeißer“ nochmals das Fahrzeugbeispiel zu bemühen: Wer einen Sportwagen und einen SUV (also verschiedene E-Vergabe-Lösungen) in der Garage hat, wird jedes Fahrzeug mit den speziell dafür vorgesehenen Reifen fahren – und nicht nur einen Reifensatz (also Bieter-Client) für beide nutzen wollen. Selbst wenn dies (mechanisch) technisch möglich sein sollte: Es bliebe ein gefährlicher Kompromiss. Der Wechsel zwischen den Fahrzeugen (Bieter-Clients) ist auch zumutbar, da diese – trotz ihres unterschiedlichen Charakters – ein ähnliches Bedienkonzept haben.

Erschwerend kommt hinzu, dass der aktuelle Status des XVergabe-Standards ausschließlich die Kommunikation zwischen Vergabestelle und Bieter, nicht aber die Struktur oder Inhalte der Angebote, Leistungsverzeichnisse oder Fragenkataloge im Fokus hat. So wird es auch nach Etablierung des Standards bis auf weiteres unverändert erforderlich bleiben, für die Bearbeitung von Formularen, Leistungsverzeichnissen oder Fragenkatalogen ggf. auf proprietäre Werkzeuge (oder eventuell sogar Bieter-Clients) der Vergabestelle bzw. der jeweiligen E-Vergabeplattform zurückzugreifen, wenn diese nicht vernünftigerweise auf etablierte Standards wie Excel, GAEB & Co setzen.
Bildquelle: p365.de – Fotolia.com

Autoren

Zeiss_2Prof. Dr. jur. Christopher Zeiss
Einer der führenden Vergaberechtsexperten in Deutschland. Er ist Professor für Staats- und Europarecht mit beschaffungsrechtlichem Schwerpunkt an der Fachhochschule für öffentliche Verwaltung NRW (Bielefeld) und hat einen Lehrauftrag zum Vergaberecht an der Universität Potsdam. Zuvor war er als Referent am Bundesministerium der Justiz (Berlin) u.a. für Vergabe- und Kartellrecht zuständig und arbeitete schon als Rechtsanwalt und Richter in der Beschaffungspraxis.

 

carsten_klipstein_2014Carsten Klipstein ist Geschäftsführer der cosinex und der GovTech-Gruppe. Seit über 15 Jahren befasst er sich mit der Digitalisierung von Verwaltungsprozessen. Herr Klipstein ist Autor verschiedener Veröffentlichungen u.a. in den Bereichen E-Government und der elektronischen Unterstützung des öffentlichen Auftragswesens.

 

 

 

Beitrag empfehlen

Verwandte Beiträge

Besuchen Sie uns auch auf

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Formularschutz