Anforderungserfüllungsmatrix (Compliance-Matrix)

Jede Anforderung ist einzeln, eindeutig und ohne Widerspruch zu beantworten. Leere Felder, rein werbliche Aussagen, bloße Produktversprechen oder pauschale Verweise wie „siehe Angebot“, „im Standard vorhanden“ oder „kann bereitgestellt werden“ sind nicht ausreichend.

Enthält eine Anforderung mehrere Teilaspekte, muss die Antwort alle Teilaspekte ausdrücklich abdecken oder die Antwort ist auf mehrere Zeilen aufzuteilen, sofern die ausgegebene Matrix dies vorsieht.

• Die vom Auftraggeber vorgegebenen Anforderungs-IDs, Bezeichnungen, Klassifizierungen und Spaltenstrukturen dürfen nicht verändert werden.

• Zeilen dürfen nicht gelöscht, zusammengefasst oder in ihrer Reihenfolge verändert werden, sofern dies nicht ausdrücklich zugelassen ist.

• Zusätzliche Erläuterungen dürfen in Anhängen erfolgen, ersetzen aber niemals die verpflichtenden Einträge in der Matrix selbst.

Die Antworten sind knapp, aber so konkret zu formulieren, dass die praktische Erfüllung der Anforderung nachvollziehbar wird. Aus der Antwort muss hervorgehen, durch welchen Lösungsbestandteil, in welcher Betriebs- oder Lieferlogik und mit welchen fachlichen oder technischen Rahmenbedingungen die Anforderung erfüllt wird.

Soweit relevant, ist anzugeben, ob die Erfüllung durch Standardfunktionalität, Konfiguration, kundenspezifische Anpassung, Schnittstelle, Drittkomponente, organisatorische Leistung oder eine Kombination dieser Elemente erfolgt.

• Benennung des relevanten Moduls, Prozesses, Servicebausteins oder Architekturbausteins

• Angabe, ob die Funktion zum geforderten Zeitpunkt [Stichtag / Go-live] produktiv verfügbar ist

• Beschreibung erkennbarer Einschränkungen, Ausschlüsse, Mengengerüste, Rollenabhängigkeiten oder Vorbedingungen

• Hinweis auf notwendige zusätzliche Lizenzen, Services, Datenbereitstellungen oder Mitwirkungsleistungen

Jeder Matrixeintrag ist mit mindestens einer nachvollziehbaren Evidenzreferenz zu unterlegen, sofern die Vergabeunterlagen keine abweichende Regel treffen. Referenzen müssen so präzise sein, dass die zugrunde liegende Aussage in angemessener Zeit aufgefunden und geprüft werden kann.

Als Nachweise kommen insbesondere in Betracht: Kapitel des technischen Angebots, Anlagen, Produktdatenblätter, Prozessbeschreibungen, Sicherheitsdokumentationen, Implementierungskonzepte, Servicebeschreibungen, Musterberichte, Architekturübersichten oder sonstige belastbare Unterlagen.

• Referenzen sollen mindestens Dokumenttitel, Versionsstand bzw. Datum sowie Abschnitt, Seite oder Nummer enthalten.

• Allgemeine Verweise auf komplette Dokumente ohne Stellenangabe gelten nicht als hinreichend präzise.

• Falls ein Nachweis von einer Drittquelle stammt, ist kenntlich zu machen, inwieweit dessen Inhalt Bestandteil des verbindlichen Angebots wird.

Alle Annahmen, Drittabhängigkeiten, kundenseitigen Mitwirkungspflichten und technischen oder organisatorischen Vorbedingungen, die für die Erfüllung einer Anforderung relevant sind, sind offen zu legen. Dies gilt insbesondere für Voraussetzungen hinsichtlich Datenqualität, Datenverfügbarkeit, Rollenbesetzung, Zugriffsrechten, Netzwerkanbindung, Endgeräten, Mandantenstruktur, Sprachen, Betriebszeiten, Sicherheitsfreigaben und Vorleistungen aus anderen Projekten oder Verträgen.

