Auswahl- und Zuschlagskriterien

Schwellenwert- und Regimeannahme. Es wird – entsprechend Ihrer Aufgabenstellung – ein EU‑Oberschwellenverfahren konzipiert.

• klassische Auftraggeber (subzentrale Auftraggeber): Liefer‑/Dienstleistungen 216.000 €, Bau 5.404.000 €; zentrale Auftraggeber: Liefer‑/Dienstleistungen 140.000 €. Wenn der Auftrag ein Sektorenauftrag wäre (SektVO/Utilities), läge die maßgebliche Liefer‑/Dienstleistungsschwelle typischerweise bei 432.000 €.

• Auffälligkeit: Der von Ihnen vorgegebene Kostenrahmen führt bei 5 Jahren zu einem TCO‑Beispiel von 105.500 € (siehe TCO‑Abschnitt) und läge damit unter 216.000 €. Das EU‑Verfahren wäre dann nicht zwingend; möglich wäre aber (a) dass der tatsächliche Auftragswert höher ist (Optionen/Module/Integrations‑ und Migrationsleistungen/weitere Nutzerzahlen) oder (b) der Auftrag umfasst zusätzliche Leistungen, die im Budget nicht enthalten sind. Für die Auftragswertschätzung sind Optionen/Verlängerungen zwingend einzubeziehen.

Eine konkrete Vertragslaufzeit ist nicht vorgegeben; daher werden TCO‑Varianten für 1/3/5 Jahre ausgewiesen. Praxisnah ist oft eine Basislaufzeit (z. B. 3 Jahre) plus Optionen; vergaberechtlich muss die Auftragswertschätzung die Gesamtlaufzeit inkl. Optionen abbilden.
Nutzungsumfangannahmen. Nutzerzahlen, Standorte, Datenvolumen, Integrationslandschaft (ERP, DMS, IAM/SSO etc.) und Migrationsquellen sind nur teilweise bekannt. Für ein Preisblatt und Vergleichbarkeit sollten diese Parameter als „Vergabeszenario“ in den Unterlagen fixiert werden (z. B. Anzahl Admins/Power User/Meldende; Anzahl Liegenschaften; erwartete Ticketvolumina; Schnittstellenanzahl).

• Normative Struktur: EU‑Recht, GWB/VgV und ggf. SektVO

Die Grundstruktur (Verfahrensarten, Transparenz, Gleichbehandlung) folgt der Richtlinie 2014/24/EU. Das Verhandlungsverfahren mit vorheriger Veröffentlichung ist in Art. 29 geregelt; die Wahl der Verfahren u. a. in Art. 26.
Der deutsche Rechtsrahmen setzt dies im Oberschwellenbereich primär über GWB (Teil 4) und VgV um.

• Wahl der Verfahrensart / Zulässigkeit des Verhandlungsverfahrens mit Teilnahmewettbewerb: § 14 VgV (insb. Abs. 3).

• Durchführung des Verhandlungsverfahrens: § 17 VgV (u. a. Fristen, Erstangebote).

• Leistungsbeschreibung als Funktions-/Leistungsanforderung (wichtig für marktoffene SaaS‑Beschaffung): § 31 VgV.

• Dokumentation/Vergabevermerk (Nachprüfungsfestigkeit): § 8 VgV.

• Begrenzung der Bewerberzahl im Teilnahmewettbewerb: § 51 VgV (Mindestzahl i. d. R. nicht unter 3).

• Normen/Zertifikate nur mit Gleichwertigkeit: § 49 VgV („oder gleichwertig“).

• Grundsätze Wettbewerb/Transparenz/Gleichbehandlung/Verhältnismäßigkeit: § 97 GWB.

• Eignungssystematik und Verhältnismäßigkeit der Eignungsanforderungen: § 122 GWB.

• Zwingende/fakultative Ausschlussgründe: §§ 123, 124 GWB.

• Zuschlag/Wirtschaftlichkeit/Zuschlagskriterien: § 127 GWB.

• Vertragsänderungen: § 132 GWB.

• Informations‑ und Wartepflicht (Standstill): § 134 GWB.

• Nachprüfungsantrag/Rügekontext: § 160 GWB.

