Interne Risikoanalyse

Unzureichende Anzahl qualifizierter Bieter.
Wenn nur wenige geeignete Anbieter teilnehmen, steigt das Risiko, dass Preis- und Leistungsangebote weniger wettbewerbsgetrieben sind und die Verhandlungsposition des Auftraggebers schwächer ausfällt. Ursachen können ein zu enges Anforderungsprofil, kurze Fristen, fehlende Markttransparenz oder eine zu spezifische Zielarchitektur sein. Frühwarnindikatoren können eine geringe Anzahl von Teilnahmeanträgen, wenige Rückfragen im Q&A-Prozess oder wiederholte Hinweise aus dem Markt auf „zu hohe Einstiegshürden“ sein.

Vor Veröffentlichung sollte ein strukturiertes Market Sounding durchgeführt werden, Umfang und Fristen sollten gegen Marktrealität validiert werden, und Eignungskriterien sind so zu formulieren, dass sie notwendige Leistungsfähigkeit sichern, ohne unnötig Wettbewerb auszuschließen. Ergänzend kann der Auftraggeber klare Mindestanforderungen zur offenen Architektur und Interoperabilität setzen, um Alternativen zu proprietären Ökosystemen zu ermöglichen.

Dominanter Anbieter / Lock-in in proprietäre Lösung.
Insbesondere bei CAFM-Systemen besteht die Gefahr, dass ein Anbieter mit proprietären Datenmodellen, eingeschränkten Exportfunktionen oder stark kundenspezifischen Customizings einen Wechsel später wirtschaftlich unattraktiv macht. Dieses Risiko betrifft nicht nur den Betrieb, sondern bereits die Vergabe, weil Angebote mit geringer Offenheit schwer vergleichbar sind und langfristige Folgekosten verschleiern können.

In der Spezifikation und im Vertrag sind Open-API-Anforderungen, standardisierte Exportformate, Datenportabilität, Schnittstellendokumentation und klare Exit-Regelungen zu verankern. Zusätzlich sollte in der Bewertung Transparenz über Konfiguration vs. Customizing sowie Auswirkungen auf Upgradefähigkeit und Wartung gezielt geprüft werden.

Begrenzte Interoperabilität / Integrationsbarrieren.
Wenn Lösungen Integrationen nur über proprietäre Adapter oder kostenpflichtige Zusatzmodule erlauben, kann dies zu späteren Abhängigkeiten, Verzögerungen und Budgetrisiken führen. Früh sichtbar wird dies, wenn Anbieter in Q&A oder Verhandlungen unklare Aussagen zu APIs, Event-Mechanismen oder Datenzugriffsrechten machen.

Verpflichtende Interface-Dokumentation, definierte Mindestanforderungen an API-Sicherheit und -Funktionalität sowie ein Szenario zur Integrationsdemonstration (inkl. Monitoring und Fehlerhandling) reduzieren das Risiko. Intern sollte zusätzlich geprüft werden, welche Integrationen „kritisch“ sind und daher besonders stark abgesichert werden müssen.

Zu generische Anforderungen führen zu geringer Vergleichbarkeit.
Wenn Anforderungen unpräzise formuliert sind, entstehen Angebote, die formal „compliant“ erscheinen, aber in der Ausprägung und Leistungsfähigkeit stark variieren. Das erhöht Bewertungsunsicherheit, begünstigt subjektive Entscheidungen und schafft Angriffsflächen in möglichen Nachprüfungsverfahren. Typische Indikatoren sind viele Rückfragen zu Interpretation, sowie Angebotsinhalte mit stark variierenden Annahmen.

Anforderungen sollten in eine strukturierte Muss/Soll-Systematik überführt werden, ergänzt durch klare Definitionen, Akzeptanzkriterien und eine Compliance-Matrix. Fachbereiche (FM, IT, Einkauf, Datenschutz, Security) müssen die Spezifikation gemeinsam validieren. Wo nötig, sollte ein externer Review (z. B. Integrationsarchitektur, Security Baseline) eingeplant werden, ohne die Verantwortung nach außen zu verlagern.

Zu restriktive Anforderungen reduzieren Wettbewerb.
Übermäßig spezifische Produktvorgaben, enge Technologie-Festlegungen oder nicht zwingend notwendige Zertifikatsforderungen können den Markt unnötig einschränken. Das kann zu weniger Bietern, höheren Preisen und geringerer Innovationsfähigkeit führen.

Jede restriktive Anforderung muss intern begründet werden (z. B. Compliance, Sicherheit, bestehende IT-Strategie). Wo möglich, sollten funktionale und interoperable Anforderungen Vorrang vor Produkt-/Technologievorgaben haben. Alternativnachweise (gleichwertige Standards) sollten erlaubt werden, sofern vergaberechtlich zulässig.

