TUMonline (ex-post-VÖ) Referenznummer der Bekanntmachung: TUM-2021-EU-2
Bekanntmachung vergebener Aufträge
Ergebnisse des Vergabeverfahrens
Dienstleistungen
Abschnitt I: Öffentlicher Auftraggeber
Postanschrift:[gelöscht]
Ort: München
NUTS-Code: DE212 München, Kreisfreie Stadt
Postleitzahl: 80333
Land: Deutschland
Kontaktstelle(n):[gelöscht]
E-Mail: [gelöscht]
Telefon: [gelöscht]
Internet-Adresse(n):
Hauptadresse: www.tum.de
Abschnitt II: Gegenstand
TUMonline (ex-post-VÖ)
Die Technische Universität München, Zentrale IT ("TUM") betreibt auf eigener IT-Infrastruktur und in eigenen Serverräumen ein Campusmanagementsystem der TU Graz mit der Produktbezeichnung CAMPUSonline. Die interne, durch die TUM definierte Bezeichnung, trägt den Namen TUMonline. Um das Campusmanagementsystem funktional zu betreiben ist eine entsprechende Wartung und Pflege der IT-Infrastruktur nötig. Zum Gesamtkonstrukt gehören die Hosts (Frontend, Middle Tier), welche mittels Docker Swarm abgebildet sind, wie auch eine Datenbank und das Campusmanagementsystem selbst. Die Ausschreibung ist in folgende Lose aufgeteilt:
-LOS 1: Betrieb und Wartung von Frontend, Middle-Tier und Oracle Datenbank
-LOS 2: Betrieb und Pflege der Softwarelösung TUMonline
Betrieb und Wartung von Frontend, Middle-Tier und Oracle Datenbank
Technische Universität München Arcisstr. 21 80333 München
Der Auftragnehmer in Los 1 ist für die reibungslose Funktion der Systemumgebung (Produktivsystem, Qualitätssicherung, Development, Demo und Review) mit diversen Komponenten (Linux Betriebssystem Version CentOS 7 und alle darauf installierten Softwarepakete die für den Betrieb des Apache Reversproxy sowie des Docker Swarm benötigt werden, Docker Software, Oracle Datenbank Version 19c unter Oracle Linux 7.9 und die darauf laufenden Datenbankinstanzen, Front- Middle-Tier Container) verantwortlich. Die abgekündigten Komponenten OHS (Oracle http Server) und iAS (Oracle Internet Application Server) sind nicht Bestandteil dieses Loses. Es müssen aber Integrationsleistungen erbracht werden. Zu den Leistungspflichten in Los 1 gehören Betrieb, Wartung, Pflege und Support der Systemumgebung. Eine ausführliche Beschreibung der zu erbringenden Leistungen ist unter Ziffer 6 der Leistungsbeschreibung enthalten.
Im Rahmen des Projektes kann es erforderlich werden, dass vom Auftragnehmer zusätzliche Leistungen erbracht werden müssen, deren Notwendigkeit und/oder Umfang vorab nicht absehbar bzw. planbar gewesen ist. Derartige Leistungen werden durch den Auftraggeber als sog. optionale Leistung abgerufen. Es besteht diesbezüglich keine Abnahmepflicht Seitens des Auftraggebers.
Im Falle der Ausübung einer Option durch den Auftraggeber erfolgt der Abruf durch explizite einseitige Erklärung des Auftraggebers gegenüber dem Auftragnehmer in Schrift- oder Textform (bspw. E-Mail). Der Auftraggeber wird sich bemühen, optionale Leistungen frühzeitig, spätestens jedoch vier Wochen im Voraus anzukündigen und abzurufen. Der Auftragnehmer ist im Falle des Abrufs einer optionalen Leistung zu deren Ausführung zu den im Preisblatt angebotenen Preisen verpflichtet, d.h. dass in diesem Fall eine Leistungspflicht des Auftragnehmers besteht. Der Auftragnehmer sollte daher zur (etwaigen) Ausführung der optionalen Leistungen personelle und technische Kapazitäten vorhalten oder deren Aktivierung zumindest einplanen. Der Auftragsgeber wird bei Bedarf als optionale Leistung zusätzliche IT-Dienstleistungen im Zusammenhang mit der in diesem Los der Leistungsbeschreibung dargestellten (zwingend zu erbringenden) Hauptleistungen abrufen.
1) Der Auftraggeber benötigt ggf. erweiterte Servicezeiten für die in Kapitel 6.3.8.1.2 der Leistungsbeschreibung genannten Komponenten bei Anfragen/Fehlern mit der Priorität "Hoch". Diese wird bei Bedarf auf 24 Stunden an 7 Tagen erhöht (24x7).
2) Der Auftraggeber hat die Möglichkeit für die Ausführung verschiedenster Aufgaben in der Systemumgebung ein Stundenkontingent in Höhe von bis zu 650 Stunden pro Jahr abzurufen. Der Auftragnehmer stellt sicher, dass die Leistungen auf Stundenbasis, mit KnowHow in den Bereichen Linux, Shell Scripting, Docker (Swarm), Oracle dB, Java, JavaScript, HTML, SQL, Spring / Angu-lar Frameworks, REST-Technologien, XSL-FO, Apache FOP Technologien sowie Git erbracht werden können. Beispiele für Aufgaben (nicht abschließend), welche über das Stundenkontingent abgerufen werden können, sind u.a.:
- Einrichtung weitere Hosts (z.B. zur Vergrößerung eines Docker Swarm)
- Einrichtung neue Container (z.B. KeyCloak, Traefik)
- Umstellung auf andere Technologie (z.B. Kubernates im Middle Tier)
- Integration des SRP in den Docker Swarm als weitere Container
- Infrastruktur für Lokale Applikationsentwicklung einrichten
- Aufbau ein Web-Services Monitoring basierend auf Splunk
- Physikalische Trennung der d.3 DB von der TUMonline DB
- Alle Art von Anpassungen sowie Entwicklungen im Kontext des Campusmanagementsystems
Betrieb der Softwarelösung TUMonline
Technische Universität München Arcisstr. 21 80333 München
Der Softwarehersteller (TU Graz) stellt regelmäßige Updates, Releases, Service-Packs sowie Vorab-Solvs für das Campusmanagementsystem zu Verfügung. Der Auftragnehmer in Los 2 ist verantwortlich für die Überführung der Updates in die jeweiligen Systeme. Dazu gehören die Planung und Terminfindung der Überführungen sowie die Installation, die Tests und Dokumentation der Aktivitäten. Die TUM stellt auch regelmäßige Updates für die lokale Anpassungen an die UI und Dokumente zu Verfügung, der Auftragnehmer ist ebenfalls verantwortlich für die Überführung der Updates in die jeweiligen Systemen und für die Pflege der CI/CD Skripte. Zur Unterstützung der internen Aufgaben des Auftraggebers stehen, neben dem Produktivsystem, folgende Testsysteme zur Verfügung: Qualitätssicherung, Development, Demo und Review. Diese müssen durch den Auftragnehmer in regelmäßigen, aber unterschiedlichen Abständen mit Releases, Service-Packs oder Vorab-Solvs (Deployment) und mit dem aktuellen Datenbestand des Produktivsystems (Klone) aktualisiert werden. Die Aktualisierung aller Systeme mittels Deployments und Klone liegt in der Verantwortung des Auftragnehmers. Das Deployment und auch der Klonprozess beinhaltet folgende Schritte, welche zum geforderten Leistungsumfang gehören: Terminplanung, Umsetzung/Installation, Kommunikation, Test und Dokumentation. Eine ausführliche Beschreibung der in Los 2 zu erbringenden Leistungen ist unter Ziffer 7 der Leistungsbeschreibung enthalten.
Im Rahmen des Projektes kann es erforderlich werden, dass vom Auftragnehmer zusätzliche Leistungen erbracht werden müssen, deren Notwendigkeit und/oder Umfang vorab nicht absehbar bzw. planbar gewesen ist. Derartige Leistungen werden durch den Auftraggeber als sog. optionale Leistung abgerufen. Es besteht diesbezüglich keine Abnahmepflicht des Auftraggebers.
Im Falle der Ausübung einer Option durch den Auftraggeber erfolgt der Abruf durch explizite einseitige Erklärung des Auftraggebers gegenüber dem Auftragnehmer in Schrift- oder Textform (bspw. E-Mail). Der Auftraggeber wird sich bemühen, optionale Leistungen frühzeitig, spätestens jedoch vier Wochen im Voraus anzukündigen und abzurufen. Der Auftragnehmer ist im Falle des Abrufs einer optionalen Leistung zu deren Ausführung zu den im Preisblatt angebotenen Preisen verpflichtet, d.h. dass in diesem Fall eine Leistungspflicht des Auftragnehmers besteht. Der Auftragnehmer sollte daher zur (etwaigen) Ausführung der optionalen Leistungen personelle und technische Kapazitäten vorhalten oder deren Aktivierung zumindest einplanen. Der Auftraggeber wird bei Bedarf als optionale Leistung zusätzliche IT-Dienstleistungen im Zusammenhang mit der in diesem Los dieser Leistungsbeschreibung dargestellten (zwingend zu erbringenden) Hauptleistungen abrufen.
1) Die in Los 2 als Hautpleistung beschriebene Deploymentanzahl kann unter Umständen unzureichend sein, daher können bis zu 30 weitere Deploymentvorgänge nötig sein. Bei Bedarf wird der Auftraggeber die Durchführung dieser zusätzlichen Deploymentvorgänge als optionale Leistungen abrufen.
2) Die in diesem Los 2 als Hauptleistung beschriebene Anzahl an durchzuführenden Klonen kann unter Umständen unzureichend sein, daher können bis zu 10 weitere Klonvorgänge nötig sein. Bei Bedarf wird der Auftraggeber die Durchführung dieser zusätzlichen Klonvorgänge als optionale Leistungen abrufen.
Abschnitt IV: Verfahren
Abschnitt V: Auftragsvergabe
Betrieb und Wartung von Front-, Middle-Tier und Oracle DB
Postanschrift:[gelöscht]
Ort: Bayreuth
NUTS-Code: DE242 Bayreuth, Kreisfreie Stadt
Postleitzahl: 95444
Land: Deutschland
E-Mail: [gelöscht]
Abschnitt V: Auftragsvergabe
Betrieb der Softwarelösung TUMonline
Postanschrift:[gelöscht]
Ort: Bayreuth
NUTS-Code: DE242 Bayreuth, Kreisfreie Stadt
Postleitzahl: 95444
Land: Deutschland
E-Mail: [gelöscht]
Abschnitt VI: Weitere Angaben
Bekanntmachungs-ID: CXP4Y9PRFRA
Postanschrift:[gelöscht]
Ort: München
Postleitzahl: 80538
Land: Deutschland
E-Mail: [gelöscht]
Telefon: [gelöscht]
Fax: [gelöscht]
Gemäß § 160 Abs. 3 Satz 1 des Gesetzes gegen Wettbewerbsbeschränkungen (GWB) ist ein Nachprüfungsantrag unzulässig, soweit
- der Antragsteller den geltend gemachten Verstoß gegen Vergabevorschriften vor Einreichen des Nachprüfungsantrags erkannt und gegenüber dem Auftraggeber nicht innerhalb einer Frist von zehn Kalendertagen gerügt hat; der Ablauf der Frist nach § 134 Abs. 2 GWB bleibt unberührt,
- Verstöße gegen Vergabevorschriften, die aufgrund der Bekanntmachung erkennbar sind, nicht spätestens bis zum Ablauf der in der Bekanntmachung benannten Frist zur Bewerbung oder zur Angebotsabgabe gegenüber dem Auftraggeber gerügt werden,
- Verstöße gegen Vergabevorschriften, die erst in den Vergabeunterlagen erkennbar sind, nicht spätestens bis zum Ablauf der Frist zur Bewerbung oder zur Angebotsabgabe gegenüber dem Auftraggeber gerügt werden,
- mehr als 15 Kalendertage nach Eingang der Mitteilung des Auftraggebers, einer Rüge nicht abhelfen zu wollen, vergangen sind. Satz 1 gilt nicht bei einem Antrag auf Feststellung der Unwirksamkeit des Vertrags nach § 135 Abs. 1 Nr. 2 GWB. § 134 Abs. 1 Satz 2 GWB bleibt unberührt.
Gemäß § 134 Abs. 1 GWB haben öffentliche Auftraggeber die Bieter, deren Angebote nicht berücksichtigt werden sollen, über den Namen des Unternehmens, dessen Angebot angenommen werden soll, über die Gründe der vorgesehenen Nichtberücksichtigung ihres Angebots und über den frühesten Zeitpunkt des Vertragsschlusses unverzüglich in Textform zu informieren. Dies gilt auch für Bewerber, denen keine Information über die Ablehnung ihrer Bewerbung zur Verfügung gestellt wurde, bevor die Mitteilung über die Zuschlagsentscheidung an die betroffenen Bieter ergangen ist.
Gemäß § 134 Abs. 2 GWB darf ein Vertrag erst zehn (10) Kalendertage nach Absendung (per Telefax, E-Mail oder elektronisch über die Vergabeplattform DTVP) der Information nach 134 Abs. 1 GWB geschlossen werden. Die Frist beginnt am Tag nach der Absendung der Information durch den Auftraggeber; auf den Tag des Zugangs beim betroffenen Bieter und Bewerber kommt es nicht an.
Ein öffentlicher Auftrag ist gemäß § 135 Abs. 1 GWB von Anfang an unwirksam, wenn der öffentliche Auftraggeber (i) gegen § 134 verstoßen hat oder (ii) den Auftrag ohne vorherige Veröffentlichung einer Bekanntmachung im Amtsblatt der Europäischen Union vergeben hat, ohne dass dies aufgrund Gesetzes gestattet ist, und dieser Verstoß in einem Nachprüfungsverfahren festgestellt worden ist. Gemäß § 135 Abs. 2 Satz 1 GWB kann die Unwirksamkeit nach § 135 Abs. 1 GWB nur festgestellt werden, wenn sie im Nachprüfungsverfahren innerhalb von 30 Kalendertagen nach der Information der betroffenen Bieter und Bewerber durch den öffentlichen Auftraggeber über den Abschluss des Vertrags, jedoch nicht später als sechs Monate nach Vertragsschluss geltend gemacht worden ist. Hat der Auftraggeber die Auftragsvergabe im Amtsblatt der Europäischen Union bekannt gemacht, endet die Frist zur Geltendmachung der Unwirksamkeit 30 Kalendertage nach Veröffentlichung der Bekanntmachung der Auftragsvergabe im Amtsblatt der Europäischen Union.