• Kernaussage: Zuschlagskriterien müssen auf die Ermittlung des wirtschaftlich günstigsten Angebots gerichtet sein; Kriterien, die im Wesentlichen die Eignung/Leistungsfähigkeit der Bieter bewerten, sind als Zuschlagskriterien unzulässig.

• Praktische Konsequenz für Ihr Wunschkriterium „Lieferantenstabilität“: Finanzierung/Bilanzkennzahlen gehören regelmäßig in die Eignung (Teilnahmewettbewerb) – nicht in den Zuschlag. Im Zuschlag darf nur „leistungsgegenstandsbezogene Kontinuitäts‑/Betriebsqualität“ bewertet werden (z. B. BCM/DR‑Konzept, Exit‑Reife, Auditierbarkeit).

Die Offenlegung von Zuschlagskriterien und Unterkriterien/Anwendungssystematik hat so zu erfolgen, dass Bieter nachvollziehen können, wie bewertet wird.

Zugleich zeigt Verg 6/22, dass eine 0–5‑Punkte‑Matrix und Mindestpunkteschwellen zulässig sein können, wenn sie transparent vorgegeben und sachgerecht angewandt werden.

In Deutschland ist § 132 GWB der zentrale Anker: Wesentliche Änderungen während der Vertragslaufzeit erfordern grundsätzlich ein neues Verfahren. Das ist bei SaaS (Release‑/Change‑Dynamik) in den Vertragsklauseln zu berücksichtigen (Change‑Control; zulässige Änderungsklauseln).

EU‑Leitfäden betonen, dass Umweltaspekte im Rahmen der 2014er Richtlinien in Leistungsbeschreibung, Wertung und Vertragsausführung berücksichtigt werden können, u. a. über Lebenszykluskostenrechnung und Umwelt‑Zuschlagskriterien, sofern Transparenz/Bezug/Prüfbarkeit gewährleistet sind.

• Leistungsbeschreibung: Funktionsorientiert, prüfbar, SaaS‑spezifisch

Für CAFM‑SaaS empfiehlt sich eine Primärbeschreibung als Funktions-/Leistungsanforderung mit objektiv prüfbaren Abnahmekriterien (Testfälle, Datenmappings, SLA‑Messmethoden). Dies ist vergaberechtlich ausdrücklich vorgesehen.

SaaS‑typische Risiken (Betrieb, Security, Datenexport, Update‑Zyklen) sind Teil des Leistungsgegenstands – nicht „nice to have“.

• Asset-/Anlagenmanagement: Stammdatenmodell, Hierarchien (Standort‑Gebäude‑Etage‑Raum‑Asset), Dokumentenverknüpfung, Kennzeichnung (z. B. Barcode/QR), Lebenszyklus, Zustands-/Wertattribute, Historie/Audit‑Trail.

• Raum-/Flächenmanagement: Flächentypen, Flächenberechnung (Methodik festlegen), Belegung, Umzugs-/Änderungsprozesse, Raum‑Services (Buchung, Ausstattung), Aktualisierungsworkflows.

• Wartungs-/Instandhaltungsmanagement: Wartungspläne, zyklische Aufgaben, Checklisten, Nachweisführung, Ressourcenplanung, Dienstleistersteuerung, Ersatzteile/Material soweit relevant, mobile Rückmeldungen.

• Störungs-/Helpdesk‑ & Ticketmanagement: Meldungsaufnahme (Web/Mobile), Priorisierung, Kategorien, Eskalation, Statuskommunikation, SLA‑Uhren, Wissensdatenbank.

• IAM/SSO (z. B. SAML/OIDC) und rollenbasiertes Berechtigungssystem,

• DMS‑Anbindung (Dokumente),

• offene API (REST) und dokumentierte Import/Export‑Mechanismen,

• Protokollierung (technische Logs + fachliche Änderungsprotokolle).

Rollenbasierte Mobile‑App/Web‑App, offline‑fähige Kernprozesse (falls erforderlich), Fotodokumentation, Scan‑Funktionen.

Standardberichte, Ad‑hoc‑Reports, Exportformate, KPI‑Framework, revisionssichere Protokollierung.