Unvollständige Funktionsabdeckung / Scope-Lücken.
Wenn Prozesse oder Rollen nicht vollständig abgebildet sind (z. B. mobile Technikerprozesse, Eskalationslogik, Reporting, Daten-Governance), drohen Nachforderungen, Change Requests und Projektverzögerungen. Dieses Risiko zeigt sich oft erst in der Implementierungsphase, lässt sich aber durch frühe End-to-End-Szenarien deutlich reduzieren.

Szenariobasierte Anforderungen und Demo-Skripte (End-to-End) sind zentral. Intern ist sicherzustellen, dass alle kritischen FM-Prozessketten (präventiv/korrektiv, Asset, Reporting, Integration, Rollen) vollständig beschrieben und testbar gemacht werden.

Subjektive Bewertung, insbesondere in Demonstrationen.
Live-Demos können stark vom Moderationsstil und von situativen Faktoren abhängen. Ohne klare Bewertungsanker drohen uneinheitliche Bewertungen. Zudem besteht das Risiko, dass „Showcases“ gut wirken, aber die reale Umsetzbarkeit nicht belegen.

Ein standardisiertes Demo-Skript, feste Zeitfenster, definierte Unterkriterien und unabhängige Scoring Sheets pro Juror sind erforderlich. Eine Kalibrierungssitzung des Panels vor der ersten Demo und eine Moderationsregel (z. B. Fragenblock vs. Unterbrechungen) reduzieren Streuungen. Es sollte dokumentiert werden, welche Funktion tatsächlich gezeigt wurde und welche Aussage auf schriftlichen Nachweisen basiert.

Inkonsistente Panel-Bewertung / Bias.
Unterschiedliche Interpretationen von Kriterien oder unbewusste Präferenzen können zu Bewertungsabweichungen führen. Das gefährdet die Transparenz und kann rechtlich angreifbar werden.

Ein Bewertungsleitfaden mit Beispielen je Punktestufe, verpflichtende Begründungstexte je Score, sowie Moderation und Plausibilitätschecks der Ergebnisse sind vorzusehen. Wo möglich, sollten Sensitivitätsanalysen (z. B. Einfluss einzelner Kriterien auf das Ergebnis) intern geprüft werden, bevor Entscheidungen finalisiert werden.

Preis-Qualitäts-Schieflage (Gewichtungen passen nicht zum Risiko).
Wenn Preis zu stark gewichtet wird, kann ein riskanter Anbieter gewinnen, der später über Change Requests kompensiert. Wenn Qualität zu stark gewichtet wird, droht überteuerte Beschaffung und geringere Budgetakzeptanz.

Gewichtungen sind intern gegen die Kritikalität des CAFM-Systems, die Integrationskomplexität und den erwarteten Migrationsaufwand zu validieren. Zusätzlich sollten Mindestqualitätsschwellen und Abklärung ungewöhnlich niedriger Angebote (Plausibilitätsprüfung) eingeplant werden.

Unklare Deliverables und fehlende Abnahmekriterien.
Wenn Leistungsbestandteile nicht eindeutig definiert sind, entstehen Interpretationsspielräume, die zu Konflikten, Nachträgen und Zeitverlust führen. Besonders kritisch sind unklare Abnahmekriterien für Migration, Schnittstellen, Performance, Rollenmodelle sowie Hypercare-Übergang in den Betrieb.

Ein detailliertes Statement of Work mit klaren Outputs, Verantwortlichkeiten, Annahmen und Abhängigkeiten ist zwingend. Zusätzlich ist ein Acceptance Test Framework zu definieren, das Testarten, Prüfumfang, Datenmengen, Erfolgskriterien, Defect-Klassen und Abnahmeprozesse verbindlich festlegt. Change-Control-Regeln müssen eindeutig sein, insbesondere welche Änderungen als im Scope gelten und welche kostenpflichtig sind.

Unzureichende Haftungs- und Leistungszusagen.
Zu niedrige Haftungscaps oder fehlende Leistungszusagen (z. B. Verfügbarkeit, Reaktionszeiten, Migrationserfolg) können dazu führen, dass der Auftraggeber bei schwerwiegenden Problemen keine wirksame Kompensation erhält.

Haftungslogik, Garantien, Service Credits und gegebenenfalls Bonus/Malus-Mechanismen sind so zu gestalten, dass sie wirksam steuern und nicht nur symbolisch sind. Gleichzeitig müssen die Regelungen marktüblich und durchsetzbar bleiben. Preisstrukturen sind transparent zu halten, um versteckte Kostentreiber (z. B. teure Zusatzlizenzen, Schnittstellenwartung) zu vermeiden.

