Präsentations- / Demonstrationsszenarien

Der Bieter benennt vorab die Demonstrationsrollen (z. B. Moderator, Systemoperator, Fachprozess-Experte, technischer Integrations-Experte) und stellt sicher, dass während der Demo Personen anwesend sind, die Fragen zur Funktion, Konfiguration, Implementierung und Betriebskonzept verbindlich beantworten können. Namen werden nicht gefordert; Rollenbezeichnungen genügen: [________]. Der Auftraggeber benennt ein Bewertungsgremium. Fragen des Auftraggebers können während des Szenarios oder in dafür vorgesehenen Q&A-Zeitslots gestellt werden. Die Q&A-Regeln (z. B. Unterbrechungen vs. Block am Ende) werden festgelegt als: [________]. Verbindlich bewertungsrelevant sind ausschließlich die demonstrierte Funktionalität und die in den Angebotsunterlagen enthaltenen Aussagen, nicht spontane Zusatzversprechen außerhalb des Angebots.

Die Demo-Umgebung muss mindestens folgende Voraussetzungen erfüllen: definierte Benutzerkonten je Rolle, vorbereitete Objekt-/Standortstruktur, mindestens ein repräsentatives Set an Assets, Wartungsplänen, Workflows, Ersatzteilen und Reporting-Daten sowie ein aktiviertes Protokoll-/Audit-Logging für relevante Aktionen. Die genauen Mindestdatenmengen (z. B. Anzahl Gebäude/Assets/Tickets) werden festgelegt als: [________]. Für virtuelle Demonstrationen muss der Bieter eine stabile Remote-Zugriffsmöglichkeit bereitstellen, die keine Installation unsicherer Software beim Auftraggeber erfordert. Zulässige Konferenz-/Remote-Tools sind: []. Für Vor-Ort-Demos gelten die Zutritts- und Sicherheitsregeln des Standorts: []. Der Bieter ist für seine Endgeräte verantwortlich und muss sicherstellen, dass keine vertraulichen Informationen Dritter angezeigt werden.

Ziel: Darstellung einer logischen Asset-Hierarchie und der Daten-Governance für FM-relevante Stammdaten.

Der Bieter muss live demonstrieren, wie eine Standortstruktur und Asset-Hierarchie aufgebaut und gepflegt wird, einschließlich mindestens einer Kette von Gebäude → Ebene/Stockwerk → Raum → Asset. Dabei ist zu zeigen, wie Assets eindeutig identifiziert werden, wie eine Zuordnung zu Kostenstellen oder organisatorischen Einheiten erfolgt und wie Dokumente wie Handbücher, Verträge oder Garantieunterlagen am Asset verknüpft werden. Zusätzlich ist die Pflege von Attributen zu zeigen, einschließlich frei definierbarer Felder oder konfigurierbarer Merkmalssets, sowie die Nachvollziehbarkeit von Änderungen (z. B. Änderungsverlauf, Pflichtfelder, Validierungsregeln).

Bewertet wird, wie flexibel und konsistent das Datenmodell ist, wie transparent Governance-Mechanismen (Pflichtattribute, Validierungen, Versionierung) umgesetzt sind und wie nutzerfreundlich die Konfiguration und Pflege im Alltag erscheint. Entscheidend ist, ob die Lösung klare Strukturen ermöglicht, ohne unkontrollierte Wildwüchse zu fördern.

Ziel: Validierung der automatisierten Planung und Ausführung vorbeugender Wartungen. Der Bieter muss demonstrieren, wie ein Wartungsplan erstellt wird, entweder zeitbasiert (z. B. alle X Wochen) oder zustands-/ereignisbasiert (wenn im Angebot vorgesehen). Zu zeigen ist die automatische Generierung von Arbeitsaufträgen aus dem Plan, inklusive Terminierung, Priorisierung und Zuweisung an Techniker oder Teams. Der Bieter muss außerdem den mobilen Ablauf der Ausführung demonstrieren, inklusive Checklisten, Dokumentation, Messwerte/Kommentare (falls relevant), und die Abschlusslogik. Abschließend ist zu zeigen, wie das System eine automatische Neuplanung bzw. Rescheduling vornimmt, einschließlich Regeln für Terminverschiebungen und Wiederholung.