• Abschluss einer Auftragsverarbeitungsvereinbarung (AVV) nach Art. 28 DSGVO.

• Technische und organisatorische Maßnahmen (TOMs) nach Art. 32 DSGVO – u. a. Vertraulichkeit/Integrität/Verfügbarkeit/Belastbarkeit, Wiederherstellbarkeit.

• Subunternehmersteuerung (Transparenz, Zustimmung/Informationspflichten, Audit‑Pflichten).

Wenn Datenverarbeitung oder Supportzugriffe außerhalb EWR möglich sind, müssen Transfer‑Risikobewertungen und ergänzende Maßnahmen (Vertrag + technisch organisatorisch) vorgesehen werden.

BSI‑nahe Leitlinien betonen das Shared‑Responsibility‑Prinzip und nennen Vertragsgegenstände wie Lokation, Backup, Monitoring, Verfügbarkeit als typische Regelungsfelder. Als Nachweisrahmen kann BSI‑C5 (oder gleichwertig) genutzt werden; C5 wird als umfassender Kriterienkatalog für Cloud‑Dienste beschrieben und ist in der Praxis etabliert.
Vergaberechtlich ist bei Zertifikaten zwingend eine Gleichwertigkeit zuzulassen.

Muss‑Anforderungen sollten Messmethoden (Monitoring, Messpunkt, Wartungsfenster, Ausschlüsse) und Mindestwerte definieren.

• Muss‑Anforderungen: RPO/RTO, Testwiederherstellung, Verschlüsselung, getrennte Aufbewahrung, Protokollierung.

• Muss‑Anforderungen: Datenexportformate, Datenmodellbeschreibung, Exit‑Assistance, Lösch-/Nachweispflichten, Übergangsfristen.

Betrieb/Support umfasst u. a. Ticketsystem/Incident‑Management, Reaktions-/Lösungszeiten, Release‑Kommunikation, Wartungsfenster, Störungsmanagement, (optional) 24/7‑Bereitschaft. EVB‑IT‑Cloud‑Strukturen sehen dafür z. B. ein Ticketsystem und definierbare Leistungspläne vor.

Migration sollte als eigener Leistungsbaustein beschrieben werden: Datenquellen, Mapping‑Pflichten, Testdaten‑Migration, Cutover‑Plan, Validierung, Protokollierung, Abnahme.

Eignungskriterien müssen in Verbindung mit dem Auftragsgegenstand stehen und angemessen sein. Im Teilnahmewettbewerb sind zudem zwingende/fakultative Ausschlussgründe zu prüfen.

• Teilnahmevoraussetzungen (Mindestanforderungen, KO): ohne Erfüllung → Ausschluss vom Teilnahmewettbewerb

• Auswahlkriterien zur Bewerberbegrenzung (nur falls >N geeignete Bewerber): objektiv, nichtdiskriminierend, in der Bekanntmachung genannt.

• Ausschlussgründe / Zuverlässigkeit (KO): „Der Bewerber erklärt das Nichtvorliegen zwingender Ausschlussgründe nach § 123 GWB; fakultative Ausschlussgründe nach § 124 GWB werden offengelegt.“

• Berufsausübung (KO): „Nachweis der Befähigung und Erlaubnis zur Berufsausübung (Eintragung Handelsregister/gleichwertig).“

• Finanzielle Leistungsfähigkeit (KO, proportional festlegen): Beispiel (zu parametrisieren): „Jahresumsatz im Leistungsbereich Software/Cloud‑Betrieb in den letzten 3 Geschäftsjahren: im Mittel ≥ [X] €.“
  Rechtsrahmen: Anforderungen können gestellt werden, müssen auftragsbezogen/proportional sein.

• Referenzen (KO): Beispiel: „Mindestens zwei Referenzen über Einführung und Betrieb eines CAFM‑ oder vergleichbaren FM‑Systems als SaaS in den letzten 3–5 Jahren, jeweils mit: (i) Migration von Bestandsdaten, (ii) mindestens [Y] Nutzer, (iii) mindestens [Z] produktiven Schnittstellen.“
  Technische/berufliche Leistungsfähigkeit ist als Eignung prüfbar.