Jede solche Annahme oder Abhängigkeit ist sowohl in der betreffenden Matrixzeile als auch im Register für Annahmen und Abhängigkeiten aufzuführen, sofern sie die Leistungsfähigkeit, den Zeitplan, den Aufwand, die Kosten, das Betriebsmodell oder die Verantwortungsabgrenzung beeinflussen kann.

Jede Nicht-Erfüllung, Teil-Erfüllung, funktionale Lücke, manuelle Zwischenlösung, spätere Nachlieferung, Einschränkung oder alternative Erfüllungslogik ist transparent zu kennzeichnen. Ein Workaround mit zusätzlichen manuellen Tätigkeiten, Nebensystemen, separaten Beschaffungsschritten oder nicht im Basisangebot enthaltenen Zusatzleistungen ist grundsätzlich nicht als vollumfängliche Erfüllung zu kennzeichnen, es sei denn, die betreffende Anforderung lässt dies ausdrücklich zu und sämtliche Auswirkungen sind offengelegt.

Sämtliche Abweichungen und Qualifizierungen sind zusätzlich im Abweichungsregister zusammenzufassen.

Aussagen zu künftigen Releases, Roadmap-Funktionen oder geplanten Weiterentwicklungen dürfen nur dann als Erfüllungsbeitrag berücksichtigt werden, wenn sie verbindlich in den Lieferumfang des Angebots aufgenommen werden, mit einem belastbaren Bereitstellungstermin versehen sind und keine unaufgedeckten Risiken für den geforderten Einführungszeitpunkt [Stichtag / Go-live] erzeugen.

Ist eine Funktion zum geforderten Zeitpunkt nicht verbindlich verfügbar, ist die Anforderung mindestens als „PC“ oder „ALT“ zu kennzeichnen; eine Kennzeichnung als „FC“ ist in diesem Fall unzulässig.

Die Antworten in der Matrix müssen mit dem technischen Konzept, dem Implementierungs- und Migrationsansatz, dem Service- und Supportmodell, den kommerziellen Formularen, eventuellen Preisblättern, etwaigen Vertragsqualifizierungen und allen sonstigen Angebotsbestandteilen übereinstimmen.

Wird eine Leistung in der Matrix als enthalten dargestellt, muss dieselbe Leistungslogik in den übrigen Angebotsunterlagen wiederzufinden sein. Umgekehrt dürfen kommerzielle oder rechtliche Vorbehalte die in der Matrix erklärte Erfüllung nicht stillschweigend einschränken.

Die Matrix ist im ausgegebenen Format [Dateiformat] sowie, soweit gefordert, zusätzlich in einer signierten Fassung [Dateiformat] einzureichen. Sofern die Matrix als bearbeitbare Tabelle bereitgestellt wird, dürfen Formeln, Filter, Blattbezeichnungen, Schutzmechanismen und Referenzstrukturen nicht verändert werden, soweit dies nicht ausdrücklich freigegeben ist.

Dateibezeichnungen, Versionsangaben und Anlagenreferenzen sind nach der vorgegebenen Namenskonvention [Namenskonvention] zu bilden.

• Sofern ausdrücklich verlangt, ist eine Änderungsübersicht je Angebotsrunde beizufügen.

• Kommentare oder Änderungsmarkierungen sind nur zulässig, wenn dies in den Vergabeunterlagen vorgesehen ist.

• Alle eingefügten Zusatzblätter oder Anhänge sind im Anlagenverzeichnis aufzuführen.

Soweit nichts anderes vorgegeben ist, sind die Antworten in der Sprache [Sprache der Angebotsabgabe] abzufassen. Zeitangaben sind eindeutig als Kalendertage, Arbeitstage, Geschäftszeiten, Stunden oder Minuten zu bezeichnen; Datumsangaben sind im Format [Datumsformat] anzugeben.

Abkürzungen, Fachbegriffe und interne Produktbegriffe des Bieters sind bei erstmaliger Verwendung zu erläutern, sofern sie für die Bewertung nicht allgemein verständlich sind.

