Angebotsversions-Tracking

Jede Einreichung ist nur dann als eigenständige Angebotsversion zu behandeln, wenn sie eindeutig identifiziert werden kann. Das interne Team akzeptiert keine „unklaren“ Versionen ohne eindeutige Kennzeichnung; stattdessen wird – sofern verfahrensrechtlich zulässig – eine formale Klarstellung über den offiziellen Kanal veranlasst. Unabhängig davon gilt intern: Ohne eindeutige Versionskennzeichnung besteht ein erhöhtes Risiko falscher Zuordnung, daher wird die Version als „nicht bewertungsfähig bis geklärt“ markiert.

Jede Einreichung muss mindestens enthalten: (a) den Bieternamen in der Form, wie er in der Plattform registriert ist, (b) eine Versionsbezeichnung nach dem Schema V1/V2/V3/… oder BAFO, (c) Datum und Uhrzeit der Submission gemäß [Zeitzone/Standard: ______], (d) eine Zuordnung zur Verhandlungsrunde oder zum Auslöser (z. B. „Runde []“, „Klarstellung“, „BAFO-Aufforderung“), sowie (e) eine explizite Ersetzungsformulierung: „Diese Version ersetzt sämtliche vorherigen Einreichungen vollständig.“ Falls nur Teile ersetzt werden (siehe 5.2), muss dies ausdrücklich und vollständig aufgelistet sein.

Intern wird jede Bietereinreichung als neue Version erfasst, sobald sie über den offiziellen Einreichungsweg eingeht und die Einreichung als „abgeschlossen“ gekennzeichnet ist. Versionen werden fortlaufend pro Bieter gezählt (V1, V2, V3 …), unabhängig davon, ob sie als „gültig“ anerkannt werden; ungültige Versionen werden nicht gelöscht, sondern als „abgelehnt/nicht konform“ markiert. BAFO ist stets eine eigene Kategorie und wird zusätzlich als „Final“ gekennzeichnet.

Für die interne Ablage wird ein einheitliches Dateinamensschema verwendet, unabhängig davon, wie der Bieter Dateien benannt hat. Das interne Team legt eine „Originaldatei“ unverändert ab und erzeugt zusätzlich eine „Arbeitskopie“ mit Standardnamen. Empfohlenes internes Format:
CAFM_Tender_[Vergabereferenz][BieterKurzname][Version][YYYYMMDD][HHMM]
Beispiel mit Platzhaltern:
CAFM_Tender_[BidderName]V2[DDMMYYYY]_[HHMM]
Das interne Team stellt sicher, dass die Bindung an den Portal-Zeitstempel nachvollziehbar bleibt, indem Portalbestätigungen/Receipts zusammen mit der Version abgelegt werden.

Das Replacement Statement ist für die Bewertung entscheidend. Fehlt es, besteht das Risiko paralleler Geltung widersprüchlicher Dokumente. Intern gilt: Ohne Replacement Statement wird die Version als „unvollständig“ markiert und es wird geprüft, ob eine Klarstellung zulässig und notwendig ist. Wenn Teilersetzungen zulässig sind, muss die Einreichung eine vollständige Liste enthalten, welche Dokumente ersetzt werden und welche unverändert bleiben.

Jede Version wird einem Trigger zugeordnet, um die Nachvollziehbarkeit zu gewährleisten. Trigger können sein: „Erstangebot“, „Verhandlungsrunde []“, „BAFO“, „Reaktion auf Addendum []“, „Reaktion auf Q&A Batch [__]“, „Formale Klarstellung/Fehlerkorrektur“ oder „Sonstiges (mit Begründung)“. Intern wird pro Trigger festgelegt, welche Änderungen zulässig sind und welche Dokumente zwingend aktualisiert werden müssen (z. B. Preisblatt bei kommerziellen Änderungen).

Das Master-Register ist die einzige „Single Source of Truth“ für die Versionshistorie. Es wird zentral geführt und ist zugriffsgeschützt. Änderungen am Register erfolgen nur durch [Rolle: ________] nach dem Vier-Augen-Prinzip, wobei jede Änderung mit Datum, Bearbeiter und Begründung protokolliert wird. Zusätzlich werden die zugehörigen Artefakte (Submission Receipt, Checksums, Change Logs) mit derselben Versions-ID verknüpft.

Die nachfolgende Tabelle ist als Mindeststandard zu verwenden und kann projektbezogen erweitert werden. Alle Felder sind mit Platzhaltern zu befüllen.

Für eine robuste Vergabeakte wird empfohlen, das Register um folgende Felder zu ergänzen: (a) Portal-Submission-ID, (b) Hash/Checksumme der ZIP/PDF, (c) Ergebnis Formalkontrolle (OK/Abweichung), (d) Ergebnis Mindestanforderungen (OK/Abweichung), (e) Verweis auf Verhandlungsprotokoll/Minutes-ID, (f) Freigabevermerk (wer hat „aktiv“ gesetzt), und (g) Hinweis auf erforderliche Addenda/Klarstellungen, falls eine Version Inkonsistenzen auslöst.