• Informationssicherheits‑Nachweisrahmen (KO oder „Muss‑Konzept“): Beispiel: „Der Bewerber verfügt über ein ISMS und kann für den Cloudbetrieb einen geeigneten Nachweis (z. B. ISO/IEC 27001 oder BSI‑C5‑Testat oder gleichwertig) vorlegen.“
  Gleichwertigkeit ist zwingend zuzulassen.

Die VgV sieht für Eignungsnachweise die Kategorien wirtschaftlich‑finanziell und technisch‑beruflich vor.

Für Zertifikate/Normen gilt: Nur „oder gleichwertig“.

Eine Begrenzung ist zulässig; Mindestzahl der einzuladenden Bewerber im Verhandlungsverfahren i. d. R. nicht unter 3.
Die Kriterien der Begrenzung müssen objektiv, nichtdiskriminierend sein und in der Bekanntmachung genannt werden; Praxis und Rechtsprechung betonen dies.

• Referenz‑Komplexität (Skalierung, Schnittstellenanzahl, Migrationstiefe)

• Security/Compliance‑Reife (auditierte Nachweise; Gleichwertigkeit)

• Projektkapazität (nachweisbare FTE‑Verfügbarkeit, Rollenabdeckung)

• Integrationskompetenz (API‑Erfahrung, SSO‑Projekte)

„Sofern mehr als [N] geeignete Bewerber vorliegen, werden die einzuladenden Bewerber anhand der objektiven Auswahlkriterien Referenzvergleichbarkeit/Komplexität, Security‑Reifegrad und Projektressourcen ausgewählt. Die Kriterien dienen ausschließlich der Eignungsdifferenzierung und haben keinen Bezug zur späteren Zuschlagswertung.“

Die Zuschlagswertung muss das wirtschaftlichste Angebot anhand vorab festgelegter Zuschlagskriterien bestimmen.

Zuschlagskriterien/Unterkriterien und Bewertungsmatrix sind transparent vorzugeben.

• Muss‑Prüfung (KO): Erfüllung Mindestanforderungen (Funktional/NFR, DSGVO‑Basics, Mindest‑SLA, Preisblatt vollständig)

• Wertung: 0–5‑Skala je Unterkriterium (mit textlichen Bewertungsankern) + Preis/TCO‑Formel

• Mindestqualitätsschwellen (optional): z. B. Mindestpunktzahl pro kritischem Qualitätsblock (zulässig bei sachlicher Begründung; Beispiele in der Rspr.).

• Preis/TCO: 30

• Funktionale Leistungsfähigkeit & Usability: 20

• Technische Lösung & Integration: 15

• Datenschutz & Informationssicherheit: 15

• Service/Betrieb/Support & SLA‑Qualität: 10

• Migration & Einführungsprojekt: 10

• 0 Punkte: nicht erfüllt / nicht prüfbar / widerspricht Muss

• 1 Punkt: nur mit gravierenden Einschränkungen

• 2 Punkte: mit wesentlichen Einschränkungen (Mindestniveau gerade erreicht)

• 3 Punkte: erfüllt (Standard)

• 4 Punkte: gut erfüllt (nachweislicher Mehrwert, geringer Projektrisiko)

• 5 Punkte: sehr gut erfüllt (Best‑Practice, hoher Mehrwert, belastbar belegt)

PreisPunkte = Gewicht_Preis × (TCO_min / TCO_i) mit Gewicht_Preis = 30, TCO_min = niedrigster TCO über alle wertbaren Angebote, TCO_i = TCO des Angebots i.
Diese lineare Formel ist transparent und rechnerisch nachprüfbar und wird in Vergabepraxis häufig verwendet (wichtig: vorab bekannt geben; Rundungsregeln definieren).

• Einmalige Softwarekosten: 30.000 €

• Jährliche Wartung/Services: 17 % von 30.000 € = 5.100 € p. a.

• Jährliche Trainingskosten: 10.000 € p. a.

• Laufzeitannahme: offen → Varianten 1/3/5 Jahre.

TCO(n) = Einmalkosten + n × (Wartung_p.a. + Training_p.a.) = 30.000 + n × (5.100 + 10.000) = 30.000 + 15.100n