Schlechte Datenqualität im Altsystem.
Unvollständige Asset-Register, inkonsistente Standortstrukturen, fehlende Pflichtattribute oder historisch gewachsene Dubletten führen dazu, dass Migration länger dauert und die neue Lösung mit fehlerhaften Daten startet. Dadurch entstehen betriebliche Risiken und Akzeptanzprobleme.

Eine eigenständige Data-Cleansing-Phase mit klaren Data-Owner-Rollen ist vorzusehen. Migration ist iterativ zu planen (mehrere Testzyklen), inklusive Reconciliation, Stichprobenprüfungen und Freigaben. Vor Go-Live muss ein Parallelabgleich für kritische Datenobjekte erfolgen, wobei Umfang und Prüfmethode festgelegt werden als: [________].

Instabile Schnittstellen zu ERP/BMS/HR/IoT.
Wenn Quell- oder Zielsysteme nicht stabil sind oder APIs Einschränkungen haben, drohen Prozessabbrüche (z. B. Workorder ohne Kostenstelle, fehlende Standortzuordnung, verzögerte Statusrückmeldungen). Dieses Risiko steigt, wenn Verantwortlichkeiten zwischen Systemen unklar sind oder wenn der Anbieter Schnittstellenwartung nur eingeschränkt übernimmt.

Eine Interface-Testphase mit klaren Testfällen, Fehlerbildern und Monitoring muss vertraglich abgesichert sein. Die Verantwortungszuordnung (RACI) für Schnittstellenbetrieb, Monitoring, Fehlerbehebung und Change Management ist verbindlich zu definieren. Open-API-Standards, Dokumentationspflichten und eine nachweisliche Betriebsfähigkeit (Monitoring/Error Handling) sind bereits in der Vergabe zu prüfen.

Unterschätzter Implementierungsaufwand und Engpässe.
CAFM-Projekte scheitern häufig an zu optimistischen Zeitplänen, fehlenden Schlüsselressourcen oder verzögerten internen Entscheidungen. Besonders kritisch sind Abhängigkeiten wie Datenbereitstellung, Schnittstellenfreigaben, Security Reviews und Abnahmefenster.

Ein realistischer Meilensteinplan mit Quality Gates und klaren Entscheidungspunkten ist zu etablieren. Intern müssen Projektgovernance, Steering Committee und Ressourcenverfügbarkeit gesichert werden. Der Anbieter muss belastbare Ressourcenpläne und Eskalationsmechanismen liefern, inklusive Regeln für Ersatz von Schlüsselpersonal und Mindestverfügbarkeit: [________].

Downtime beeinträchtigt FM-Betrieb.
Ausfälle oder Performanceprobleme können die Störungsbearbeitung, Wartungsdurchführung und Reportingfähigkeit unmittelbar beeinträchtigen. In SaaS-/Cloud-Modellen kommen Provider-Abhängigkeiten hinzu.

Uptime-SLAs, RTO/RPO-Ziele, DR-Tests und transparente Incident-/Problem-Management-Prozesse sind verbindlich. Zusätzlich sollte ein stabiler Hypercare-Ansatz vereinbart werden. Intern ist zu klären, welche Prozesse während Ausfällen minimal weiterlaufen müssen und welche Workarounds verfügbar sind: [________].

Widerstand bei Technikern und operativen Teams.
Wenn mobile Prozesse unpraktisch sind, Schulung unzureichend ist oder Rollen/Prozesse nicht zur Realität passen, werden Umgehungsprozesse etabliert und Datenqualität leidet.

Ein Training- und Kommunikationsplan, ein Super-User-Konzept, Pilotierung sowie die Einbindung der operativen Teams in Prozessdesign und Test sind erforderlich. Erfolgskennzahlen für Adoption (z. B. Nutzungsquote, Ticketqualität) sollten festgelegt werden als: [________].

Hohe Wechselkosten und geringe Datenportabilität.
Proprietäre Datenstrukturen, fehlende Exportmöglichkeiten oder fehlende Dokumentation erhöhen das Risiko, dass der Auftraggeber langfristig gebunden ist.

Exit-Klauseln, Datenportabilität, regelmäßige Exporttests sowie optional Escrow-Regelungen (wo sinnvoll) sollten vertraglich abgesichert werden. Bereits in der Vergabe ist zu prüfen, ob Export und Datenmodell transparent sind und ob die Schnittstellen ohne Sondertools nutzbar sind.