Jede revidierte Einreichung muss Änderungen transparent machen. Intern wird keine Version als „aktiv“ freigegeben, wenn Änderungen nicht nachvollziehbar dokumentiert sind, weil dies Bewertungs- und Gleichbehandlungsrisiken erzeugt. Änderungen dürfen nicht „stillschweigend“ erfolgen; das interne Team prüft dies anhand von Markup-Dateien, Change Logs und – falls erforderlich – mittels Dokumentvergleich.

Jede Version ab V2 muss eine kurze, aber vollständige Executive Summary enthalten, die die wichtigsten Änderungen gegenüber der Vorversion zusammenfasst. Diese Summary muss sich getrennt auf (a) technische Lösung/Scope, (b) kommerzielle Inhalte/Preisstruktur und (c) Vertragskommentare beziehen. Intern wird die Summary ins Register übertragen (Kurzfassung) und als Dokument im Versionsordner abgelegt.

Die Einreichung muss entweder eine redline/track-changes-Version enthalten oder ein strukturiertes Change Log, das eindeutig auf Dokumentabschnitte/Anlagen verweist. Wenn die Bieterunterlagen keinen Track-Changes-Modus unterstützen (z. B. PDF-only), wird ein Change Log zwingend erwartet. Intern wird bei Bedarf zusätzlich ein eigener Vergleich erstellt (nur intern), um die Konsistenz sicherzustellen.

Sobald Preise, Mengengerüste, Annahmen oder Rabattmechaniken geändert werden, ist ein aktualisiertes Preisblatt erforderlich. Zusätzlich muss der Bieter den Delta zur Vorversion klar ausweisen (z. B. „alt → neu“ oder „Differenzbetrag“ je Preisposition). Intern erfolgt eine unabhängige Plausibilisierung der Deltas durch [Commercial Lead: ________] und eine Abgleichprüfung gegen die Verhandlungsminutes.

Um „stille“ Änderungen zu verhindern, muss der Bieter bestätigen, welche Dokumentteile unverändert bleiben. Intern wird geprüft, ob die Bestätigung plausibel ist (Stichprobenvergleich). Bei Widersprüchen wird die Version als „inkonsistent“ markiert und es wird geprüft, ob eine Klarstellung erforderlich ist.

Intern gilt die Regel, dass jede Änderung entweder (a) in einer Markup-Fassung sichtbar ist oder (b) im Change Log genannt wird. Wird eine Änderung entdeckt, die nicht dokumentiert ist, wird die Version als „nicht freigabefähig“ markiert, bis die Abweichung verfahrenskonform aufgeklärt ist. Die Entscheidung, ob dies zu einem Ausschluss-/Zurückweisungsrisiko führt, trifft ausschließlich die Vergabestelle unter Beachtung der anwendbaren Regeln.

Für jede Einreichung gilt die offizielle Deadline gemäß [Frist: ________]. Intern wird ausschließlich der Portalzeitstempel als maßgeblich dokumentiert. Versionen, die nach der Frist eingehen, werden als „verspätet“ markiert und nicht bewertet, es sei denn, es liegt eine dokumentierte, verfahrenskonforme Ausnahme vor (z. B. Plattformstörung nachweislich systemseitig).

Wenn das Verfahren Teilersetzungen zulässt, müssen diese eindeutig gekennzeichnet sein. Intern gilt: Teilersetzungen sind nur dann zulässig, wenn (a) die ersetzten Dokumente eindeutig benannt sind, (b) die unveränderten Dokumente als weiterhin gültig bestätigt werden, und (c) keine Widersprüche in Querverweisen entstehen. Das Team legt in diesem Fall eine „Version Map“ ab, die zeigt, welche Dokumente aus welcher Version gelten.

Verhandlungsinhalte, die nur mündlich besprochen wurden, sind nicht bindend und dürfen nicht in die Bewertung einfließen, solange sie nicht in einer schriftlichen Angebotsversion enthalten sind (oder verfahrenskonform in ein Addendum überführt wurden). Intern wird jede wesentliche Verhandlungsaussage einer „Umsetzungsprüfung“ unterzogen: Ist sie in der nächsten Version sichtbar? Falls nein, wird sie als „nicht umgesetzt“ dokumentiert.

Intern gilt: Bewertet wird immer nur die letzte fristgerechte und formell konforme Version, die als „aktiv“ markiert wurde. Frühere Versionen bleiben archiviert, werden aber nicht parallel bewertet. Wenn eine spätere Version formale Mängel aufweist, entscheidet die Vergabestelle, ob (a) Klarstellung zulässig ist, (b) die Version nicht berücksichtigt wird und die letzte konforme Version aktiv bleibt, oder (c) ein Ausschluss-/Zurückweisungsgrund vorliegt.