Jede Anforderung erhält eine eindeutige Referenznummer, beispielsweise [REQ-0001]. Diese Referenznummer ist in allen Angebotsunterlagen, Rückfragen, Klarstellungen, Verhandlungsprotokollen und aktualisierten Fassungen der Matrix unverändert zu verwenden.

Änderungen an Anforderungstexten oder Referenznummern durch den Bieter sind unzulässig. Wird eine Anforderung im Verfahren präzisiert, ergänzt oder ersetzt, ist auf die jeweils durch den Auftraggeber veröffentlichte Fassung Bezug zu nehmen.

Die Anforderungen sind mindestens nach ihrer vergabefachlichen Bedeutung zu kennzeichnen. Üblich sind die Kategorien „Muss“, „Bewertet“ und „Verhandelbar“.

Muss-Anforderungen beschreiben Mindestanforderungen oder besonders wesentliche Anforderungen. Bewertete Anforderungen fließen in die qualitative Angebotsbewertung ein. Verhandelbare Anforderungen können Gegenstand der Verhandlung sein, müssen jedoch bereits im Erstangebot mit einer vollständigen und belastbaren Position beantwortet werden.

Die Matrix ist in logisch zusammenhängende Anforderungsgruppen zu gliedern, damit Fachbereiche, IT, Betrieb, Einkauf und Entscheidungsgremien die Antworten effizient prüfen können. Folgende Struktur ist als generischer Mindestaufbau empfohlen, soweit die jeweilige Beschaffung diese Themen abdeckt:

Plattform und Systemarchitektur

Dieser Abschnitt umfasst unter anderem Systemarchitektur, Bereitstellungsmodell, Hosting, Mandanten- und Umgebungslogik, Skalierbarkeit, Verfügbarkeit, Rollen- und Berechtigungsverwaltung, Authentifizierung, Administrationsfunktionen, Protokollierung, Mandanten- oder Objektstrukturen, Mehrsprachigkeit, mobile Nutzbarkeit und allgemeine Usability- oder Barrierefreiheitsanforderungen.

Funktionale CAFM-Fähigkeiten

Hierzu zählen insbesondere Stammdaten- und Objektverwaltung, Asset- und Anlagenverwaltung, vorbeugende und reaktive Instandhaltung, Tickets und Service Requests, Auftrags- und Leistungssteuerung, Flächen- und Raumverwaltung, Belegungs- und Reservierungsfunktionen, Vertrags- und Fristenmanagement, Prüf- und Compliance-Aufgaben, Dokumentenverknüpfung, mobile Bearbeitung, Offline-Fähigkeit sowie die Unterstützung relevanter FM-Prozesse.

Integration und Interoperabilität

Dieser Abschnitt deckt Schnittstellen, Integrationsmuster, Import- und Exportmechanismen, Programmierschnittstellen, Ereignisverarbeitung, Dateischnittstellen und die Anbindung an andere Unternehmenssysteme ab, beispielsweise an kaufmännische Systeme, Personal- oder Organisationssysteme, Identitäts- und Zugriffsmanagement, Dokumentenmanagement, Gebäude- und Sensordatenquellen oder sonstige fachlich relevante Drittsysteme.

Datenmigration und Stammdaten

Hierzu gehören Bestandsdatenübernahme, Datenmapping, Datenbereinigung, Datenqualitätsanforderungen, Importwerkzeuge, Migrationsverantwortlichkeiten, Probeläufe, Abstimm- und Freigabeverfahren, Schnittstellendaten, Historienübernahme sowie die laufende Pflege und Governance von Stammdaten.

Reporting, Dashboards und Nachvollziehbarkeit

Dieser Abschnitt umfasst Standardberichte, Ad-hoc-Auswertungen, Kennzahlen, Dashboards, Exportfunktionen, Zeitplanung von Berichten, Verteillogiken, Audit-Trail, Änderungsprotokolle, Nachvollziehbarkeit von Vorgängen und revisionsgerechte Dokumentation, soweit gefordert.

Informationssicherheit und Datenschutz