Unbefugter Zugriff / Ransomware / schwache Identitätssteuerung.
CAFM-Systeme enthalten personenbezogene Daten, Standortinformationen und operative Prozesse. Schwache Authentifizierung, unzureichendes Rollenmodell oder fehlende Protokollierung erhöhen das Risiko von Missbrauch und Datenabfluss.

Unbefugter Zugriff / Ransomware / schwache Identitätssteuerung. CAFM-Systeme enthalten personenbezogene Daten, Standortinformationen und operative Prozesse. Schwache Authentifizierung, unzureichendes Rollenmodell oder fehlende Protokollierung erhöhen das Risiko von Missbrauch und Datenabfluss.

Nichtkonformität mit Datenschutzregeln / Subprozessor-Risiko / internationale Transfers.
Bei SaaS- oder globalen Supportmodellen entstehen zusätzliche Risiken durch Subprozessoren und mögliche Drittlandzugriffe. Fehlende Transparenz über Datenflüsse und TOMs kann zu Compliance-Verstößen führen.

Ein DPA (Auftragsverarbeitungsvertrag), TOM-Verifikation, Subprozessor-Genehmigungsmodell und Transfermechanismen (falls relevant) müssen vertraglich verbindlich sein. Datenschutz-Folgenabschätzung (falls erforderlich) ist frühzeitig einzuplanen. Intern ist zu definieren, welche Datenkategorien in CAFM verarbeitet werden und welche Schutzbedarfe gelten: [________]

Unterschätzte Lifecycle-Kosten und Kosteneskalation.
CAFM-Kosten entstehen nicht nur durch Lizenzen, sondern auch durch Implementierung, Schnittstellenbetrieb, Support, Releases, Skalierung und Change Requests. Wenn das Preisschema unvollständig ist oder Wachstumstreiber nicht kontrolliert werden (z. B. Nutzer-/Asset-Wachstum), drohen Budgetüberschreitungen.

Eine TCO-Analyse über [] Jahre, transparente Preisstruktur, klare Volumen- und Preisänderungsmechanismen und Governance für Changes sind erforderlich. Intern ist ein Budgetrahmen inkl. Reserve und Trigger für Budgeteskalationen festzulegen als: []. Zudem sollten Anbieterangebote hinsichtlich „versteckter“ Kostenpositionen (z. B. Zusatzmodule, Schnittstellenwartung, Reporting-Packages) gezielt geprüft werden.

Roadmap-Misalignment und Technologierisiko.
Wenn die Produktentwicklung nicht zu den strategischen Zielen passt (z. B. ESG-Reporting, IoT, Mobile, Analytics), drohen teure Workarounds oder erneute Beschaffung.

Roadmap-Workshops im Rahmen der Verhandlungen, klare Produkt-Lifecycle-Zusagen und modular/offene Architektur reduzieren das Risiko. Zusätzlich ist intern zu definieren, welche zukünftigen Anforderungen als „wahrscheinlich“ gelten und daher in die Bewertung einfließen müssen: [________].

Anbieterinsolvenz oder strategische Neuausrichtung.
Wenn der Anbieter wirtschaftlich instabil ist oder seine Strategie ändert, kann Produktpflege, Support oder Roadmap-Fit leiden.

Finanzielle Due Diligence, Referenzprüfung, Roadmap-Bewertung und vertragliche Absicherungen (z. B. Exit, Datenrückgabe, Übergangssupport) sind vorzusehen. Intern ist festzulegen, welche Nachweise akzeptiert werden und wie Stabilität bewertet wird: [________].

Roadmap-Misalignment und Technologierisiko.
Wenn die Produktentwicklung nicht zu den strategischen Zielen passt (z. B. ESG-Reporting, IoT, Mobile, Analytics), drohen teure Workarounds oder erneute Beschaffung.

Roadmap-Workshops im Rahmen der Verhandlungen, klare Produkt-Lifecycle-Zusagen und modular/offene Architektur reduzieren das Risiko. Zusätzlich ist intern zu definieren, welche zukünftigen Anforderungen als „wahrscheinlich“ gelten und daher in die Bewertung einfließen müssen: [________].

Beschaffung

[__]

[__]

[__]

[________]

[________]

[________]

Implementierung

[__]

[__]

[__]

[________]

[________]

[________]

Betrieb

[__]

[__]

[__]

[________]

[________]

[________]

Security/Datenschutz

[__]

[__]

[__]

[________]

[________]

[________]

Finanzen

[__]

[__]

[__]

[________]

[________]

[________]

Strategie

[__]

[__]

[__]

[________]

[________]

[________]