Eine BAFO-Einreichung muss ausdrücklich als „BAFO“ gekennzeichnet sein, sowohl im Anschreiben als auch im Dateinamen/Package. Intern wird BAFO zusätzlich als „Final“ markiert und gegen eine BAFO-Checkliste geprüft, um Vollständigkeit und Abschlusscharakter sicherzustellen.

Nach Ablauf der BAFO-Frist sind keine weiteren inhaltlichen Änderungen zulässig. Intern wird jede spätere Einreichung desselben Bieters als „nicht zulässig nach BAFO“ markiert und nicht in die Bewertung übernommen, außer es handelt sich um eine verfahrenskonform angeforderte formale Klarstellung ohne inhaltliche Verbesserung (dies ist eng auszulegen und zu dokumentieren).

BAFO supersediert alle vorherigen Versionen. Intern wird bei BAFO-Eingang automatisch der Status aller Vorversionen auf „ersetzt“ gesetzt und die BAFO als einzige „Final“-Version geführt. Querverweise in Evaluationsdokumenten werden auf BAFO umgestellt.

Nach BAFO erfolgt die finale Bewertung ausschließlich anhand der BAFO-Unterlagen und der bis dahin veröffentlichten, für alle Bieter verbindlichen Klarstellungen/Addenda. Interne Bewertungsnotizen müssen eindeutig die BAFO-Version referenzieren. Jede Abweichung (z. B. Nutzung einer älteren technischen Anlage) ist als Verfahrensrisiko zu behandeln und sofort zu korrigieren.

Alle Versionen werden in einem gesicherten Repository abgelegt: [Repository/Ordnerstruktur: ________]. Zugriffsrechte sind rollenbasiert und nach Need-to-know zu vergeben. Originaldateien werden unverändert gespeichert („read-only“), Arbeitskopien werden getrennt geführt. Jede Ablage enthält mindestens: Submission-Package, Portalbestätigung, Change Summary/Change Log, interne Checkliste, Hash/Checksumme, sowie relevante Freigabevermerke.

Die Versionshistorie muss unveränderbar bzw. manipulationssicher sein. Intern wird dies durch [Mechanismus: z. B. Berechtigungen, Write-Once-Archiv, Hashing, Protokollierung: ________] unterstützt. Jede nachträgliche Änderung (z. B. Umbenennung, Verschiebung) wird protokolliert und begründet.

Jede Bewertung, jedes Protokoll und jede Entscheidungsvorlage muss die konkrete Version nennen (z. B. „Bieter [], V3, eingegangen am []“). Interne Dokumente ohne Versionsbezug gelten als unvollständig und sind vor Abschluss der Bewertung zu korrigieren.

Die Aufbewahrung erfolgt nach [Regelwerk/Frist: ________]. Nach Ablauf der Frist wird archiviert oder gelöscht gemäß interner Governance. Datenschutz- und Vertraulichkeitsanforderungen sind einzuhalten; insbesondere sind personenbezogene Daten in den Angeboten entsprechend zu schützen und Zugriff zu beschränken.

Dieses Tracking wird durch interne Quality Gates ergänzt, um sicherzustellen, dass Versionen konsistent, vollständig und verfahrenskonform behandelt werden. Das Ziel ist, Fehler in der Bewertung zu verhindern, nicht nur „Dokumente zu sammeln“.

Vor jeder Bewertung einer neuen Version wird eine Version-Review-Checkliste ausgefüllt. Diese bestätigt, dass (a) die Version fristgerecht eingegangen ist, (b) Replacement Statement vorhanden ist, (c) Change Summary/Change Log vorhanden ist, (d) Preisänderungen nachvollziehbar sind, (e) Vertragsänderungen sauber markiert sind, und (f) Mindestanforderungen weiterhin erfüllt sind. Zusätzlich wird geprüft, ob Änderungen mit den Verhandlungsminutes übereinstimmen. Preisänderungen werden unabhängig verifiziert (z. B. Delta-Prüfung, Rechenprüfung, Plausibilität). Am Ende wird die Version durch [Freigaberolle: ________] als „aktiv“ freigegeben oder als „nicht freigabefähig“ zurückgestellt.

Dieses Tracking reduziert gezielt Verfahrens- und Bewertungsrisiken. Es verhindert insbesondere, dass Preisreduzierungen oder Rabatte ohne dokumentierte Grundlage in die Bewertung gelangen, dass Leistungsumfang still verändert wird, dass nach Fristablauf informelle „Korrekturen“ berücksichtigt werden, dass evaluierende Teams unterschiedliche Versionsstände verwenden oder dass rechtliche Angriffe auf Basis ungleicher Behandlung entstehen. Darüber hinaus schafft es einen belastbaren Nachweis, dass die finale Entscheidung ausschließlich auf den zulässigen und dokumentierten Angebotsständen basiert und dass jede Änderung im Verfahren nachvollziehbar gesteuert wurde.