Hierzu zählen Zugriffsschutz, Rollen- und Rechtemanagement, Protokollierung sicherheitsrelevanter Ereignisse, Verschlüsselung, Schlüsselmanagement, Sicherung und Wiederherstellung, Resilienz, Schwachstellenmanagement, Incident-Prozesse, Aufbewahrungs- und Löschkonzepte, Datenlokation, Unterauftragnehmersteuerung sowie die Erfüllung anwendbarer Datenschutz- und Sicherheitsverpflichtungen.

Implementierung, Schulung und Support

Dieser Abschnitt beschreibt Einführungsmethodik, Projektgovernance, Konfigurationsansatz, Test- und Abnahmemethodik, Datenmigration, Schulungs- und Enablement-Konzept, Hypercare, Service Desk, Supportmodell, Eskalationswege, Service Levels, Wartung, Release-Management und Change-Prozesse.

Die nachfolgend definierte Tabellenstruktur ist von allen Bietern einheitlich zu verwenden. Der Auftraggeber kann zusätzliche Spalten, etwa zu Priorität, Bewertungsgewicht, Zielrelease oder Verfahrenshinweisen, ergänzen; die nachstehenden Spalten bilden jedoch den verbindlichen Mindestumfang.

Der Auftraggeber kann zusätzliche Verfahrensspalten vorsehen, beispielsweise für Bewertungsgewichte, Verhandlungsvermerke oder interne Referenzen. Solche Zusatzspalten ändern nicht die Pflicht des Bieters, die oben genannten Mindestspalten vollständig auszufüllen.

Alle Bieter haben dieselben Statuscodes zu verwenden. Abweichende oder selbst definierte Kennzeichnungen sind nicht zulässig. Für jede Zeile ist genau ein Statuscode einzutragen.

* Die Kennzeichnung „N/A“ ist nur zulässig, wenn der Auftraggeber die Nichtanwendbarkeit für die betreffende Zeile ausdrücklich vorsieht oder bestätigt.

Statuscodes allein genügen nicht. Jeder Status ist durch eine inhaltliche Antwort, die Erfüllungsmethode, etwaige Qualifizierungen, Evidenzen und Auswirkungen zu unterlegen.

• Mehrfachkennzeichnungen in einer Zeile sind unzulässig.

• Zusätzliche Kosten, Zusatzlizenzen, Zusatzmodule, notwendige Fremdleistungen oder Projektvoraussetzungen sind transparent auszuweisen.

• Aussagen wie „optional“, „auf Anfrage“, „im Roadmap-Plan“, „kundenspezifisch möglich“ oder „im Einzelfall umsetzbar“ gelten ohne belastbare Konkretisierung nicht als ausreichender Erfüllungsnachweis.

• Soweit eine Anforderung nur über eine Drittkomponente erfüllt wird, ist dies sowohl in der Spalte „Erfüllungsmethode“ als auch im Drittkomponentenregister auszuweisen.

Abweichungen von Muss-Anforderungen sind in der Matrix und im Abweichungsregister ausdrücklich zu kennzeichnen. Je nach anwendbaren Vergaberegeln können solche Abweichungen die Zulässigkeit, die Bewertbarkeit oder die Wertung des Angebots beeinflussen.

Die bloße Erwartung, dass eine Muss-Anforderung in einer späteren Verhandlungsrunde noch gelöst werden kann, ersetzt keine vollständige Erstantwort.

Alternative oder funktional gleichwertige Lösungsansätze dürfen nur insoweit angeboten werden, wie dies nach den Vergabeunterlagen zulässig ist. Der Bieter hat die Gleichwertigkeit oder die funktionale Überlegenheit nachvollziehbar zu erläutern und sämtliche Auswirkungen auf Prozesse, Schnittstellen, Daten, Rollen, Schulung, Betrieb, Sicherheit, Migration, Zeitplan und Kosten offenzulegen.

Eine alternative Lösung ersetzt die verlangte Antwort nicht; der Status „ALT“ ist nur zulässig, wenn die alternative Erfüllungslogik vollständig beschrieben wird.

Anforderungen oder Vertragsbestandteile, die als verhandelbar gekennzeichnet sind, können im weiteren Verfahren vertieft besprochen werden. Gleichwohl hat der Bieter bereits im Erstangebot seine Ausgangsposition vollständig, transparent und mit allen wesentlichen Parametern darzustellen.