Bewertet werden Automatisierungsgrad, Nachvollziehbarkeit (Audit Trail), Praxistauglichkeit der mobilen Nutzung und die Fähigkeit, Standardprozesse ohne hohe manuelle Nacharbeit stabil zu betreiben.

Ziel: Darstellung des vollständigen Lebenszyklus einer reaktiven Störung/Meldung bis zum Abschluss. Der Bieter muss zeigen, wie ein Nutzer über ein Portal oder eine definierte Eingabemaske ein Ticket erfasst, einschließlich Standortbezug, Beschreibung, optionaler Anhänge und Kategorisierung. Im nächsten Schritt ist die Priorisierung/Severity-Logik zu zeigen, einschließlich Regeln und ggf. SLA-relevanter Parameter. Daraus muss ein Arbeitsauftrag entstehen, der geplant und einem Bearbeiter zugeordnet wird. Es ist außerdem zu demonstrieren, wie Ersatzteile oder Material (sofern im System vorgesehen) reserviert werden, wie die Durchführung dokumentiert und wie der Auftrag abgeschlossen und geschlossen wird. Abschließend ist eine Feedback- oder Rückmeldelogik zu zeigen, sofern vorgesehen, einschließlich Kommunikation an den meldenden Nutzer.

Bewertet werden Prozessdurchgängigkeit, Eskalationslogik, Transparenz der Statusführung, sowie die Frage, ob der Prozess in einem realen FM-Umfeld ohne Medienbrüche praktikabel ist.

Ziel: Validierung der mobilen Arbeitsweise im Feld. Der Bieter demonstriert den mobilen Zugriff eines Technikers auf zugewiesene Aufträge, inklusive Zugriff auf Asset-Historie und relevante Dokumente. Wenn Offline-Fähigkeit angeboten wird, ist diese praktisch zu zeigen, einschließlich Offline-Erfassung und späterer Synchronisierung. Der Bieter muss Foto-Upload oder Dokumentation per Medienanhang demonstrieren sowie eine digitale Unterschrift (oder gleichwertige Bestätigung) für Abschluss/Abnahme, sofern vorgesehen. Zudem ist die Echtzeit-Synchronisierung zu demonstrieren, soweit dies im gewählten Szenario realistisch darstellbar ist.

Bewertet werden Feldtauglichkeit, Stabilität, Performance, Datenintegrität und die Frage, ob der Techniker-Workflow einfach genug ist, um breite Akzeptanz zu erreichen.

Ziel: Bewertung der analytischen Transparenz und Managementfähigkeit. Der Bieter muss ein Standard-Dashboard mit typischen FM-KPIs demonstrieren (z. B. Ticketvolumen, Reaktionszeiten, Erledigungszeiten, PM-Compliance), ohne dass konkrete KPI-Definitionen vorgegeben sind, sofern diese nicht durch den Auftraggeber bereitgestellt werden: [________]. Es ist zu zeigen, wie nach Standort/Gebäude gefiltert wird und wie ein benutzerdefinierter Bericht erstellt oder angepasst wird. Schließlich ist ein Export in gängige Formate zu demonstrieren und zu erläutern, wie Berechtigungen für Berichte und Datenzugriffe gesteuert werden.

Bewertet werden Flexibilität der Berichte, Klarheit der Visualisierung, Performance bei datenintensiven Auswertungen und die Fähigkeit, Management-Transparenz ohne hohen manuellen Aufwand herzustellen.

Ziel: Nachweis von Governance- und Zugriffskontrollfähigkeiten. Der Bieter muss zeigen, wie eine neue Rolle erstellt oder angepasst wird und wie Module/Funktionen für diese Rolle restriktiv freigeschaltet werden. Dabei ist eine Multi-Site-Struktur abzubilden, in der Benutzer nur bestimmte Standorte oder Objektbereiche sehen dürfen. Abschließend ist ein Audit-Log zu zeigen, das administrative Änderungen nachvollziehbar macht (z. B. Rollenänderungen, Berechtigungszuweisungen).

Bewertet werden Einfachheit der Administration, Logik und Konsistenz des Rollenmodells, Transparenz der Kontrollen und Nachvollziehbarkeit für Audits.

Ziel: Validierung der Interoperabilität und technischen Reife.