Für die reale Wertung ersetzen Bieterpreise diese Budgetwerte. Die Budgetrechnung dient (a) als plausibilisierte Kostenschätzung, (b) als Struktur für ein einheitliches Preisblatt, (c) ggf. als transparenter Höchstpreis (nur wenn ausdrücklich als KO‑Kriterium festgelegt).

Für die Auftragswertschätzung sind Optionen/Verlängerungen einzubeziehen; für die Zuschlagswertung sollte die gleiche Laufzeitlogik verwendet werden, um Wertungs‑ und Auftragswertsystematik konsistent zu halten.

• Preis/TCO: „Die Wertung erfolgt auf Basis der Gesamtbetriebskosten (TCO) über [Laufzeit inkl. Optionen] gemäß Ausgabe des Preisblatts. PreisPunkte = 30 × (TCO_min / TCO_i). Rundung auf zwei Dezimalstellen.“

• Datenschutz/Sicherheit: „Bewertet wird die Güte des Datenschutz‑ und Sicherheitskonzepts einschließlich AVV‑/TOM‑Qualität, Berechtigungskonzept, Verschlüsselung, Auditierbarkeit und Umgang mit Unterauftragnehmern. Zertifikate/Testate werden als Nachweis akzeptiert, sofern ISO/BSI‑C5 oder gleichwertig.“

• Service/SLA: „Bewertet wird die Qualität der Betriebs‑ und Supportleistungen einschließlich SLA‑Definitionen, Messmethodik, Eskalationskonzept und Release‑Management.“

• Wichtiger Compliance‑Satz (Trennung Eignung/Zuschlag): „Bieter‑/Unternehmensbezogene Eignungsaspekte (z. B. Anzahl Unternehmensreferenzen, Umsatzkennzahlen) werden ausschließlich im Teilnahmewettbewerb geprüft und sind nicht Gegenstand der Zuschlagswertung.“

Für öffentliche Auftraggeber ist der EVB‑IT Cloudvertrag ein belastbarer Strukturanker für Cloudleistungen: Er sieht u. a. einen Kriterienkatalog, eine AVV inkl. TOM sowie einen Abschnitt „Leistungen bei Vertragsende“ und Prüfrechte vor.
Er enthält außerdem eine Regelung, dass auftragnehmerseitige AGB mit dynamischem Änderungsvorbehalt nur insoweit wirksam einbezogen werden, wie Änderungen nicht zum Nachteil des Auftraggebers sind – ein wichtiger Ausgangspunkt für SaaS‑Updateklauseln.

• Verfügbarkeit (z. B. monatlich, definierte Messpunkte, definierte Wartungsfenster, Ausschlüsse)

• Incident‑Klassifikation (P1/P2/P3) mit Reaktions‑/Lösungszeiten

• Service‑Credits (moderate pauschalierte Kompensation, klar berechenbar)

• Monitoring/Reporting (monatliches SLA‑Reporting, Zugriff des Auftraggebers auf Messdaten)

• Backup/Restore: RPO/RTO, regelmäßige Restore‑Tests, Verschlüsselung

• Change/Release‑Management: Vorankündigungsfristen, Testfenster, Rückfalloptionen, Dokumentationspflichten

• Security‑Incident‑Pflichten: Meldewege, Forensik‑Kooperation, Lessons Learned

BSI‑nahe Darstellungen nennen Lokation, Backup, Monitoring und Verfügbarkeit als typische Vertragsregelungsfelder im Cloudkontext; zudem wird Shared Responsibility betont (also: klare Verantwortungszuordnung).

• AVV nach Art. 28 DSGVO als Vertragsbestandteil; EVB‑IT Cloudvertrag sieht eine AVV‑Anlage ausdrücklich vor.

• TOM‑Anlage nach Art. 32 DSGVO (u. a. Verschlüsselung, Wiederherstellbarkeit, regelmäßige Wirksamkeitsprüfung).

• Unterauftragnehmerregime: Transparenzliste, Genehmigungs-/Widerspruchsmechanismus, Flow‑down‑Pflichten, Audit‑Pflichten.

Bei SaaS muss Exit/Portabilität als vertraglicher Leistungsbestandteil definiert werden; EVB‑IT Cloudvertrag führt „Leistungen bei Vertragsende“ ausdrücklich als Leistungsbereich.