Es ist nicht zulässig, verhandelbare Elemente ohne konkrete Ausgangsposition offen zu lassen oder pauschal auf spätere Einigung zu verweisen.

Jede Abweichung, Qualifizierung oder Alternative ist mit einer klaren Auswirkungenserklärung zu versehen. Diese muss mindestens erkennen lassen, ob und wie sich die betreffende Aussage auf Leistungsumfang, Implementierungsaufwand, Datenmigration, Schnittstellen, Nutzerprozesse, Betriebsmodell, Lizenzen, Vergütung, Terminplan, Service Level, Informationssicherheit, Abnahme oder spätere Exit-Fähigkeit auswirkt.

Jede Abweichung, Qualifizierung oder Alternative ist mit einer klaren Auswirkungenserklärung zu versehen. Diese muss mindestens erkennen lassen, ob und wie sich die betreffende Aussage auf Leistungsumfang, Implementierungsaufwand, Datenmigration, Schnittstellen, Nutzerprozesse, Betriebsmodell, Lizenzen, Vergütung, Terminplan, Service Level, Informationssicherheit, Abnahme oder spätere Exit-Fähigkeit auswirkt.

Allgemeine Geschäftsbedingungen, Standardproduktbeschränkungen, externe Lizenzbedingungen oder sonstige Dokumente des Bieters dürfen eine in der Matrix erklärte Erfüllung nicht verdeckt einschränken. Soweit solche Inhalte für die Erfüllungsbewertung relevant sind, sind sie ausdrücklich und anforderungsspezifisch als Qualifizierung oder Abweichung auszuweisen.

Werden im Verfahrensverlauf überarbeitete Angebotsfassungen verlangt, ist eine aktualisierte Matrix mit neuem Versionsstand [Version], Datum [Datum] und nachvollziehbarer Änderungskennzeichnung einzureichen. Änderungen sind so darzustellen, dass die Entwicklung gegenüber der Vorversion ohne unverhältnismäßigen Prüfaufwand erkennbar ist.

Alle Referenzen in der Matrix müssen auf tatsächlich eingereichte Unterlagen verweisen. Dokumenttitel, Versionsstände und Seiten- oder Abschnittsangaben müssen konsistent sein; widersprüchliche Querverweise sind vom Bieter vor Abgabe zu bereinigen.

Die Matrix verlangt sachliche, belastbare und prüfbare Aussagen. Allgemeine Marketingformulierungen, unkommentierte Textbausteine oder bloß reproduzierte Produktwerbung ohne Bezug zur konkreten Anforderung sind nicht ausreichend.

Auf Verlangen des Auftraggebers muss der Bieter seine Aussagen durch ergänzende Unterlagen, eine Demonstration, eine beispielhafte Konfiguration, Musterberichte, Architektur- oder Sicherheitsunterlagen oder sonstige zulässige Nachweise substantiieren können.

Vor Einreichung hat der Bieter zu prüfen und intern freizugeben, dass die Matrix vollständig, fachlich zutreffend, widerspruchsfrei, aktuell und mit allen begleitenden Angebotsunterlagen abgestimmt ist. Dies umfasst insbesondere die Abstimmung zwischen Vertrieb, Fachkonzept, Produktmanagement, Implementierung, Support, Informationssicherheit, Preisstellung und rechtlicher Angebotsprüfung.

Alle Antworten müssen sich auf die tatsächlich angebotene Version, den angebotenen Servicestand oder das angebotene Bereitstellungsmodell beziehen. Soweit eine Aussage nur für eine spätere Version gilt, ist dies ausdrücklich kenntlich zu machen und mit Termin, Verbindlichkeit und Auswirkung zu versehen.

Der Bieter hat mit Abgabe der Matrix zu erklären, dass die eingetragenen Angaben vollständig, zutreffend und durch eine vertretungsberechtigte Person freigegeben sind. Eine Mustererklärung ist in Anlage K enthalten.