Der Bieter muss demonstrieren, wie eine Schnittstelle technisch angesprochen wird, beispielsweise durch einen Beispiel-API-Call (z. B. Abfrage eines Assets oder Erzeugung eines Tickets). Weiterhin ist ein Datenimportprozess zu zeigen, einschließlich Mapping, Validierung und Fehlerbehandlung. Der Bieter muss außerdem eine Schnittstellenüberwachung demonstrieren (Monitoring, Status, Fehlermeldungen, Retry-Logik) und erklären, wie Synchronisationslogik, Zeitpläne und Konflikte behandelt werden.

Bewertet werden Offenheit der Architektur, Stabilität der Integrationsmechanismen, Transparenz im Betrieb und technische Reife im Umgang mit Fehlerszenarien.

Ziel: Bewertung der Flexibilität und Low-Code-/Konfigurationsfähigkeit. Der Bieter demonstriert, wie ein Workflow angepasst oder erstellt wird, z. B. ein Genehmigungsprozess oder eine Eskalationskette. Es ist zu zeigen, wie ein neues Feld an einem Asset-Typ ergänzt wird und wie dieses Feld in Formularen, Listen oder Berichten verwendet wird. Darüber hinaus muss eine Änderung in der Genehmigungskette demonstriert werden, einschließlich Rollen und Bedingungen, sowie eine Anpassung von Benachrichtigungsregeln (z. B. E-Mail/Push/Task).

Bewertet werden Konfigurations-Transparenz, Administrations-Unabhängigkeit, Nachvollziehbarkeit von Änderungen und die Fähigkeit, Anpassungen kontrolliert (inkl. Governance) vorzunehmen.

Ziel: Nachweis der Systemreaktionsfähigkeit und Skalierbarkeit. Der Bieter demonstriert die Reaktionszeit bei typischen Vorgängen (z. B. Dashboard laden, Ticket anlegen, Workorder öffnen), idealerweise unter erhöhter paralleler Nutzung. Wenn eine Concurrent-User-Simulation möglich ist, kann diese gezeigt werden; andernfalls soll der Bieter plausibel erläutern, wie Lasttests durchgeführt wurden und welche Messergebnisse vorliegen, sofern zulässig: [________]. Zusätzlich ist die Generierungszeit eines größeren Berichts zu demonstrieren und zu erläutern, welche technischen Mechanismen für Performance und Skalierung eingesetzt werden.

Bewertet werden Stabilität, Response Times, Skalierungspotenzial und die Glaubwürdigkeit der Performance-Aussagen im Verhältnis zur angebotenen Architektur.

Der Auftraggeber kann optionale Szenarien aktivieren, wenn sie für das Projekt relevant sind. Eine Aktivierung und die Bewertungssystematik werden rechtzeitig vorab kommuniziert. Mögliche Advanced-Szenarien umfassen ESG-Datenverfolgung und -Reporting, IoT-basierte Predictive Maintenance, KI-gestützte Analysen, sowie Space-Utilization-Analytik. Welche Advanced-Szenarien gelten, wird festgelegt als: [________].

Die Bewertung erfolgt auf Basis standardisierter Bewertungsbögen je Szenario. Jedes Szenario wird anhand definierter Unterkriterien bewertet, die sich typischerweise auf Prozessabdeckung, Bedienbarkeit, Nachvollziehbarkeit, Stabilität/Performance und Governance-Fähigkeit beziehen. Die Punktevergabe erfolgt durch ein Bewertungsgremium; Einzelbewertungen werden anschließend aggregiert. Falls eine gewichtete Gesamtwertung vorgesehen ist, werden Gewichtung und Punkteskala verbindlich festgelegt als: [________].

Die Demonstration dient der Bewertung von Usability und praktischer Umsetzbarkeit. Sie ersetzt nicht die formale Prüfung der schriftlichen Angebotsunterlagen. Wenn demonstrierte Funktionalität von den schriftlichen Aussagen abweicht, kann dies zu Abwertung führen oder – sofern Mindestanforderungen betroffen sind – zu einem Nichtkonformitätsbefund.

Bieter dürfen während der Demonstration keine Informationen über andere Bieter erfragen oder vergleichen. Alle Demonstrationsinhalte sind vertraulich zu behandeln. Aufzeichnungen (Audio/Video/Screen Recording) sind nur zulässig, wenn der Auftraggeber dies schriftlich freigibt: [zulässig / nicht zulässig – ________]. Der Auftraggeber kann selbst protokollieren und Belege (z. B. Screenshots) für die interne Bewertung erstellen, sofern dies mit den Verfahrensregeln vereinbar ist.