• Datenexport: vollständiger Export aller fachlichen Daten inkl. Historien/Logs (soweit rechtlich zulässig) in offenen Formaten (CSV/JSON/XML) plus Datenmodellbeschreibung.

• Dokumentenexport: strukturierter Export inkl. Metadaten, Versionen (sofern vereinbart).

• Exit‑Assistance: definierte Tagessätze und ein Höchstvolumen (Planbarkeit; Kosten in TCO‑Preisblatt).

• Löschung & Nachweis: Fristen, Löschprotokolle, ggf. Nachweis durch Audit/Bestätigung.

• Übergangsphase: Zugriff für [X] Tage/Wochen nach Vertragsende auf Read‑only‑Umgebung, wenn erforderlich.

Da SaaS‑Leistungen laufend weiterentwickelt werden, muss der Vertrag saubere Änderungsklauseln enthalten, die die Grenzen von § 132 GWB respektieren (keine „wesentlichen“ Änderungen ohne vergaberechtliche Grundlage).

• Standard‑Updates innerhalb definierter Release‑Policy (keine Entgelt‑ oder Funktionsverschlechterung),

• definierter Change‑Request‑Prozess für zusätzliche Leistungen/Module mit klaren Preisregeln (Preisblatt),

• klare Abgrenzung zwischen Wartung/Fehlerbehebung vs. Erweiterung.

• Bekanntmachung und Transparenz: Eignungs‑ und Zuschlagskriterien sowie ggf. Kriterien zur Bewerberbegrenzung müssen in geeigneter Form veröffentlicht werden; für die Begrenzung verweist § 51 VgV ausdrücklich auf objektive/nichtdiskriminierende Kriterien und Mindestbewerberzahl.
  Zuschlagskriterien müssen so transparent sein, dass sie nachprüfbar sind.

• Leistungsbeschreibung: Funktionsorientierte Leistungsbeschreibung ist zulässig und für SaaS meist vorzugswürdig.

• Vertraulichkeit und Gleichbehandlung in Verhandlungen: Vertrauliche Angebotsinformationen sind zu schützen; das ist in § 5 VgV verankert und muss in Verhandlungsrunden organisatorisch abgesichert werden.

• Dokumentation/Vergabevermerk: Das Verfahren ist fortlaufend zu dokumentieren; der Vergabevermerk muss Entscheidungen stützen und nachprüfbar machen.

• Mindestfristen: Für Erstangebote im Verhandlungsverfahren mit Teilnahmewettbewerb gilt grundsätzlich eine Mindestfrist von 30 Tagen.

• Standstill: Vor Zuschlag ist die Informations‑ und Wartepflicht einzuhalten (Regelfrist 15 Kalendertage; bei elektronischer Übermittlung 10 Kalendertage).

• Nachprüfungslogik (Rüge/Nachprüfungsantrag): Nachprüfungsverfahren werden auf Antrag eingeleitet; § 160 GWB bildet den Rahmen.

Unklare Bewertungsmatrizen, nicht veröffentlichte Unterkriterien oder nachträgliche Bewertungsänderungen sind klassische Angriffsflächen (OLG Düsseldorf‑Linie; VK‑Praxis).

• Kriterien stets auftragsbezogen formulieren und in Muss vs. wertbar trennen.

• Zertifikate/Standards stets mit „oder gleichwertig“ öffnen.

• Bewertungsmatrix vorab vollständig offenlegen und konsequent anwenden (Selbstbindung).

• „Lieferantenstabilität“ als Eignung (finanziell) und im Zuschlag nur als Betriebs-/Kontinuitätskonzept abbilden (Trennungsgebot).

• Unternehmensmerkmale (Umsatz, Anzahl Referenzen) als Zuschlagskriterien verwenden.

• Nachträgliche Änderungen an Gewichtung/Matrix/Unterkriterien ohne transparente Vorabkommunikation.

• SaaS‑AGB mit dynamischen Nachteilsklauseln unkontrolliert einbeziehen; EVB‑IT‑Systematik zeigt, dass dynamische Änderungen nur ohne Nachteil zulässig eingebettet werden sollten.