Jede eingereichte Fassung der Matrix und der strukturierten Angebotsformulare muss mindestens folgende Metadaten tragen: [Bietername], [Angebotsreferenz], [Versionsstand], [Datum], [Kontaktperson] und [Dateibezeichnung].

Der Bieter benennt eine fachlich verantwortliche und eine kommerziell oder verfahrensseitig verantwortliche Kontaktperson für Rückfragen während Prüfung, Aufklärung und Verhandlung. Vertretungsregelungen sind anzugeben.

Sofern in den Vergabeunterlagen nichts anderes festgelegt ist, sind die strukturierten Angebotsformulare und die Compliance Matrix mindestens in einer bearbeitbaren Fassung [Format] sowie in einer verbindlich freigegebenen, nicht ohne Weiteres veränderbaren Fassung [Format] einzureichen.

Die nachstehenden Anlagen bilden die Mindeststruktur der strukturierten Angebotsformulare für die Angebotsabgabe. Soweit der Auftraggeber nicht einzelne Anlagen als optional kennzeichnet, sind sie vollständig auszufüllen und zusammen mit der Anforderungenserfüllungsmatrix einzureichen.

• Anlage A – Bieterstammdaten

• Anlage B – Verzeichnis der Angebotsunterlagen

• Anlage C – Zusammenfassung der Compliance-Status

• Anlage D – Register für Abweichungen, Qualifizierungen und Alternativen

• Anlage E – Register für Annahmen, Abhängigkeiten und Mitwirkungspflichten

• Anlage F – Register für Drittkomponenten und Partnerleistungen

• Anlage G – Implementierungs-, Migrations- und Schulungsprofil

• Anlage H – Support- und Serviceprofil

• Anlage I – Evidenz- und Referenzindex

Die nachfolgenden Anlagen sind als ausfüllbare Formblätter gestaltet und können durch zusätzliche Zeilen ergänzt werden, soweit dies zur vollständigen Darstellung des Angebots erforderlich ist. Die Grundstruktur und Bezeichnung der Felder bleibt unverändert.

Dieses Formblatt dient der eindeutigen Identifikation des Bieters und der für das Angebot verantwortlichen Ansprechpartner.

Alle mit dem Angebot eingereichten Dokumente und Anlagen sind vollständig aufzuführen.

Diese Übersicht dient der schnellen Einordnung des Angebots und ist mit den Einzelergebnissen der Matrix konsistent zu führen.

Kurzer Gesamtkommentar zu wesentlichen Abweichungen oder Schwerpunktstärken: [Freitext].

Jede Abweichung, Qualifizierung oder alternative Erfüllungslogik ist zusätzlich zur Einzelzeile der Matrix in diesem Register zusammenzufassen.

Alle für die Erfüllung relevanten Annahmen, Drittabhängigkeiten und kundenseitigen Mitwirkungspflichten sind hier zusammenzufassen.

Alle Drittkomponenten, Partnerleistungen, Unterauftragnehmeranteile oder sonstigen externen Lösungsbausteine, die für die Erfüllung relevant sind, sind offen zu legen.

Soweit für eine Drittkomponente besondere Datenverarbeitungs-, Sicherheits- oder Exportbedingungen gelten, sind diese zusätzlich in den jeweiligen Angebotsunterlagen zu erläutern.

Dieses Formblatt beschreibt den generischen Projektansatz des Bieters für Einführung, Datenübernahme, Tests, Schulung und Übergang in den Betrieb.

[Freitext zu Projektmethodik, Steuerungsmodell, Phasenschnitt, Konfigurationsansatz und Abgrenzung zwischen Standard, Konfiguration und Anpassung]

[Go-live-Ansatz: ...] [Annahmen zum Cutover: ...] [Hypercare-Dauer: ...] [Leistungsumfang in Hypercare: ...]

Dieses Formblatt beschreibt die vorgesehenen Betriebs-, Support- und Serviceparameter des angebotenen Lösungsumfangs.

Dieses Verzeichnis dient der strukturierten Zuordnung aller Nachweise, auf die in der Matrix und in den Formblättern verwiesen wird.