Auszug Beispiellastenheft

HIer sind allgemeine Anforderungen beschrieben, die für das Gesamtsystem gelten und nicht nur einem einzelnen Modul zugeordnet sind. Dies umfasst die technischen und betrieblichen Grundlagen der CAFM-Software, die Qualität der Benutzeroberfläche sowie Integrations- und Sicherheitsaspekte.

• Modularität: Die Software soll modular aufgebaut sein. Nicht benötigte Module können deaktiviert bleiben, während weitere Module bei Bedarf hinzugefügt werden können. Alle Module greifen dabei auf einen gemeinsamen Datenpool zu (Single Source of Truth), was konsistente Datenhaltung gewährleistet und zukünftige Erweiterungen erleichtert.

• Offene Schnittstellen: Es sind Schnittstellen (APIs) bereitzustellen, um Datenaustausch mit anderen Systemen zu ermöglichen. Eine RESTful API oder vergleichbarer Webservice sollte vorhanden sein, um z. B. Personaldaten, Veranstaltungspläne oder Sensorinformationen aus Drittsystemen zu integrieren. Offene Standards wie OpenAPI werden ausdrücklich begrüßt. Für Open Data-Initiativen der Hochschule sollte das System zudem Exportmöglichkeiten in offenen Formaten (z. B. CSV, JSON) bieten, damit ausgewählte Daten (etwa Energiekennzahlen oder Auslastungsstatistiken) bei Bedarf öffentlich oder forschungsintern geteilt werden können.

• Drittsystem-Integration: Typische Anbindungen betreffen:

• ERP-Systeme (z. B. SAP): Austausch von Stammdaten (Kostenstellen, Anlagenstammdaten) oder Buchhaltungsdaten (Kosten, Abschreibungen). Bei Bedarf soll z. B. die Übergabe von Instandhaltungsmeldungen an ein bestehendes SAP PM oder das Übernehmen von Bestellanforderungen möglich sein.

• Identity Management/LDAP: Anbindung an das zentrale Verzeichnis der Hochschule (Active Directory o. ä.) zur Synchronisation von Benutzern und zur Unterstützung von Single Sign-On (SSO).

• Gebäudeleittechnik (BMS): Möglichkeit, relevante Daten aus der Gebäudeautomation (z. B. Zählerstände, Störmeldungen aus der GLT) zu importieren. Standardprotokolle (BACnet, OPC UA etc.) sollten unterstützt oder über Middleware anbindbar sein. Ziel ist ein integriertes Monitoring, z. B. um IoT-Sensordaten (Verbrauch, Klima, Präsenz) direkt im CAFM zu nutzen.

• CAD/BIM-Tools: Direkte Schnittstelle oder Importfunktion für CAD-Zeichnungen (DXF/DWG) und BIM-Modelle (IFC, Revit). Änderungen im Raumzuschnitt sollen entweder per Import aktualisierbar sein oder im System selbst nachgepflegt werden können. Grafische Grundrisse sollen mit Sachdaten verknüpft werden, um z. B. Flächenvisualisierungen aktuell zu halten.

• Mail- und Kalendersysteme: Integration mit dem E-Mail/Kalendersystem der Hochschule (z. B. Exchange/Office 365), um Benachrichtigungen (z. B. Ticketstatus) per E-Mail zu versenden und gebuchte Räume als Termineintrag in Benutzerkalender einzutragen. Auch eine Bereitstellung freigegebener Kalender (iCal/ICS) für Räume ist wünschenswert, damit z. B. Raumbelegungspläne abonniert werden können.

• IoT-Plattform: Falls an der Hochschule bereits eine IoT-Datenplattform im Einsatz ist (z. B. für Smart-Campus-Anwendungen), soll das CAFM darüber Sensordaten beziehen und zurückspielen können (z. B. aktuelle Raumtemperaturen, Belegungsdaten von Schreibtischsensoren, Luftqualitätswerte). Alternativ muss das CAFM eigene Mechanismen bieten, um Sensoren direkt einzubinden. Wichtig ist hierbei eine Echtzeit-Verarbeitung von Sensordaten, um unmittelbar auf Ereignisse reagieren zu können.

• Digitaler Zwilling: Die Architektur soll die Nutzung eines digitalen Zwillings des Campus ermöglichen. Das heißt, dass statische Gebäudedaten (BIM) mit dynamischen Echtzeitdaten (Sensorik) im System verknüpft werden können, um ein aktuelles Abbild des Betriebszustands zu erhalten. Diese Kopplung von BIM und CAFM reduziert Betriebsrisiken und Kosten, indem z. B. Wartungsarbeiten effizienter geplant werden und stets aktuelle Bestandsdaten für Mieter- und Serviceverträge vorliegen. Durch den digitalen Zwilling kann eine Vielzahl von Daten auf einer Plattform zusammenfließen – vom Energie- und Wasserverbrauch über Belegungs- und Luftqualitätswerte bis hin zu Verkehrsströmen – was eine holistische Analyse ermöglicht. Perspektivisch können solche Plattformen in Verbindung mit KI zu „kognitiven Zwillingen“ werden, die Anomalien erkennen, Prognosen treffen und teilweise autonom optimieren.

• Smart-Campus-Konnektivität: Über die reinen FM-Funktionen hinaus soll das System anschlussfähig für Smart Campus Konzepte sein. Das bedeutet, dass es sich in eine übergeordnete Campus-Digitalplattform integrieren lässt. Beispielsweise könnte das CAFM ausgewählte Betriebsdaten an ein zentrales Campus-Dashboard liefern oder Daten aus studentischen Anwendungen (z. B. Belegungsdaten aus Lernraummanagement) übernehmen. Offene APIs und standardisierte Datenformate sind hierfür Voraussetzung. Diese Konnektivität stellt sicher, dass FM-Daten im Kontext des gesamten Campus nutzbar sind – sei es für universitätsweite Echtzeit-Dashboards oder für die Beteiligung an Smart-City-Initiativen der Stadt.

• Skalierbarkeit: Das System muss mit den Anforderungen mitwachsen können. Insbesondere sollte es in der Lage sein, Daten für viele Gebäude und Benutzer performant zu verarbeiten. Angenommen wird der Einsatz für ca. 3–5 Standort-Liegenschaften (Campusareale) mit insgesamt z. B. 10–20 Gebäuden, >50.000 m² Fläche und mehreren tausend Räumen. Das System soll perspektivisch auch erweiterten Umfang (z. B. zusätzliche Liegenschaften oder Nutzergruppen) ohne Performanceverlust abdecken.

• Betriebsmodell: Die Software kann entweder in der Cloud (Software as a Service in einem europäischen Rechenzentrum) oder On-Premises im Rechenzentrum der Hochschule betrieben werden – abhängig von den Angeboten der Bieter. In jedem Fall sind Datensicherheit und -hoheit zu gewährleisten. Bei Cloud-Lösungen sind entsprechende Zertifizierungen (ISO 27001 o. ä.) und vertragliche Garantien vorzulegen (Auftragsdatenverarbeitung, Support bei DSGVO-Anfragen etc.). Ein Wechsel des Betriebsmodells (Cloud <-> On-Prem) sollte konzeptionell möglich sein, um zukünftigen Strategiewechseln gerecht zu werden.

• Benutzerrollen: Das System muss ein rollenbasiertes Berechtigungskonzept unterstützen. Typische Rollen sind z. B. Administrator, FM-Manager, Haustechniker, Reinigungsleiter, Fachbereichskoordinator, externer Dienstleister sowie normale Mitarbeitende/Studierende (für Self-Service-Funktionen wie Raumbuchung oder Störungsmeldung).

• Neue Rollenprofile: Neben den klassischen Rollen sollte das System auch neue Rollen im Kontext moderner FM-Strategien abbilden können. Beispielsweise könnten folgende Rollen relevant werden: ESG-Manager/in (zuständig für Nachhaltigkeitsreporting und -maßnahmen), IoT-Administrator/in (betreut Sensorik und digitale Infrastruktur), Nachhaltigkeitsbeauftragte/r (kümmert sich um die Umsetzung von Nachhaltigkeitsrichtlinien im Gebäudebetrieb). Das System muss erlauben, für solche Rollen maßgeschneiderte Rechteprofile zu definieren – etwa Zugriff auf ESG-Dashboards und Berichte für den ESG-Manager oder administrative Sensorverwaltung für den IoT-Admin. Diese Profile sollen flexibel konfigurierbar sein, um künftige organisatorische Änderungen (neue Aufgabenbereiche) zu berücksichtigen.

• Rechteprofile: Für jede Rolle sollen gezielt Lese-, Schreib-, Änderungs- oder Löschrechte auf Module, Funktionen und Datenobjekte definierbar sein. Z. B. darf ein Fachbereichskoordinator Räume buchen und Störungen melden, aber keine technischen Stammdaten ändern. Ein Haustechniker darf Wartungsaufträge bearbeiten, aber keine Vertragsdaten einsehen usw. Rechte sollten im Idealfall kontextabhängig gestaltet werden können (z. B. räumliche Beschränkung: ein Gebäudemanager sieht nur „sein“ Gebäude).

• Mehrstufige Freigaben: In Verbindung mit Workflows sollen bestimmte Aktionen nur durch berechtigte Personen freigegeben werden können (Vier-Augen-Prinzip). Das System muss sicherstellen, dass solche Genehmigungsschritte von befugten Rollen durchgeführt werden (z. B. Kostenfreigabe einer Reparatur nur durch Budgetverantwortliche). Rollen und Workflows sind zu verzahnen, damit z. B. ein „ESG-Officer“ automatisch in Nachhaltigkeits-bezogene Prozesse (Freigabe von Nachhaltigkeitsbudgets, Prüfung von ESG-Kriterien bei Vergaben) eingebunden wird.

• Verzeichnisdienst-Anbindung: Zur Vereinfachung der Administration soll die Möglichkeit bestehen, Benutzerkonten aus dem zentralen Verzeichnis (Active Directory/LDAP) zu importieren und die Authentifizierung darüber abzuwickeln (Single Sign-On). Alternativ bzw. ergänzend muss ein internes Benutzermanagement mit Passwortverwaltung und Passwort-Richtlinien vorhanden sein.

• Externe Nutzer und Self-Service: Das System muss auch externe Benutzer verwalten können, z. B. Accounts für Dienstleister oder Mieter. Diesen sind stark eingeschränkte Rollen zuzuweisen (etwa nur Zugriff auf bestimmte Auftragsdaten, siehe Dienstleisterportal). Eine sichere Trennung zwischen internen und externen Benutzern (z. B. getrennte Mandanten oder Rollen) ist zu gewährleisten.

• Audit und Protokollierung: Alle sicherheitsrelevanten Aktionen und Änderungen (z. B. Stammdatenänderung, Rechteänderung, Löschung von Datensätzen) sollen protokolliert werden, inklusive Benutzerkennung, Zeitstempel und Art der Änderung. Dies dient der Nachvollziehbarkeit und Unterstützung von Governance-Anforderungen. Die Protokolle müssen einsehbar sein (mindestens für Administratoren) und revisionssicher gespeichert werden. Insbesondere Änderungen an kritischen Einstellungen oder Löschvorgänge sollten mit Begründung dokumentiert werden. Rechtssicherheit: Die Protokollierung soll so erfolgen, dass sie bei internen oder externen Audits als Nachweis akzeptiert wird (z. B. Unveränderbarkeit, digitale Signaturen).

• Web-Oberfläche: Die Anwendung soll über aktuelle Browser (Chrome, Firefox, Edge) nutzbar sein, ohne Plugins oder besondere Add-ons. Es sind gängige Webtechnologien zu verwenden; die Unterstützung aktueller Browserversionen ist Pflicht.

• Mehrsprachigkeit: Die Benutzeroberfläche muss mindestens in deutscher Sprache verfügbar sein. Ideal ist eine zweisprachige Oberfläche (deutsch/englisch), da ggf. externe Dienstleister oder internationale Nutzende eingebunden sind. Umschaltung der Sprache im laufenden Betrieb sollte möglich sein.

• Konsistenz und Ergonomie: Das UI-Design soll konsistent und aufgeräumt sein. Wiederkehrende Strukturen (Masken, Dialoge, Navigationsschemata) erleichtern die Orientierung. Eingaben sollten wo möglich durch steuerelemente wie Auswahllisten, Kalender-Picker etc. unterstützt werden, um Fehler zu vermeiden. Barrierefreiheit ist mit zu berücksichtigen: Die Software sollte möglichst barrierearm sein (entsprechend BITV/WCAG-Standards), sodass auch Mitarbeitende mit Beeinträchtigungen sie benutzen können (skalierbare Schrift, Kontraste, Tastaturbedienbarkeit).

• Dashboard-Startseite: Nach dem Login sollte der Nutzer eine anpassbare Übersichtsseite (Dashboard) sehen, die für seine Rolle relevante Kennzahlen, Aufgaben und Meldungen anzeigt. Z. B. offene Tickets, anstehende Termine, Flächen- oder Energieverbrauchskennzahlen und personalisierte Nachrichten. Das Dashboard soll vom Nutzer oder Admin konfigurierbar sein (Widgets ein-/ausblenden, Reihenfolge ändern), damit jeder die für ihn wichtigsten Informationen auf einen Blick erhält.

• Grafische Visualisierung: Wichtig ist die grafische Unterstützung in bestimmten Modulen, insbesondere ein CAD- bzw. grafischer Plan-Viewer für Gebäudepläne. Räume sollen in digitalen Grundrissen visuell dargestellt werden können, inkl. Zoom-/Pan-Funktionen. Eine farbliche Kennzeichnung von Flächen nach Kriterien muss möglich sein (Belegung, Nutzung, Zustand, Kostenstelle etc.). Beispielsweise können freie Räume grün und belegte rot markiert werden, oder Flächen nach Fachbereich farblich unterschieden werden. Die grafische Darstellung soll mit Sachdaten verknüpft sein (Klick auf einen Raum im Plan zeigt dessen Stammdaten oder Belegungsstatus). Optional wäre auch eine einfache 3D-Visualisierung, falls BIM-Daten vorliegen, um z. B. technische Anlagen im Gebäudemodell zu verorten – mindestens jedoch eine 2D-Grundrissanzeige.

• Indoor-Navigation: Für große oder komplexe Gebäude wäre es von Vorteil, wenn das System oder eine integrierte App eine Indoor-Navigationsfunktion bieten könnte. D. h. Nutzer (Studierende, Besucher, Techniker) könnten auf einer digitalen Karte den Weg zu einem bestimmten Raum oder Asset finden. Dies könnte z. B. durch Einbindung eines Drittanbieters für Indoor-Mapping erfolgen. Ein Anwendungsfall: Eine neuer Mitarbeiter*in nutzt die App, um den reservierten Arbeitsplatz oder die nächstgelegene Ausstattung (z. B. Drucker, Erste-Hilfe-Kasten) schnell zu lokalisieren.

• Konfigurierbarkeit: Power-User (z. B. CAFM-Administratoren) sollten die Möglichkeit haben, Ansichten und Formulare ohne Programmierung anzupassen. Beispielsweise Spalten in Tabellen ein-/ausblenden, zusätzliche Attributfelder definieren, eigene Filter speichern oder Regeln für die farbliche Hervorhebung von Werten konfigurieren.

• Favoriten & Navigation: Eine effiziente Navigation ist bereitzustellen, z. B. eine Baumstruktur der Liegenschaften/Gebäude/Räume zur schnellen kontextuellen Auswahl sowie eine durchgängige Suchfunktion (Live-Suche) für Objekte aller Art. Eine Favoritenfunktion (Speichern häufig benötigter Objekte, Ansichten oder Berichte) ist wünschenswert, um wiederkehrende Zugriffe zu beschleunigen.

• User Feedback und Hilfe: In die UI sollten auch Möglichkeiten zur Rückmeldung und Unterstützung integriert sein. Beispielsweise könnten Nutzer nach Erledigung eines Tickets oder einer Buchung eine kurze Zufriedenheitsbewertung abgeben (Sterne oder „Daumen hoch/runter“). Diese Feedback-Daten werden gesammelt, um die Servicequalität zu überwachen. Zudem sollte ein kontextsensitives Hilfesystem vorhanden sein (z. B. Tooltips, Online-Hilfe oder Chatbot für häufige Fragen). Moderne Lösungen setzen hier auch auf Chatbots, die Anwendenden Hilfestellung geben oder Routineanfragen entgegennehmen – perspektivisch könnte eine KI-basierte Assistenz bei typischen Nutzerfragen unterstützen (z. B. „Wie buche ich einen Raum?“).

• Benutzerzufriedenheit messen: Das System sollte ermöglichen, die Nutzungserfahrung zu evaluieren. Beispielsweise kann über integrierte Umfragen die Zufriedenheit der Nutzenden periodisch erfragt werden (z. B. „Wie zufrieden sind Sie mit dem Raumbuchungsprozess?“). Auch Kennzahlen wie die User Adoption (aktive Nutzeranzahl, häufig genutzte Funktionen) sollen erfasst werden, um Schulungsbedarf oder Optimierungspotenziale zu erkennen.

• Mobile App für Techniker/Servicekräfte: Es sollte eine native mobile Anwendung (Smartphone/Tablet, Android und iOS) verfügbar sein, mit der technische Mitarbeiter ihre Aufträge abrufen, Rückmeldungen erfassen und Störungen direkt vor Ort dokumentieren können. Wichtige Funktionen: Einsicht in Auftragsdetails inkl. Priorität und Frist, Abarbeiten von Checklisten, Erfassen von Verbrauchsmaterial, Anhängen von Fotos (Schadensdokumentation), Barcode-/QR-Code-Scan von Anlagen zur schnellen Identifikation. Die App muss offlinefähig sein (Daten zwischenspeichern bei Funklöchern und automatische Synchronisation bei Verbindungswiederkehr).

• Mobile Self-Service App: Auch für normale Nutzer (Mitarbeitende, ggf. Studierende) ist eine mobile Lösung wünschenswert, um FM-Services abzurufen. Über eine solche Workplace-App sollen z. B. Raumbuchungen vorgenommen, spontane Anforderungen (Reinigung, Catering) gemeldet oder Störungen gemeldet werden können. Dies erhöht die Erreichbarkeit und Nutzung der Plattform. Eine intuitiv bedienbare App mit Single Sign-On zur Hochschulkennung senkt die Hürden für die Teilnahme am digitalen Facility Management.

• Responsive Design: Alternativ oder ergänzend zur nativen App muss die Web-Oberfläche mobiloptimiert sein. Kernfunktionen (Meldung erfassen, Räume buchen, Aufgabenlisten einsehen, etc.) sollen auch auf Smartphone/Tablet-Bildschirmen benutzbar sein, mit Touch-Bedienung und angepasster Darstellung. So wird sichergestellt, dass auch ohne App-Installation alle Features mobil verfügbar sind.

• Push-Benachrichtigungen: Mobile Nutzer (App-Benutzer) sollten optional Push Notifications erhalten, z. B. wenn ein zugewiesener Auftrag aktualisiert wurde, eine genehmigungspflichtige Anfrage freigegeben werden muss oder eine bevorstehende Raumbuchung ansteht. Techniker können so unmittelbar informiert werden (statt E-Mails abrufen zu müssen), und Nutzer werden an ihre bevorstehenden Reservierungen oder an fälliges Feedback erinnert.

• Geräteintegration: Die App sollte Gerätemerkmale des Smartphones/Tablet nutzen können, z.B. die Kamera (für Fotos oder zum QR-Code/Barcode-Scan), das GPS-Modul (um Vorfälle im Außengelände zu lokalisieren oder dem Benutzer standortbezogene Informationen zu geben) und ggf. Bluetooth/NFC für zukünftige Zwecke (z. B. Check-In via NFC-Batch oder Sensoranbindung).

• Indoor-Navigation und Wegfindung: Wie angedeutet, wäre es ein Plus, wenn die mobile App die Nutzer innerhalb von Gebäuden navigieren kann. Zum Beispiel könnte eine Studierender über die App den gebuchten Raum finden mit einem „Turn-by-Turn“-Weg bis vor die Tür. Dies setzt ein Indoor-Mapping voraus und ist optional, könnte aber im Rahmen eines Smart Campus-Konzepts integriert werden.

• Sicherheit und Zugriff: Die mobilen Lösungen müssen denselben Sicherheitsstandards genügen wie die Hauptanwendung (verschlüsselte Verbindungen, Zugriffskontrollen gemäß Rolle). Im Falle von Geräteverlust sollte z. B. eine Remote-Sperrung des Zugangs möglich sein (ggf. über MDM der Hochschule). Zudem ist darauf zu achten, dass keine sensiblen Daten unverschlüsselt auf dem Gerät verbleiben.

• Zentrale Datenhaltung: Alle Stamm- und Bewegungsdaten (Flächen, Räume, Anlagen, Verträge, Buchungen, Tickets, Verbrauchswerte etc.) werden im CAFM zentral gespeichert. Das Datenmodell soll Beziehungen zwischen den Entitäten abbilden (z. B. welches Asset steht in welchem Raum, welcher Vertrag gehört zu welcher Anlage, welcher Lieferant erbringt welche Leistungen). Redundante Datenspeicherung ist zu vermeiden; stattdessen sollen relevante Informationen verknüpft und aus einer Quelle gepflegt werden.

• Datenimport initial: Für die Einführung müssen bestehende Datenbestände importiert werden können. Das System soll gängige Formate (Excel/CSV, XML) für den Import bereitstellen oder Migrationsskripte unterstützen. Insbesondere Raumlisten, Anlagenlisten und ggf. Personal- bzw. Kostenstellenstammdaten sollen übernommen werden. Es ist darzustellen, welche Tools oder Mappings der Anbieter für die Migration bereitstellen kann.

• Laufender Import/Export: Neben der initialen Migration ist auch regelmäßiger Datenaustausch gefragt. Beispielsweise monatlicher Import von Energieverbrauchsdaten aus einem externen Energiemanagementsystem oder Export von FM-Kosten ans Rechnungswesen. Hierfür sollen flexible Import-/Export-Schnittstellen oder -Werkzeuge vorhanden sein. Ideal ist, wenn der Endanwender definieren kann, welche Felder in welchen Formaten exportiert/importiert werden (z. B. via Konfigurationsassistent oder ETL-Tool).

• Echtzeit-Integration: Wo möglich, sollen Datenschnittstellen in Echtzeit oder near-real-time arbeiten, um z. B. Sensorwerte, Buchungsänderungen oder Störungsmeldungen ohne Zeitverzug im System verfügbar zu machen. Bei zeitkritischen Daten (z. B. Live-Belegungszahlen, aktuelle Zählerstände) ist auf ein entsprechendes Protokoll (Event-getrieben, MQTT o. Ä.) zu achten.

• Dokumentenmanagement: Viele Daten sind durch Dokumente ergänzt (Pläne, Verträge, Fotos, Protokolle). Die Software soll ein integriertes Dokumentenmanagement bieten oder zumindest eine Anbindung an ein bestehendes DMS erlauben. Mindestanforderung: Dateien können bei den jeweiligen Objekten hochgeladen und versioniert gespeichert werden (z. B. Wartungsprotokoll als PDF am Wartungsauftrag, Grundrissdatei am Raumobjekt). Eine strukturierte Ablage (Ordnerstruktur oder Verschlagwortung) und Volltextsuche über Dokumente sind wünschenswert. Wichtig ist die Möglichkeit, Dokumente als verbindliche Nachweise zu markieren – z. B. ein Wartungsprotokoll, das final unterschrieben wurde, sollte unveränderbar archiviert werden können (Schreibschutz oder Version Freeze), um die Rechtsgültigkeit zu bewahren.

• Datenqualität: Hilfen zur Sicherstellung der Datenqualität sollen vorhanden sein, z. B. Pflichtfelder, Wertelisten (Kataloge) für bestimmte Attribute, Plausibilitätsprüfungen (z. B. Enddatum nicht vor Startdatum). Administratoren sollen Stammdatenkataloge (wie Raumnutzungsarten, Anlagenarten, Störungskategorien) selbst anlegen und pflegen können. Idealerweise unterstützt das System auch Datenvalidierungen beim Import (z. B. Warnung, wenn Fläche nicht summiert passt, oder Dublettenprüfung bei Personaldaten).

• Historisierung: Änderungen an Stammdaten sollten historisch nachvollziehbar sein. D. h. wenn z. B. ein Raum umbenannt oder einer anderen Abteilung zugeordnet wird, soll das alte Attribut erhalten bleiben (mit Gültigkeitsdatum) oder zumindest ein Änderungsprotokoll existieren. So kann z. B. nachvollzogen werden, welche Raumbezeichnung vor einem Umbau galt oder welche Fläche ein Fachbereich früher hatte. Gerade für Flächen- und Personaldaten ist Historisierung wichtig (z. B. um rückwirkend Flächennutzungsgrade zu analysieren).

• Offene Datenformate: Für den Datenaustausch und die Datenweitergabe muss das System offene, gängige Formate unterstützen. Neben den genannten IFC (für Gebäudemodelle) und CSV/XML (für Listen) sind z. B. PDF/A für Dokumente, JPEG/PNG für Bilder und ggf. spezialisierte Standards wie gbXML oder CityGML (für Gebäudedaten im Smart City Kontext) zu nennen. Open Data Prinzipien sollten berücksichtigt werden, damit die Hochschule z. B. im Rahmen von Forschungskooperationen problemlos Daten aus dem CAFM bereitstellen kann, ohne erst aufwändige Konvertierungen vornehmen zu müssen.

• Integration externer Datenquellen: Das System sollte in der Lage sein, externe Datenquellen einzubinden oder zu referenzieren. Beispielsweise könnten öffentliche Open-Data-Dienste (Wetterdaten für Energy Analytics, ÖPNV-Daten für Mobilitätsservices) oder interne Datenbanken (z. B. die Studentenverwaltung für aktuelle Belegungszahlen von Lehrveranstaltungen) sinnvoll sein. Derartige externe Daten könnten per API-Abfrage oder Datenimport integriert werden, um erweiterte Funktionen zu ermöglichen (z. B. wetterbereinigte Verbrauchsanalysen).

• Standardberichte: Eine Reihe vordefinierter Standardberichte wird erwartet, z. B. Flächenkennzahlen (pro Gebäude, pro Organisationseinheit), Instandhaltungsübersichten (fällige und erledigte Wartungen, Kostenübersicht), Störungsstatistik (Anzahl Tickets nach Kategorie/Priorität, durchschnittliche Lösungszeit), Reinigungsleistung (gereinigte Fläche pro Woche, Qualitätskontrolle Ergebnisse), Energierberichte (Verbrauch nach Monat/Gebäude) usw. Diese Berichte sollten vom Nutzer ohne großen Aufwand generierbar sein (Parameter wählbar, z. B. Zeitraum, Gebäude, Kostenstelle).

• Ad-hoc-Analysen: Über die Standardreports hinaus soll der Anwender Ad-hoc-Auswertungen durchführen können. Das System sollte eine Abfrage- und Auswertungsfunktion bieten, mit der man z. B. alle Räume filtern kann, die länger als X Tage ungenutzt waren, oder eine Liste aller Verträge mit Ablauf im nächsten Jahr erzeugen kann. Optimal wäre ein integriertes Reporting-Tool oder BI-Frontend, das auch Diagramme (Balken, Tortengrafiken, Zeitreihen) erstellen kann.

• Dashboarding: Unterschiedliche Stakeholder (Techniker, FM-Leiter, Kanzleramt, Nachhaltigkeitsbeauftragte etc.) sollen auf ihren Dashboards Kennzahlen in Echtzeit sehen können. Das System sollte daher Widgets für KPIs liefern, z. B. „aktuell offene Tickets“, „Flächenauslastung heute“, „Energieverbrauch diese Woche vs. letzte Woche“. Diese Dashboards sollen interaktiv sein (Drill-Down bei Klick).

• Kennzahlensystem: Das System soll die Berechnung gängiger FM-Kennzahlen unterstützen, z. B. m² pro Mitarbeiter, Reinigungskosten pro m², Wartungskostenquote, CO₂-Emission pro Kopf, Anteil nachhaltiger Lieferanten etc. Zudem sollte ein Vergleich zwischen Objekten möglich sein (Benchmarking). Z. B. können Gebäude untereinander hinsichtlich Energieintensität verglichen werden, um Ineffizienzen zu identifizieren.

• ESG-Reporting: Im Rahmen von Nachhaltigkeitsberichten sollen spezifische Reports erzeugt werden können, z. B. Energieverbräuche und CO₂-Emissionen pro Jahr, Wasserverbrauch, Abfallmengen, Anzahl HSE-Vorfälle. Die Software soll idealerweise vorgefertigte Berichtsvorlagen für gängige Nachhaltigkeitsframeworks (GRI, CSRD) liefern oder zumindest die Datengrundlage dafür bereitstellen. Die Scope 1-3 Emissionen der Hochschule sollten aus den erfassten Daten möglichst automatisch berechnet und dargestellt werden können. So kann die Erstellung z. B. eines jährlichen Nachhaltigkeitsberichts erheblich vereinfacht werden.

• Live-Analytics & Sensor-Daten: Falls Sensoren angebunden sind (IoT-Integration), sollen deren Daten auch analytisch genutzt werden. Beispiele: Live-Auslastungs-Dashboard (wie viele Arbeitsplätze sind gerade belegt, aktuelle Raumluftqualitätswerte pro Raum), oder Echtzeit-Energieverbrauchsanzeige. Das System sollte in der Lage sein, Live-Daten mit historischen Daten zu kombinieren, um Trends frühzeitig zu erkennen (Predictive Analytics). So könnten Anomalien identifiziert werden, z. B. ein plötzlicher Mehrverbrauch an Wasser als Indikator für ein Leck (woraufhin automatisch ein Alarm ausgelöst wird).

• KI-gestützte Analysen: Zukünftig sollte das Berichtssystem KI/ML-Technologien nutzen können, um Muster und Prognosen zu liefern. Beispielsweise könnte ein ML-Algorithmus Prognosen über die Raumauslastung für die nächsten Wochen liefern (unter Berücksichtigung von Semesterzeiten, Wetter etc.), oder eine KI analysiert die freien Räume und schlägt Optimierungen vor (Raumzusammenlegungen, Energiesparpotenziale). Auch im Störungsmanagement könnten Text-Mining-Verfahren eingesetzt werden, um häufige Problemursachen zu erkennen. Solche KI-Funktionen sind kein Muss zum Start, aber das System sollte technisch offen dafür sein und idealerweise bereits erste KI-Features bieten (viele Hersteller entwickeln solche Funktionen aktuell). Beispiel: KI-gestützte Analyse der Sensordaten könnte automatisch empfehlen, bestimmte Wartungsintervalle zu verlängern oder zu verkürzen, basierend auf realer Nutzung und Verschleiß.

• Export und Weiterverarbeitung: Alle Berichte und Analysen sollten in gängigen Formaten exportierbar sein (PDF, Excel, CSV). Zudem ist eine API-Schnittstelle für Berichtsabfragen wünschenswert, damit z. B. ein Management-Dashboard außerhalb des CAFM (etwa im Intranet der Hochschule) mit aktuellen Kennzahlen aus dem CAFM gespeist werden kann.

• Campus-Dashboard und Nutzerkommunikation: Die Lösung soll die Möglichkeit bieten, ausgewählte Kennzahlen öffentlich oder für alle Hochschulangehörigen sichtbar zu machen, um Transparenz zu fördern. Beispielsweise könnte ein Campus-Nachhaltigkeitsdashboard im Intranet anzeigen: „Heutiger Stromverbrauch vs. Durchschnitt“ oder „Aktuelle CO₂-Einsparung dank Solaranlage“. Das CAFM muss die Daten für solche Zwecke bereitstellen (über Widget oder Datendienst). Ebenso könnten Feedback-Ergebnisse aggregiert kommuniziert werden („93% der Nutzer waren diesen Monat zufrieden mit dem Helpdesk-Service“), um eine Rückkopplung an die Community zu geben. Solche digitalen Kommunikationsstrategien fördern das Bewusstsein und binden die Nutzer aktiv ein.

• Zugriffssicherheit: Alle Verbindungen zum System (insbesondere bei Web- oder Cloudbetrieb) müssen nach aktuellem Stand der Technik verschlüsselt sein (TLS 1.2/1.3). Zugriffe von außen sind nur über gesicherte Kanäle zulässig (VPN, HTTPS). Bei Cloud-Lösungen ist sicherzustellen, dass nur berechtigte Personen Zugang zu Administrationsoberflächen haben (z. B. IP-Restriktionen für Admin-Logins).

• Authentifizierung: Das System muss robuste Authentifizierungsmechanismen bieten. Neben Benutzername/Passwort sollte Multi-Faktor-Authentifizierung (MFA) unterstützt werden, zumindest optional für privilegierte Nutzeraccounts (Admins) und externe Zugriffe. MFA erhöht die Sicherheit signifikant, da zusätzlich zum Passwort ein zweiter Faktor (z. B. Einmalcode, Hardware-Token oder biometrisches Merkmal) erforderlich ist. Idealerweise lässt sich MFA über die angebundene SSO-Infrastruktur realisieren oder in der Anwendung direkt aktivieren.

• Rechtesystem: Das Berechtigungskonzept stellt sicher, dass Benutzer nur die Daten sehen, die für ihre Aufgabenerfüllung notwendig sind (Least Privilege Principle). Dieses Prinzip ist strikt umzusetzen. Rollen und Berechtigungen sollten regelmäßig überprüft werden (Rezertifizierung), um „Rechteschlupf“ zu vermeiden.

• Datenschutz (DSGVO): Personenbezogene Daten (z. B. Mitarbeitende als Raumverantwortliche, Ticket-Meldende, Besucherlisten) werden im System verarbeitet. Die Software muss Funktionen bieten, um DSGVO-Vorgaben einzuhalten, z. B.:

• Protokollierung von Zugriffen auf personenbezogene Daten (wer hat wann welche Personendaten angesehen/verändert).

• Löschkonzepte: Möglichkeit, personenbezogene Daten nach Ablauf von Aufbewahrungsfristen zu anonymisieren oder zu löschen (z. B. Historie von Ticketmeldern nach X Jahren).

• Datenexport: Erfüllung von Betroffenenrechten durch Export aller über eine Person gespeicherten Daten auf Anfrage.

• Einwilligungsmanagement: Falls z. B. Fotos von Personen (Mitarbeiterausweise o. Ä.) hinterlegt werden, muss die Einwilligung dokumentiert werden können.

• Hosting und Datenspeicherung: Bei Cloud-Lösungen ist zwingend vorgeschrieben, dass die Daten innerhalb der EU (vorzugsweise Deutschland) gespeichert werden. Ein Nachweis über Auftragsdatenverarbeitung (ADV) muss erbracht werden. Bei On-Premises-Betrieb sind angemessene physische Sicherheitsmaßnahmen im Rechenzentrum zu erfüllen (Zutrittskontrolle, USV, Feuerlöscheinrichtungen etc.).

• Schwachstellenmanagement: Der Anbieter soll regelmäßige Sicherheitstests (Penetrationstests) durchführen oder unterstützen. Sicherheitszertifizierungen wie ISO 27001 oder BSI-Grundschutz sind von Vorteil und sollen, falls vorhanden, vorgelegt werden. Zudem muss das System regelmäßige Updates/Patches erhalten, um neu bekannt gewordene Schwachstellen zu schließen. Ein Security Patch Process (z. B. monatliche Updates, Notfall-Patches binnen 48h bei kritischen Lücken) sollte vertraglich vereinbart werden.

• Protokollierung und Monitoring: Neben der genannten Benutzeraktions-Protokollierung soll das System sicherheitsrelevante Ereignisse loggen, z. B. fehlgeschlagene Login-Versuche, versuchte unautorisierte Zugriffe, Integritätsverletzungen. Diese Logs sollen vom Administrator einsehbar und in externe Security-Information-und-Event-Management (SIEM) Systeme integrierbar sein. Echtzeit-Warnungen (E-Mail/SMS) bei sicherheitskritischen Events (z. B. Brute-Force-Angriff erkannt) sind wünschenswert.

• Notfallkonzept: Für den Fall von Systemausfällen oder -datenverlusten muss eine Backup-/Restore-Lösung existieren. Es soll geklärt sein, in welchem Rhythmus Backups erstellt werden (mind. täglich inkrementell, wöchentlich voll) und wie schnell im Ernstfall eine Wiederherstellung möglich ist. Ebenso sollte ein Notfallplan existieren, damit kritische Prozesse notfalls auch bei Systemausfall überbrückt werden können (z. B. manuelle Störungsannahme auf Papier, die später nacherfasst wird).

• Test-/Schulungssystem: Zur Gewährleistung der Datensicherheit im laufenden Betrieb ist es sinnvoll, ein getrenntes Test- bzw. Schulungssystem zu haben, auf dem Updates und Änderungen vorab geprüft werden. Dieses sollte möglichst anonymisierte Echtdaten enthalten, um realistische Tests zu ermöglichen, ohne den Datenschutz zu verletzen.

• Verschlüsselung und Integrität: Sensible Daten in der Datenbank (wie Passwörter, API-Schlüssel, ggf. personenbezogene Notizen) sollen verschlüsselt gespeichert werden. Bei Dateianhängen ist zu klären, ob eine Verschlüsselung oder Signatur der Dokumente erforderlich ist (ggf. bei besonders sensiblen Dokumenten wie Bauplänen, Zugangscodes etc.). Integritätsmechanismen (Checksums, Hashes) für Dokumente wären ein Plus, um Veränderungen erkennen zu können.

• Sicherheitskonzept für mobile Nutzung: Da mobile Endgeräte eingesetzt werden, muss ein Konzept gegen Geräteverlust und unbefugte Nutzung vorliegen. Z. B. automatische Logout-Zeiten in der App, optional PIN-Schutz für die App, Remote-Löschung von zwischengespeicherten Offline-Daten. Mobile Zugriffe sollten genauso durch das Rechte- und Rollensystem beschränkt sein wie Desktop-Zugriffe.

Hier werden die einzelnen Funktionsbereiche (Module) des CAFM-Systems detailliert beschrieben. Dies entspricht einem Modul oder Prozessgebiet mit seinen spezifischen Anforderungen. Die Beschreibung erfolgt produktneutral und funktional, d.h. es wird beschrieben, was das System leisten muss, nicht unbedingt wie die Lösung technisch umgesetzt ist.

• Grundstruktur und Stammdaten: Das System soll eine hierarchische Struktur von Liegenschaften und Gebäudeobjekten erlauben. Übliche Hierarchie: Campus/Liegenschaft → Gebäude → Gebäudeteil/Bereich (optional) → Geschoss → Raum. Jedes dieser Objekte hat Stammdaten (Name, Nummer, Beschreibung, etc.). Die Hierarchie muss flexibel anpassbar sein (z. B. zusätzliche Ebenen wie „Trakt“ einfügbar). Auf oberster Ebene (Liegenschaft) werden allgemeine Daten gehalten wie Adresse, Grundstücksfläche, Katasterinformationen. Auf Gebäudeebene sind Attribute wie Baujahr, Bauart, Brutto-Grundfläche, Nutzfläche, Anzahl Stockwerke, Höhe, Hauptnutzung und technische Basisdaten (z. B. Heizungstyp, Energiestandard) zu verwalten. Diese dienen Berichtszwecken und als Vorbelegung für Räume (Vererbung von Eigenschaften, soweit sinnvoll).

• Gebäudepläne und -dokumente: Pro Gebäude können relevante Dokumente hinterlegt sein: Baupläne, Schnitte, technische Anlagenbücher, Flucht- und Rettungspläne, Prüfprotokolle etc. Das System muss es erlauben, solche Dokumente in strukturierter Form zu speichern (ggf. mit Dokumenttyp, Datum, Version). Ideal ist eine Verknüpfung mit dem Dokumentenmanagement, sodass z. B. immer der aktuelle Grundrissplan abrufbar ist. Pläne sollten sowohl als Datei (PDF/CAD) abgelegt sein als auch – nach Möglichkeit – interaktiv im System betrachtbar.

• Gebäudehistorie: Größere Maßnahmen am Gebäude (Sanierungen, Umbauten, Erweiterungen) sollten dokumentiert werden können. Dies kann über Verknüpfung zu Projektakten erfolgen oder als Chronologie im Gebäude-Stammdatensatz. Ziel ist, auch nach Jahren die wichtigsten Eingriffe nachvollziehbar zu halten (z. B. „2018 Dachsanierung, 2020 Anbau Südflügel“). Eventuell kann hier das Vertragsmanagement verknüpft werden (z. B. ein Bauvertrag als Dokumentation eines Umbaus).

• Liegenschaftsverwaltung und Verträge: Falls die Hochschule Liegenschaften angemietet hat oder anmietet, müssen Mietvertragsdaten am jeweiligen Objekt gepflegt werden können. Wichtige Felder: Vertragsbeginn, -ende, Mietkosten, Vermieter, hinterlegte Kaution, Indexierungsvereinbarungen, etc., um Laufzeiten und Konditionen im Blick zu behalten. Umgekehrt, falls Teile der Gebäude an Dritte vermietet werden (z. B. Mensa an einen Betreiber, Caféteria, Copyshop, Parkplätze an Dritte), sollen diese Flächen als solche gekennzeichnet und mit den entsprechenden Mietverträgen verknüpft werden.

• Flächen und Räume (Basisdaten): Jeder Raum gehört zu einem Gebäude/Geschoss. Die grundlegenden Flächenattribute (Raumnummer, Raumname, Fläche in m² nach DIN 277, Raumart/Nutzungsart) werden im Raumstamm gehalten. Es soll möglich sein, Summenflächen auf höheren Ebenen automatisch zu aggregieren (z. B. Summe Nutzfläche pro Gebäude oder pro Fachbereich). Für Räume und Flächen sollten zudem Kennzeichen für besondere Merkmale vorgesehen sein (z. B. Denkmalschutzstatus, Barrierefrei ja/nein, Laborraum etc.), um Auswertungen danach zu ermöglichen.

• Geodaten: Für Gebäude sollte neben der postalischen Anschrift auch eine Geokoordinate hinterlegt werden können (für Kartenansichten, Navigation). Bei großen Campusarealen kann es sinnvoll sein, Umrissflächen oder GIS-Daten zu speichern, um die Liegenschaften in einer Karte darzustellen. Eine optionale Integration zu GIS-Systemen oder Google Maps/OpenStreetMap für eine Übersichtskarte wäre hilfreich.

• Kostenstellen und Verantwortlichkeiten: Jedem Gebäude und/oder Raum kann eine organisatorische Zuordnung gegeben werden (z. B. zuständiger Fachbereich oder Kostenstelle). Das System soll erlauben, dass pro Objekt eine oder mehrere Verantwortlichkeiten hinterlegt werden: z. B. technische Verantwortung (Hausmeister-Team A), kaufmännische Verantwortung (Abteilung Gebäudemanagement), nutzerseitige Verantwortung (Fachbereich XY als Hauptnutzer). Diese Zuordnungen dienen u.a. dem Reporting von Kosten (Wer trägt welche Kosten?) und der automatischen Zuweisung von Meldungen (eine Störungsmeldung aus Raum X könnte direkt an den zuständigen Hausmeister gehen).

• Anzeigen und Sichten: Das Gebäudemanagement-Modul sollte Übersichtsseiten bieten, z. B. eine Liste aller Liegenschaften mit Kennzahlen (Gesamtfläche, Anzahl Gebäude, wichtigste Nutzung), eine Gebäudesteckbrief-Ansicht mit allen Stammdaten und verknüpften Objekten (Anlagen, Verträge, etc.), und eine Raumliste pro Gebäude. Eine grafische Navigation über den Standort-/Gebäudeplan (z. B. Klick auf Gebäude öffnet dessen Daten) ist wünschenswert.

• Integrationen: Die Daten aus diesem Modul werden in praktisch allen anderen Modulen genutzt. Daher muss z. B. bei Anlage eines neuen Raums sofort in der Raumliste (und ggf. in der Reinigungsplanung eintragbar sein. Ebenso sollten Änderungen, die in BIM-Planungstools gemacht wurden (neue Raumaufteilung), ins CAFM übernommen werden können (via IFC-Import).

• Auswertungen im Gebäudemanagement: Es muss möglich sein, Gebäudesteckbriefe zu erzeugen, die die wichtigsten Kenndaten eines Gebäudes zusammenfassen (Flächen, Baujahr, letzte Sanierung, Zahl der Arbeitsplätze, Energiekennwerte etc.). Ebenso Berichte wie z. B. „Liste aller Gebäude mit Baujahr vor 1970“ (für Sanierungsplanung) oder „Gebäude nach Eigentumsart (gemietet/Owned)“. Diese Auswertungen greifen oft auf Daten aus anderen Modulen zu (z. B. Energiekennwert), daher muss das Berichtswesen hier gute Vorlagen bereitstellen.

• Digital Twin Anbindung: Da ein digitaler Zwilling unterstützt wird, sollte das Gebäudemodul als „Anker“ für diesen dienen. Konkret: Das System sollte anzeigen können, welche Sensoren einem Gebäude/Raum zugeordnet sind und live deren Status einblenden (z. B. „Raumtemperatur aktuell 21°C“ direkt am Raumobjekt). Auch die Anbindung an 3D-Modelle (BIM-Viewer) kann hier geschehen, sodass ein Nutzer vom Raumstammdatenblatt zum 3D-Modell springen kann, wo der Raum hervorgehoben ist.

Durch das Vertragsmanagement-Modul wird sichergestellt, dass keine Fristen versäumt werden und alle Verpflichtungen sowie Ansprüche bekannt sind. Es schafft Transparenz über die laufenden Kosten und Leistungen. Insbesondere bei Outsourcing (Reinigung etc.) ist es die Basis, um zu prüfen, ob der Dienstleister liefert wie vereinbart. Zudem verbindet es sich mit den technischen und Flächendaten, sodass pro Objekt klar wird, welcher Vertrag gilt. Dies ist auch wichtig für Ausschreibungen: Das System liefert Daten, um neue Verträge auszuschreiben (z.B. m²-Zahlen, Leistungsumfang aus Ist-Verträgen als Basis).

• Raumkatalog: Alle Räume der Hochschule müssen mit eindeutiger Kennzeichnung erfasst sein (Raumnummer, Gebäude, Geschoss). Pro Raum werden Stammdaten verwaltet: Fläche (m², nach Nutzfläche oder Hauptnutzfläche nach DIN 277), Raumart (Hörsaal, Büro, Labor, Verkehrsfläche etc.), aktuelle Nutzung (z. B. Büro Prof. X, Seminarraum, Lager), ggf. Ausstattungskategorie (normal, hochwertig, einfach). Das System sollte erlauben, eigene Kataloge für Raumarten und Nutzungen zu hinterlegen (z. B. „Labor - chemisch“ vs. „Labor - IT“ etc.).

• Grafische Raumplanung: Wie ausgeführt, soll das System eine Visualisierung der Räume im Gebäudegrundriss ermöglichen. Für das Flächenmanagement ist dies zentral: z. B. farbliche Markierung aller Räume eines Fachbereichs oder Darstellung aller freien Räume in einem Gebäude. Die grafische Bearbeitung – etwa das Ändern der Raumgröße oder Zuschneiden von Räumen – wird in der Regel im CAD/BIM erfolgen, aber zumindest die Ergebnisse (geänderte Flächenmaße) müssen synchronisiert werden. Das System soll IFC- oder DWG-Importe nutzen können, um aktuelle Raumgeometrien einzulesen.

• Flächennutzungszuordnung: Jeder Raum bzw. jede Fläche sollte Organisationseinheiten zugeordnet werden können (z. B. Fakultät oder Verwaltungseinheit, die den Raum hauptsächlich nutzt). Da Räume auch geteilt genutzt werden können, sollte eine prozentuale Aufteilung möglich sein (z. B. 80% Fachbereich A, 20% Fachbereich B), oder alternativ flexible Zuschlagsregeln (z. B. Kosten werden zu gleichen Teilen aufgeteilt). Dies ist wichtig für interne Verrechnungen oder Berichte „Fläche pro Fachbereich“.

• Arbeitsplatzkapazität: Neben der Fläche ist oft die Anzahl Arbeitsplätze pro Raum relevant (speziell für Büros, PC-Pools, Hörsäle). Das System sollte ein Feld „Soll-Belegung“ (Arbeitsplatzanzahl) und „Ist-Belegung“ führen, um zu sehen, ob ein Raum überbelegt oder unterbelegt ist. Diese Infos fließen auch in Arbeitsplatzmanagement ein.

• Raumbuch (History): Das System sollte historisch nachvollziehen können, welche Nutzung ein Raum über die Zeit hatte. Z. B. 2010–2018 „Büro FB Wirtschaft“, seit 2019 „Labor Informatik“. Ebenso Umbennungen oder Umnummerierungen. Diese Historie hilft beim Auffinden älterer Dokumente (die vllt. noch alte Raumnummern tragen) und bei der Auswertung der Flächennutzung im Zeitverlauf.

• Auslastungsstatus: Für Flächen, die temporär zugewiesen werden (Projektbüros, temporäre Arbeitsplätze), sollte man sehen können, ob sie aktuell ungenutzt sind. Dies kann über die Verknüpfung mit dem Belegungsmanagement erfolgen. So wäre z. B. eine Übersicht „Leerstandsflächen“ im System generierbar.

• Open Space und Flächencluster: Das System sollte neben klassischen Räumen auch offene Flächen oder Zonen verwalten können (z. B. Coworking-Bereiche, Lounges). Diese haben ggf. keine festen Wände, aber werden als Bereich definiert und mit m² und Kapazität erfasst. Solche Bereiche könnten im Plan als Umriss gekennzeichnet sein.

• Bereitstellung für Planung: Das Flächenmanagement-Modul sollte Daten für strategische Planungen liefern können: z. B. Simulation, was passiert, wenn ein Fachbereich X% mehr Studierende hat – wieviel m² bräuchte man zusätzlich? Evtl. über Export der Daten ins CAD/BIM oder in eine Planungssoftware. Wichtig ist hier, dass man mit wenigen Klicks Flächenreports generieren kann, die Planungsgrundlagen bilden (z. B. Raumartenverteilung, Flächeneffizienz = m²/Studierende).

• Kennzahlen: Typische Kennzahlen im Flächenmanagement: Anteil Hauptnutzfläche vs. Verkehrsfläche, m² pro Person (Mitarbeiter, Studierende), Flächenausnutzungsgrad (belegte vs. verfügbare Büros), Kosten pro m² (wenn aus Verträgen hinterlegt) etc. Das System soll diese auf Knopfdruck liefern.

• Indoor Maps für Nutzer: Ein Nebenaspekt – es wäre hilfreich, wenn aus dem System heraus einfache Raumpläne für Nutzer generiert werden können (z. B. als Web-Link oder PDF), etwa ein Campusplan mit allen Räumen oder eine Raumübersicht pro Gebäude. So könnten neue Mitarbeitende oder Besucher sich orientieren. In Kombination mit der Indoor-Navigation (falls vorhanden) bietet man so einen Mehrwert für die Campus-App.

• Anbindung Stundenplanung: In einer Hochschule werden viele Räume durch die Lehrveranstaltungsplanung belegt. Eine Schnittstelle oder Datenabgleich mit dem Stundenplansystem (z. B. via Import der belegten Zeiten pro Raum) könnte helfen, im CAFM zu erkennen, wann Räume frei oder belegt sind – was für Reinigung und Wartung relevant ist. Dies gehört zwar nicht zum Kern-CAFM, aber die Integration solcher Nutzungsdaten macht das Flächenbild vollständiger.

• Zukunftsfähigkeit: Gerade mit Blick auf neue Arbeitsformen (Flexible Offices, Shared Spaces) muss das Flächenmanagement-Modul anpassbar sein. Sollten z. B. zukünftig komplett neue Flächenkategorien (etwa „Multispace-Zone“) entstehen, muss das System diese aufnehmen können. Offenheit für Erweiterung der Datenmodelle (neue Attribute, neue Flächentypen) ist daher wichtig.

Durch das Raum- und Flächenmanagement erhält die Hochschule einen vollständigen Überblick über die Nutzung ihrer räumlichen Ressourcen. Es bildet die Grundlage für viele weitere Entscheidungen, wie z. B. Umzüge, Bedarfsanmeldungen für Neubauten oder Optimierungen im Arbeitsplatzmanagement. Eine aktuelle und genaue Flächendatenbank ist zudem Voraussetzung, um im ESG-Kontext belastbare Kennziffern (Flächenbezug von Verbräuchen, m²-Produktivität etc.) berichten zu können.

• Personen-Raum-Zuordnung: Jede Person (Mitarbeiter/in der Hochschule) kann einem Büro/Arbeitsplatz zugeordnet sein. Das System sollte idealerweise an ein Personalverzeichnis angebunden sein, um Stammdaten der Personen zu erhalten. Die Zuordnung soll zeigen: Wer sitzt wo (und seit wann). Historie: Wenn Personen umziehen, soll das System dies nachvollziehen können (alte Zuordnung enden, neue beginnen). Damit lässt sich rückwirkend sehen, wer wann welchen Raum genutzt hat – relevant z.B. für Nachvollziehbarkeit oder Schadensfälle. Im Sinne der DSGVO sollte diese Historie allerdings nach gewisser Zeit anonymisiert werden können, falls nicht mehr notwendig.

• Hybrid Work und flexible Arbeitsplätze: Das CAFM soll flexible Arbeitsplatzkonzepte unterstützen. Beispielsweise können bestimmte Zonen als „Shared Desk Bereich“ definiert sein. Mitarbeitende buchen sich temporär einen Schreibtisch (über das Reservierungssystem, siehe 3.4) an den Tagen, an denen sie vor Ort arbeiten. Das System muss solche flexiblen Plätze verwalten und buchbar machen. Diese Desk-Sharing-Arbeitsplätze sollen im Plan angezeigt werden (z. B. als Schreibtisch-Symbole) und deren Belegung in Echtzeit aktualisiert werden (wer hat welchen Platz heute gebucht).

• Presence-Tracking: Für die Effizienz ist die Präsenzdetektion wichtig. Das System sollte integrativ mit Sensoren oder anderen Methoden arbeiten: z. B. Belegungssensoren an Schreibtischen, die melden, ob der Platz wirklich genutzt wird. So kann ein gebuchter, aber ungenutzter Platz nach gewisser Zeit automatisch wieder freigegeben werden. Alternativ kann ein Check-in via App oder durch Scannen eines QR-Codes am Tisch erfolgen. Ziel: Höhere tatsächliche Nutzung und automatische Freigabe von No-Shows. Diese Funktion vermeidet, dass Ressourcen blockiert bleiben, obwohl niemand sie nutzt.

• Kapazitätsmanagement: Im hybriden Betrieb will man wissen, wie viele Prozent der Arbeitsplätze an einem Tag belegt sind. Das System soll Auswertungen liefern, z.B. durchschnittliche Anwesenheitsquote pro Wochentag, Spitzenbelegungen, minimal genutzte Tage. Damit kann man beurteilen, ob ggf. Büroflächen reduziert oder umgewidmet werden können (Rightsizing). Auch die Steuerung von Infrastruktur (Reinigung, Kantinenangebot) kann sich daran orientieren.

• Arbeitsplatztypen: Das System sollte unterschiedliche Arbeitsplatztypen unterscheiden können: Feste Arbeitsplätze (persönlich zugewiesen), flexible Arbeitsplätze (Shared Desk), temporäre Projektarbeitsplätze, Co-Working-Spaces, spezialisierte Arbeitsplätze (Laborarbeitsplätze, Barrierefreie Plätze mit besonderer Ausstattung). Diese Typisierung soll im System gepflegt sein, um Buchungsregeln oder Berechtigungen daran knüpfen zu können (z. B. darf Laborplatz nur von Laborpersonal gebucht werden).

• Teams und Zonen (Neighbourhoods): In manchen Konzepten werden „Nachbarschaften“ gebildet – Teams haben eine Zone mit mehreren flexiblen Plätzen. Das System sollte solche Zusammenfassungen abbilden können (z. B. Team X hat Zone Y mit 10 Plätzen). Buchungen könnten dann z.B. erleichtert werden, indem ein Teammitglied einfach „Zone Y“ auswählt und das System einen konkreten Platz zuteilt. Auch Auswertungen pro Team sind so möglich.

• Service am Arbeitsplatz: Mit dem Belegungsmanagement verknüpft können Services geplant werden. Beispiel: Wenn an einem Tag wenige Leute im Büro sind, kann evtl. die Reinigung reduziert werden. Oder wenn jemand einen Platz bucht, könnte automatisch ein Bedarf gemeldet werden (z. B. Monitor oder Dockingstation an dem Platz bereitstellen). Solche Integrationen sind fortgeschritten, aber das System sollte zumindest die Datenbasis liefern, dass andere Module reagieren können (z. B. Reinigungsmodul sieht: Raum heute belegt oder nicht, siehe 3.7).

• Hotline/Anlaufstelle: Für Mitarbeitende im Hybrid-Modus sollte das System Infos bereitstellen: Welche Plätze sind heute frei, wo sitzen Kollegen, welche Räume sind verfügbar. Dies kann über eine App geschehen oder über ein Kiosk-Display im Foyer („Raumbelegungsübersicht heute“). Ziel: Transparenz und einfache Orientierung, um die neuen flexiblen Konzepte nutzbar zu machen.

• Auswertungen:

• Belegungsstatistiken: z.B. durchschnittliche Bürobelegung pro Tag, Peak- und Low-Tage, Auslastung der Flex-Plätze vs. fester Plätze.

• Flächenproduktivität: z.B. Verhältnis Anzahl Arbeitsplätze zu Bürofläche oder Verhältnis Mitarbeiter zu Arbeitsplätze (bei Shared Desk < 1, d.h. nicht jede*r hat einen eigenen Platz).

• Zufriedenheit: Falls möglich, könnten Umfragen zur Zufriedenheit mit dem Arbeitsplatzkonzept integriert oder ausgewertet werden (z. B. via Mitarbeiter-App Rückmeldung geben, ob das Buchen und Arbeiten flexibel gut klappt). Diese Daten könnten im System erfasst werden, um Workplace-Strategien anzupassen (etwa wenn viele Unzufriedenheiten mit Lärm in einer Shared Zone gemeldet werden).

Es unterstützt dieses Modul die Hochschule dabei, moderne Arbeitsplatzmodelle umzusetzen, was insbesondere in der Verwaltung relevant ist (Büroflächenoptimierung, attraktive Arbeitsbedingungen). Durch die Kopplung mit Sensorik und Buchungssystem werden tatsächliche Nutzungsdaten generiert, die eine fundierte Steuerung erlauben. Nicht nur kann man Flächen effizienter nutzen, sondern man gewinnt auch Flexibilität, um auf Veränderungen (z. B. mehr Homeoffice) zu reagieren. Gleichzeitig erhöht sich die Transparenz für Mitarbeitende: sie sehen, wo Platz ist, und können ihren Arbeitsort bedarfsgerecht wählen.

• Raumbuchungssystem: Das System soll ermöglichen, dass berechtigte Nutzer (z.B. alle Mitarbeitenden, bestimmte Studentengruppen) Räume online buchen können. Dies beinhaltet eine Kalenderansicht der Räume mit Verfügbarkeiten. Man soll einen gewünschten Zeitraum auswählen und eine Buchungsanfrage stellen können. Dabei können Buchungsdetails erfasst werden (Veranstaltungstitel, erwartete Teilnehmerzahl, Bedarf an Ausstattung oder Catering).

• Kalender und Übersicht: Eine übersichtliche Kalenderfunktion (Tages-/Wochenansicht) pro Raum bzw. eine zentrale Raumübersicht soll vorhanden sein. Freie und belegte Zeit-Slots müssen klar ersichtlich sein. Idealerweise gibt es eine Suchfunktion „Zeige mir einen freien Raum für 20 Personen am nächsten Dienstag 14–16 Uhr“ – das System soll also nach Kriterien (Zeit, Größe, Ausstattung) passende Räume finden.

• Buchungskriterien: Bei der Buchung können Kriterien wichtig sein: Anzahl Personen, benötigte Ausstattung (Beamer, Videokonferenztechnik, Barrierefreiheit), gewünschter Campus/Standort. Das System sollte auf Basis solcher Kriterien passende Räume vorschlagen, um den Nutzenden die Wahl zu erleichtern.

• Automatisierte Optimierung: Das System soll Möglichkeiten zur Optimierung der Buchungen bieten. Beispiele:

• Zusammenlegung von Buchungen: Falls zwei kleinere Meetings denselben Raum nacheinander halbtags nutzen, könnte das System vorschlagen, sie zeitlich/örtlich zusammenzulegen (wenn möglich), um einen anderen halben Tag frei zu bekommen – was z.B. Reinigung und Heizzyklen optimiert.

• Vermeidung von Leerstand: Das System sollte erkennen, wenn viele Buchungen in einem Gebäude, aber wenige in einem anderen sind, und ggf. empfehlen, neue Meetings eher in das weniger ausgelastete Gebäude zu legen (sofern sinnvoll, z. B. um Heizenergie zu sparen).

• Priorisierung: Falls ein Raum überbucht ist (mehrere Anfragen für dieselbe Zeit), sollen Mechanismen zur Priorisierung vorhanden sein (z.B. wer zuerst angefragt hat oder wer eine höhere Berechtigung hat). Alternativ könnte das System automatisch Ausweichräume anbieten.

• No-Show-Handling: Ein häufiges Problem sind Buchungen, bei denen niemand erscheint. Falls eine Buchender den Raum nicht aufsucht, soll nach X Minuten automatisch die Buchung als storniert markiert werden, damit andere den Raum nutzen können. Dafür wird Präsenzdetektion eingesetzt – z.B. über einen Check-in durch den Nutzer (per App-Button „Ich habe den Raum übernommen“) oder idealerweise durch Sensorik im Raum (Bewegungsmelder, Türsensor). Wird keine Präsenz festgestellt, wird die Buchung aufgehoben und der Raum wieder freigegeben. Diese Regeln (Wartezeit X, Methode Y) müssen parametrierbar sein.

• Wiederkehrende Buchungen: Regelmäßige Meetings (z.B. jeden Montag 10 Uhr Teammeeting) müssen als Serientermine eingebucht werden können. Das System soll Serien unterstützen und auch Ausnahmen verwalten (z.B. eine einzelne Instanz absagen oder verschieben, ohne die ganze Serie zu löschen).

• Genehmigungen: Für bestimmte Räume oder Ressourcen kann eine Genehmigungspflicht bestehen (z.B. die Aula nur mit Freigabe durch Verwaltung, oder ein teures Laborgerät nur nach Approval durch Laborleitung). Das System soll abbilden können, dass eine Buchungsanfrage zunächst von einer definierten Rolle freigegeben werden muss. Das kann in den Workflow integriert sein.

• Ressourcenbuchung: Neben Räumen sollen auch andere Ressourcen buchbar sein, z. B. Dienstfahrzeuge, Veranstaltungs-Equipment (Beamer, Messestände) oder Services (Catering, Technik-Support). Das System sollte die Möglichkeit bieten, solche Ressourcen mit dem gleichen Mechanismus zu verwalten. D.h. es gibt einen Ressourcenpool mit Verfügbarkeiten, ggf. verbunden mit bestimmten Bedingungen (z. B. Fahrer mit bestimmter Lizenz für Fahrzeug). Diese Ressourcen können dann ähnlich wie Räume gebucht werden, inkl. Kalender und Konflikterkennung.

• Benachrichtigungen: Das Modul soll Bestätigungs- und Erinnerungsfunktionen bieten. Bei erfolgreicher Buchung erhält der/die Anfragende eine Bestätigung (per E-Mail und/oder App-Push). Vor dem Termin können Erinnerungen verschickt werden („Ihre Raumbuchung 14–16 Uhr beginnt in 1 Stunde“). Bei Änderungen oder Absagen müssen die Beteiligten informiert werden. Auch Gebäude-Services (Portier, Facility) könnten Benachrichtigungen erhalten, z. B. tägliche Übersicht aller gebuchten Räume.

• Integration mit anderen Modulen:

• Reinigung: Wenn bestimmte Räume genutzt wurden, kann das Reinigungsmanagement automatisch informiert werden, um eine Sonderreinigung einzuplanen (z.B. nach einem Event mit Catering).

• Technik: Bei Buchung eines Veranstaltungsraums könnte automatisch eine Meldung an den technischen Dienst erzeugt werden, z. B. „Benötigt Unterstützung bei Medientechnik um 10 Uhr“.

• Zutritt: Im Zusammenspiel mit 3.10 könnte eine Raumbuchung dazu führen, dass der Buchende temporären Zutritt zum Raum erhält (bei elektronischen Schlössern) und nach Ende wieder entzogen wird.

• Self-Service Portal: Für die Nutzenden sollte die Buchungsoberfläche so einfach wie möglich sein – ideal via Web oder App in wenigen Klicks buchbar. Ein Statusdashboard „Meine Buchungen“ mit Möglichkeit zur Stornierung oder Änderung durch den Nutzer ist notwendig. Falls Wartelisten- oder Anfragemechanismen existieren (z.B. man kann sich melden „benachrichtigen, falls Raum früher frei wird“), sollte das System das unterstützen.

• Auswertungen & Optimierung: Das System soll Auslastungsanalysen der Ressourcen ermöglichen: z. B. welcher Raum ist wie häufig gebucht, durchschnittliche Vorlaufzeit der Buchungen, Anzahl No-Shows, Peak-Zeiten. Diese Daten helfen, Engpässe zu erkennen (z. B. „Raum A ist zu 90% belegt, Raum B nur zu 20% – warum?“) oder zu sehen, ob mehr Räume gebraucht werden. Auch die Effektivität des No-Show-Managements kann so evaluiert werden (Anteil an automatisch freigegebenen Buchungen).

• Integration mit Hochschulsystemen: Falls die Raumbuchungen im Kontext der Hochschule stehen, könnte eine Integration mit dem zentralen Raumverwaltungssystem (Lehrveranstaltungsplanung) überlegt werden, damit z.B. freie Stundenplanzonen automatisch als buchbar importiert werden oder umgekehrt.

• Benutzerfeedback: Nach dem Meeting oder der Nutzung könnte das System optional Feedback erfragen (z. B. „Raum in Ordnung? Technik funktioniert?“). Dies wäre im Störungsfall hilfreich (wenn jemand angibt „Beamer war defekt“, könnte automatisch ein Ticket erstellt werden). Solches Feedback erhöht die Qualität, ist aber optional.

Durch ein effizientes Buchungsmanagement wird der Nutzwert der Räume und Ressourcen maximiert. Nutzende können autonom und transparent Verfügbarkeiten einsehen und Reservierungen vornehmen. Die Verwaltung behält dennoch die Kontrolle durch Regeln und Auswertungen und kann Angebot und Nachfrage steuern. Insbesondere die No-Show-Reduzierung durch Präsenzdetektion sorgt dafür, dass knappe Ressourcen optimal genutzt werden. Zudem trägt das System dazu bei, durch Optimierungen (z. B. zusammengelegte Buchungen, intelligente Raumauswahl) Kosten zu sparen und die Nachhaltigkeit zu fördern (weniger heizen/leuchten von ungenutzten Räumen).

• Wartungsplanung: Das System muss die Planung wiederkehrender Wartungsaufgaben ermöglichen. Für jede relevante Anlage/Asset können Wartungspläne hinterlegt werden: Intervall (z. B. monatlich, jährlich, alle 100 Betriebstunden), Art der Wartung (Inspektion, Wartung, Kalibrierung etc.), zuständige Person/Abteilung oder externer Dienstleister. Es sollen Wartungstermine generiert werden, und das System erinnert automatisch an bevorstehende Wartungen (mit definierbarem Vorlauf).

• Gesetzliche Prüfungen: Betreiberpflichten wie ZÜS-Prüfungen von Aufzügen, Druckbehälterprüfungen, E-Checks etc. müssen abgebildet werden. Das System sollte hierfür idealerweise hinterlegte Vorlagen haben oder zumindest ermöglichen, die Prüffristen parametrierbar einzustellen. Wichtig ist, dass keine Frist versäumt wird: automatische Erinnerung/Alarm bei Fristüberschreitung.

• Arbeitsaufträge: Aus Wartungsterminen müssen konkrete Aufträge generiert werden, mit Auftragsnummer, Beschreibung, Fälligkeit, Priorität. Diese Aufträge können intern zugewiesen oder extern vergeben werden (Integration mit Lieferantenmanagement.

• Checklisten: Für standardisierte Wartungs- und Prüfabläufe sollte das System Checklisten hinterlegen können, die vom Ausführenden abgehakt werden. So wird sichergestellt, dass alle erforderlichen Schritte durchgeführt werden (z. B. „Filter gewechselt“, „Ölstand geprüft“).

• Dokumentation: Nach Durchführung muss derdie Technikerin das Ergebnis dokumentieren: Was wurde getan, Messergebnisse, Befund, ggf. Fotos, benötigte Ersatzteile. Das System muss diese Ergebnisse speichern (Wartungshistorie pro Anlage) und Dokumente anhängen können (z. B. Prüfprotokoll als PDF). Rechtssicher: Für gesetzlich vorgeschriebene Prüfungen muss nachvollziehbar sein, dass sie erfolgt sind und bestanden wurden. Im Falle eines Audits oder Unfalls muss aus dem System ein Nachweis erbracht werden können, dass alle vorgeschriebenen Prüfungen termingerecht erledigt wurden. Die Dokumentation muss daher unveränderbar sein und idealerweise mit Zeitstempel/Unterschrift (digital) versehen werden können.

• Anpassungsfähigkeit: Der Instandhaltungsplaner muss Termine verschieben können (mit Begründungsfeld), falls betrieblich notwendig, aber das System soll Warnungen geben, wenn man über das Intervall hinausgeht (Verstoß gegen Vorschrift). Das System sollte zudem umplanen können, wenn z. B. ein externer Dienstleister einen Termin nicht halten kann (Neudatierung aller betroffenen Anlagen).

• Routen-/Kapazitätsplanung: Wenn viele Wartungen anstehen, sollte das System eine Planungsübersicht bieten, idealerweise gruppiert nach Standort/Gewerk. So kann der FM-Leiter z.B. sehen: im nächsten Monat 10 Wartungen in Gebäude A, 5 in B – und diese so legen, dass ein Techniker alle in Gebäude A an einem Tag erledigt (optimierte Routenplanung). Einige Systeme bieten hierfür automatische Tourenplanung; minimal soll man manuell terminieren können mit guter Übersicht (Plantafel).

• Predictive Maintenance: Moderne Systeme gehen über sture Intervalle hinaus und ermöglichen zustandsabhängige, vorausschauende Wartung. Das CAFM sollte vorbereitet sein, Predictive Maintenance umzusetzen. D.h. Sensorwerte oder Betriebsdaten analysieren und Wartungen auslösen, wenn eine Abnutzung erkennbar wird (z. B. Schwingung an Pumpe zu hoch = Lager austauschen, bevor es ausfällt). Hierzu:

• Sensor-Integration: IoT– das System soll Sensorwerte überwachen können, Grenzwerte kennen und bei Überschreitung Alarm oder Auftrag generieren. Beispiel: Vibrationssensor an Lüftungsmotor -> Alarm bei ungewöhnlicher Schwingung -> Wartungsauftrag „Motorlager prüfen“ automatisch erstellen.

• Betriebsstundenzähler: Für Anlagen, deren Wartung nach Laufzeit erfolgt (z.B. Notstromaggregat alle 50 Betriebsstunden), sollte das System Zählerstände erfassen und daraus Wartungen auslösen können. Integration mit Gebäudeleitsystem oder manuelle Eingabe der Zählerstände ist denkbar.

• Datenanalyse: Das System sollte Daten zur Anlagenzuverlässigkeit liefern: MTBF (Mean Time Between Failures), häufigste Störungen pro Anlage, Wartungskosten pro Jahr. Mit Analytics kann man erkennen, welche Anlagen oft Probleme machen und ggf. ersetzt gehören. Langfristig könnten KI-Algorithmen diese Daten auswerten und proaktiv Empfehlungen geben (z. B. „Pumpe X zeigt Auffälligkeiten, empfiehlt Austausch nächsten Sommer“).

• Störungsmanagement (reaktive Instandhaltung): Enge Verzahnung mit Modul 3.6: Störungsmeldungen aus dem Helpdesk müssen als Work Orders ins Instandhaltungsmodul übernommen werden können. Jede Störung wird priorisiert und kategorisiert (z. B. Heizung ausgefallen – Priorität hoch). Daraus wird ein Auftrag generiert, der intern zugewiesen oder extern vergeben wird. Das System sollte SLAs bei Störungen unterstützen (z. B. Reaktionszeit 2h bei „hoch“) und überwachen, ob diese eingehalten werden, inkl. Eskalation, wenn eine Störung zu lange offen ist.

• Auftragsstatus: Jeder Wartungs- oder Reparaturauftrag durchläuft Status wie „geplant“, „in Bearbeitung“, „erledigt“, „abgeschlossen (dokumentiert)“. Diese Status müssen nachvollziehbar im System gepflegt werden. Der aktuelle Bearbeitungsstand soll für Beteiligte (Techniker, Auftraggeber, evtl. Melder) einsehbar sein, z. B. via Self-Service-Portal kann der Meldende sehen „In Bearbeitung seit 2 Tagen“.

• Zuweisung & Terminierung: Das System soll ermöglichen, Aufträge bestimmten Personen oder Teams zuzuweisen. Interne Techniker haben vordefinierte Zuständigkeiten (z. B. Elektriker für alle Elektro-Aufträge). Auch externe Dienstleister können als Auftragnehmer hinterlegt werden. Jeder Auftrag hat eine Frist oder Wunschtermin. Das System soll bei Planung berücksichtigen, ob Ressourcen verfügbar sind (Kalender der Techniker). Ein Kalender/Planungsboard zur Verplanung von Technikern ist hilfreich (z. B. alle Aufträge eines Tages nach Techniker sortierbar).

• Material und Kosten: Wenn während der Instandhaltung Material gebraucht wird, soll das erfasst werden können. Das System sollte ermöglichen, Material aus einer hinterlegten Teileliste auszuwählen und ggf. Lagerbestände zu führen (Ersatzteillager). Ebenso Arbeitszeiten: Der Techniker soll seinen Aufwand (Stunden) auf den Auftrag buchen. Daraus ergeben sich Ist-Kosten, die dem Auftrag (und ggf. Kostenstellen) zugeordnet werden. So entsteht sukzessive ein Kostenüberblick pro Auftrag und pro Anlage.

• Mobile Unterstützung: Wie in 2.4 beschrieben, sollen Techniker mobil arbeiten können. Konkret: Der Techniker sieht auf der App seine zugewiesenen Aufträge, kann vor Ort Checklisten abhaken, Ergebnisse eintragen (Messwerte, Befund), Fotos hochladen und schließlich den Auftrag als erledigt melden. Offline-Fähigkeit ist wichtig, da Technikräume im Keller evtl. kein Netz haben. Durch QR-Code-Scan (oder NFC) am Asset kann der Techniker sicherstellen, dass er den richtigen Datensatz offen hat (Vermeidung von Verwechslungen).

• Wartungshistorie & Lebenslaufakte: Das System muss Wartungshistorien pro Anlage führen. Also eine Liste aller durchgeführten Wartungen/Reparaturen mit Datum, Befund, Maßnahmen, Kosten. So ist nachvollziehbar, was an einem Gerät bisher gemacht wurde. Diese „Lebenslaufakte“ ist wichtig für Entscheidungen (z. B. Austausch bei häufenden Störungen, Ende Lebensdauer erreicht etc.). Idealerweise können hier auch Kennzahlen wie Verfügbarkeit oder Totalausfallzeiten auf Anlagebene ausgewertet werden.

• Regelwerke und Betreiberpflichten: Das System sollte aktuelle gesetzliche Prüfintervalle möglichst kennen oder zumindest ermöglichen, diese zu parametrisieren. Idealerweise enthält es eine Bibliothek gängiger Prüfpflichten (z.B. Brandschutzeinrichtungen jährlich nach DIN, Aufzüge alle 2 Jahre, Trinkwasser halbjährlich etc.). So kann man bei Einrichtung der Anlage gleich die entsprechenden Prüfungen auswählen. Außerdem wäre ein Report „Erfüllung der Betreiberpflichten“ hilfreich – welcher Prüfpunkt ist erledigt, was steht an, was ist überfällig. Damit kann man gegenüber Aufsichtsbehörden oder internem Audit zeigen, dass die Hochschule ihren Pflichten nachkommt.

• Berichte und Kennzahlen Instandhaltung:

• Offene Wartungsaufträge nach Priorität, überfällige Wartungen, demnächst fällige Wartungen (Forecast-Liste).

• Störungsstatistik: Anzahl Meldungen pro Monat, durchschnittliche Reaktions- und Lösungszeit, Häufigkeit pro Kategorie.

• Kostenstatistik: Wartungskosten pro Gebäude, pro Anlage, Budget vs. Ist pro Jahr, etc.

• Verfügbarkeiten: z. B. „Anlage X war im letzten Jahr 98% der Zeit verfügbar“ (falls Ausfallzeiten erfasst).

• KPI: Wartungsquote (Anteil planmäßiger vs. ungeplanter Instandhaltungskosten), Durchschnittliches Wartungsintervall pro Anlagenart, etc.

• Feedback und Qualität: Nach Abschluss eines Instandhaltungsauftrags kann intern Feedback eingeholt werden. Der Auftraggeber oder Melder könnte bewerten, ob die Leistung zufriedenstellend war. Dies ist optional, kann aber als Qualitätskontrolle dienen. Z.B. „War die Störungsbehebung zu Ihrer Zufriedenheit?“ – positive/negative Rückmeldungen könnten gemonitort werden.

• Integration mit Vertragsmanagement: Viele Wartungen werden durch externe Firmen durchgeführt. Das System muss diese einbinden können: Bei generiertem Wartungsauftrag sollte vermerkt werden können „extern durch Firma X“. Das Vertragsmodul liefert den dazugehörigen Wartungsvertrag mit Firma X, sodass ersichtlich ist, was vertraglich vereinbart ist (SLA, Umfang). Nach Ausführung durch Externe kann der interne FM-Mitarbeiter das Feedback eintragen oder – besser – der Dienstleister bekommt einen begrenzten Zugang (Portal oder E-Mail-Link), um die Durchführung selbst zu bestätigen und einen Bericht/Leistungsnachweis hochzuladen. So wird dokumentiert, dass der Auftrag erfüllt wurde und wann.

• Leistungskontrolle extern: Das System soll unterstützen zu prüfen, ob der Dienstleister Leistung gemäß Vertrag erbracht hat. Zum Beispiel, ob alle vereinbarten Wartungen fristgerecht durchgeführt wurden. Hier können Verknüpfungen zum Lieferantenmanagement hergestellt werden, z. B. KPI „100% der Wartungen im Vertrag erfüllt, 0 mal Frist verletzt“. So fließen die Ergebnisse der Instandhaltung in die Bewertung der Dienstleister ein.

Durch das Instandhaltungsmanagement-Modul wird sichergestellt, dass technische Anlagen und Gebäude zuverlässig betrieben werden können. Es unterstützt proaktive Wartung, minimiert Ausfallzeiten und gewährleistet die Einhaltung aller Prüfpflichten. Im Kontext der Hochschule bedeutet das auch Sicherheit für Nutzer (z. B. funktionierende Türen, keine Unfallgefahren) und Schutz der Werte. Mit neuen Technologien wie IoT-Sensorik und KI kann das System Ausfälle verhindern, bevor sie passieren, was langfristig Kosten spart und die Betriebsbereitschaft erhöht. Zudem schafft die lückenlose Dokumentation und Nachweisführung eine hohe Rechtssicherheit.

• Meldungserfassung (Self-Service): Mitarbeitende und Studierende sollen niedrigschwellig Störungen oder Anforderungen melden können. Dies sollte via Web-Portal und mobil (App) möglich sein. Eine intuitive Eingabemaske fragt die wichtigsten Infos ab: Kategorie des Problems (wählbar aus Liste: z. B. Reinigung, Technik, Ausstattung, Schaden), Beschreibung, Ort (Raum wählen oder automatisch durch Standortermittlung), optional Foto anhängen. Der Meldende wird automatisch zugeordnet (aus dem Login).

• Kategorisierung und Priorisierung: Das System soll eingehende Meldungen anhand der gewählten Kategorie und ggf. Schlagworte automatisch einer Priorität zuordnen oder zumindest einen Vorschlag machen. Beispiel: Kategorie „Sicherheitsrelevanter Defekt“ = Priorität Hoch. Hier könnte perspektivisch KI helfen, Freitextbeschreibungen zu analysieren und Kategorien/Prioritäten vorzuschlagen (Text Mining).

• Ticket-Workflow: Jedes Ticket durchläuft einen definierten Workflow:

• Offen: neu eingegangen, noch nicht zugewiesen.

• In Bearbeitung: einem Mitarbeiter/Team zugewiesen, in Arbeit.

• Wartend: ggf. wenn auf externe Teile/Dienstleister gewartet wird.

• Erledigt: Problem behoben, aber noch nicht vom Meldenden bestätigt.

• Geschlossen: vom Meldenden oder automatisch nach Zeit bestätigt.

• Zuweisung und Eskalation: Das Helpdesk-Modul soll über Regelwerke Tickets automatisch zustellen können. Etwa basierend auf Kategorie und Ort: „Heizung defekt in Gebäude X“ wird automatisch dem Haustechniker-Team X zugewiesen. Falls keine automatische Regel greift, sieht ein Helpdesk-Mitarbeiter das Ticket in einer zentralen Liste und kann manuell zuteilen. Wichtig: Eskalationen, wenn ein Ticket zu lange offen bleibt. Dann soll z. B. nach 24h ohne Reaktion ein Reminder an den Teamleiter gehen.

• Kommunikation mit Meldenden: Das System soll den Meldenden auf dem Laufenden halten: Bestätigung der Ticketaufgabe (Ticketnummer, Info, eventuell FAQ-Hinweis falls bekanntes Problem), Benachrichtigung bei Statusänderungen („Ihr Ticket wird jetzt bearbeitet von …“, „Ihr Ticket wurde erledigt“). Diese Kommunikation idealerweise per E-Mail und in der App/Portal (mein Ticket-Status).

• Wissensdatenbank/FAQ: Häufige einfache Anliegen könnten durch Selbsthilfe gelöst werden. Das System könnte beim Erfassen einer Meldung ähnliche vorhandene Tickets oder eine FAQ anzeigen („Es ist kalt im Raum? -> Bitte prüfen Sie zuerst, ob Fenster geschlossen.“). Eine Wissensdatenbank mit Lösungen und Workarounds, verknüpft mit dem Ticketsystem, ist wünschenswert. Zukünftig könnte ein Chatbot trivialen Fragen begegnen („Wie melde ich einen Schaden?“) und Antworten geben.

• Bearbeitung und Dokumentation: Der zuständige Techniker oder Dienstleister bearbeitet das Ticket, behebt das Problem. Im System dokumentiert er die durchgeführte Maßnahme, evtl. Ursache, aufgetretene Kosten oder Materialverbrauch. Falls das Ticket mit einem Asset verknüpft ist (z. B. kaputter Beamer, der im Inventar gelistet ist), sollte die Historie dort ebenfalls vermerkt werden.

• Mobile Bearbeitung: Techniker sollten die ihnen zugewiesenen Tickets mobil sehen und Rückmeldungen eingeben können. D.h. ein Techniker vor Ort löst das Problem, macht z.B. ein Foto von der Reparatur und setzt den Status auf „Erledigt“ über die App. Das erhöht die Aktualität der Daten und spart doppelte Erfassung.

• Externe Dienstleister einbinden: Wenn eine Meldung durch externe Firmen gelöst werden muss (z. B. Aufzugstechnik), soll das System dies abbilden. Optionen: Entweder ein interner Mitarbeiter setzt den Status „Weitergeleitet an Firma XY – Termin am …“, oder – bei fortgeschrittener Nutzung – der Dienstleister erhält einen Portalzugang zu seinen zugewiesenen Tickets. Über E-Mail-Links könnte zumindest die Rückmeldung vereinfacht werden („Bestätigen Sie hier, dass der Auftrag erledigt ist und laden Sie Ihren Bericht hoch“).

• Leistungsmessung: Das System soll KPIs für das Helpdesk bieten: durchschnittliche Reaktionszeit, durchschnittliche Lösungszeit, Anzahl Tickets pro Kategorie, Prozentsatz innerhalb SLA gelöst, User-Zufriedenheit. Diese Kennzahlen sollten in Dashboards und Reports bereitstehen, um die Servicequalität zu überwachen.

• Feedback durch Melder: Wenn der Bearbeiter das Ticket auf „Erledigt“ setzt, sollte er einen Abschlussbericht eingeben (was wurde getan, ggf. Ursache, aufgetretene Kosten). Der Meldende kann das Ergebnis prüfen. Optional kann der Meldende ein Feedback geben (Zufriedenheit/Bewertung). Das System könnte eine einfache Feedback-Frage nach Ticketabschluss senden („Waren Sie zufrieden? Ja/Nein oder Sternebewertung“). Das ist gut für Qualitätskontrolle, aber kein Muss. Falls gesammelt, soll ein Durchschnittswert je Kategorie oder gesamt ausgewertet werden können.

• Ticket-Archiv und Suche: Abgeschlossene Tickets sollen archiviert, aber durchsuchbar sein. Oft melden verschiedene Nutzer im Abstand das gleiche Problem – eine Recherche „gab es in Raum 101 schon mal eine ähnliche Meldung?“ kann hilfreich sein (vielleicht gibt es ein tieferes Problem). Die Suchfunktion sollte Volltext und Filter (nach Zeitraum, Ort, Kategorie) erlauben.

• Verbindung zu anderen Services: Das Helpdesk-Modul kann nicht nur Störungen, sondern auch allgemeine Anforderungen managen. Beispielsweise „Bedarf: zusätzlicher Tisch für Veranstaltung aufstellen“ – solche Service Requests könnten analog behandelt werden, ggf. mit anderen Workflows (Genehmigung durch Vorgesetzten bevor es umgesetzt wird). Das System sollte flexibel sein, um neben Störungen auch Aufträge oder Anfragen (Servicekatalog) aufzunehmen.

• Notfallmanagement: In Notfällen (z. B. Wasserrohrbruch) sollten definierte Prozesse unterstützt werden. Z.B. ein Notfall-Ticket könnte gleich mehrere Personen alarmieren (Push-Nachricht an alle Haustechniker „Wasserrohrbruch Gebäude B, sofort handeln“). Solche Sonderroutinen sind wünschenswert.

• Multi-Channel: Neben der primären digitalen Meldung sollte das System auch Meldungen erfassen können, die telefonisch oder persönlich eingehen (dann erfasst ein Hausmeister das Ticket eben manuell im System). Wichtig ist, dass wirklich alle Vorgänge im System landen, auch wenn nicht jeder Nutzer die App nutzt. Somit sollte das System auch eine schnelle manuelle Ticketerfassung durch den FM-Sachbearbeiter erlauben („Anruf von Frau Y: Licht defekt in Raum Z“).

• Priorisierung von VIP/Eskalation: Das System sollte es ermöglichen, bestimmte Nutzer oder Bereiche als VIP/Eilbedürftig zu markieren (z. B. Rektoratsbereich). Tickets von dort könnten automatisch höher priorisiert werden oder eine andere Eskalationsstufe haben.

• Störungsstatistik und Ursachenanalyse: Nach einer gewissen Betriebszeit sollte das System Auswertungen erlauben, welche Ursachen häufig auftreten („wiederkehrende Probleme“) und ggf. präventive Maßnahmen empfehlen. Falls z. B. regelmäßig Überlastung einer Stromleitung gemeldet wird, könnte das System anzeigen „10 mal Sicherung raus in letzten 3 Monaten“ -> Hinweis, die Elektrokapazität prüfen (dies könnte ein FM-Mitarbeiter aus den Daten lesen, oder eine KI könnte darauf aufmerksam machen).

Durch ein zentralisiertes Helpdesk-System erhöht sich die Transparenz und Nachverfolgung von Problemen. Nutzer können jederzeit den Status ihrer Meldung sehen und wissen, dass nichts untergeht. Für das FM-Team ermöglicht es eine strukturierte Abarbeitung und Priorisierung. Außerdem entsteht eine wertvolle Datengrundlage: Welche Probleme treten wo am häufigsten auf? Wie zufrieden sind die Nutzer mit der Lösung? Dies hilft, interne Prozesse zu verbessern und Ressourcen gezielt einzusetzen. In einer Hochschulumgebung trägt dies unmittelbar zur Nutzungsqualität der Gebäude bei – Hörsäle sind funktionsfähig, Arbeitsplätze intakt, Anliegen der Nutzer werden ernst genommen und zügig bearbeitet.

• Reinigungspläne und Bereiche: Zunächst müssen alle zu reinigenden Bereiche im System erfasst sein. Dies umfasst Räume sowie ggf. Sonderflächen (Treppenhäuser, Foyers, Außenanlagen). Jedem Bereich wird eine Reinigungszone und ein Reinigungstyp zugeordnet. Z.B. Büro – tägliche Unterhaltsreinigung; Hörsaal – Reinigung nach Nutzung; Sanitärraum – 2× täglich; Labor – spezielle Reinigung wöchentlich. Das System soll erlauben, Reinigungspläne aufzustellen: Welche Fläche wird wann gereinigt und mit welcher Frequenz. Beispielsweise: Gebäude A, 1.OG: Büros täglich Mo-Fr, Flure täglich, Hörsäle nach jeder Veranstaltung, etc.

• Leistungsverzeichnis: Es sollte möglich sein, je Reinigungszone die auszuführenden Tätigkeiten zu definieren (Staubwischen, Müll entsorgen, Saugen, Nasswischen, Desinfektion etc.). Das System kann hier Vorlagen bieten (Reinigungsstandards). So ist dokumentiert, welcher Leistungsumfang vereinbart ist.

• Dynamische Anpassung: Ein modernes CAFM sollte in der Lage sein, Reinigungspläne dynamisch an Nutzungsdaten anzupassen. Beispielsweise: Wenn ein Hörsaal mehrere Tage ungenutzt war, kann die Reinigung seltener erfolgen; umgekehrt nach einer Veranstaltung mit Catering könnte eine Sonderreinigung eingeplant werden. Oder wenn laut Belegungsmanagement heute nur 20% der Büros belegt waren (viele im Homeoffice), kann die Reinigung einiger Räume übersprungen bzw. reduziert werden. Das System sollte solche Logiken ermöglichen, zumindest indem es Belegungs- und Buchungsdaten auswertbar macht und manuell darauf reagiert. Fortgeschritten: Automatisches Generieren von Zusatzaufträgen („Event X im Raum Y – generiere Sondereinigung für morgen früh“) oder Reduzieren von Routineaufträgen (heute wenige Leute – halbiere Reinigungsumfang).

• Personaleinsatzplanung: Das System sollte eine Möglichkeit bieten, Reinigungspersonal und Reviere zu planen. D.h. welcher Reiniger ist welchem Bereich zugeordnet und wie viel Zeit pro Aufgabe eingeplant ist. Eine digitale Revierkarte/Plan kann helfen (z.B. Gebäude A: Herr X reinigt EG+1.OG, Frau Y 2.OG...). Diese Funktion ist oft rudimentär in CAFM, da meist Dienstleister eigene Planung machen, aber zumindest intern sollte man die Übersicht haben.

• Eigenleistung vs. Fremdleistung: Die Software muss sowohl Eigenreinigungsteams als auch externe Dienstleister abbilden können. Bei Fremdvergabe: Das System sollte Reinigungsdienstleister als solche verwalten und die vereinbarten Leistungen als Soll hinterlegen. Der Dienstleister liefert z.B. Turnuspläne, die ins System übernommen werden, oder man vereinbart, dass das CAFM der führende Plan ist (dann muss der Dienstleister nach Plan arbeiten).

• Auftragsgenerierung: Das System soll Reinigungsaufträge generieren. Z.B. täglich um 5 Uhr morgens generiert es für jeden Bereich den Tagesauftrag („Reinigung Standard - Bereich X, gemäß Plan“). In der Praxis wird man eher periodisch Pläne ausgeben (Wochenplan). Hier kann das System pro Woche/Tag einen Leistungsnachweis ausgeben, was zu tun ist. Wenn Abweichungen auftreten (Sonderaufträge, Ausfälle), sollte das System diese erfassen (z. B. „Bereich Z heute nicht gereinigt wegen Veranstaltung im Gange“).

• Mobile Unterstützung für Reinigungsteams: Falls das Reinigungspersonal mit mobilen Geräten arbeiten kann, sollte das System das unterstützen. Z.B. eine App mit ihrer Aufgabenliste der Räume. Sie können dann abhaken, was erledigt ist, und ggf. besondere Vorkommnisse notieren („Fenster kaputt vorgefunden“ – das würde wiederum ein Störungsticket auslösen). Auch Zeiterfassung könnte hier integriert sein.

• Qualitätssicherung: Sehr wichtig ist die Reinigungs-Qualitätssicherung. Das System sollte vorsehen, dass Stichprobenkontrollen durchgeführt werden. Dazu kann es Checklisten für Inspektionen geben (z.B. Sauberkeit Büro 101 bewertet mit Schulnote). Solche Inspektionen sollen geplant werden können (z.B. pro Woche X% der Flächen kontrollieren) und das Ergebnis dokumentiert werden. Mangelpunkte sollen nachverfolgbar sein (z. B. „Qualitätsmangel: Staub auf Regal – nachgereinigt am ...“).

• Verbrauchsmaterial: Optional könnte das System auch Reinigungsmittel-Verbrauch verwalten oder Bestände (z.B. Handtuchpapier, Seife). Das ist meist Nebensache, aber es sollte zumindest dokumentierbar sein, wo Spender nachgefüllt werden müssen oder wann Material nachbestellt werden muss. Solche Tätigkeiten ließen sich in die Aufträge integrieren (Check „Seife aufgefüllt“).

• Integration mit Helpdesk: Nutzerfeedback spielt auch hier eine Rolle. Wenn z.B. Nutzer eine Beschwerde melden „Raum nicht sauber“, kommt das als Ticket rein (3.6) und sollte mit dem Reinigungsmodul verknüpft sein. Evtl. ist es sinnvoll, den Reinigungstrupp automatisch darüber zu informieren und einen Nachreinigungsauftrag zu erzeugen.

• Berichte und KPIs: Das System soll Kennzahlen zur Reinigung liefern:

• Flächenleistung (m² pro Stunde/Reinigungskraft).

• Reinigungskosten pro m² pro Jahr, nach Gebäuden oder Bereichen (Daten aus Verträgen, interne Löhne).

• Qualitätsergebnisse (Durchschnittsnote der Kontrollen, Anzahl Beanstandungen pro Monat).

• Einhaltung der Frequenzen (wurden alle geplanten Reinigungen durchgeführt?).

• Verbrauchsmaterial-Statistik (wenn erfasst).

• Entwicklung der Reinigungsaufwände im Zeitverlauf (z. B. sinkt Aufwand durch Hybrid Work?).

Diese Zahlen helfen, die Reinigungsdienstleistung zu steuern und bei Vergaben oder internen Anpassungen als Grundlage.

Es sorgt das Reinigungsmanagement-Modul dafür, dass die Sauberkeit auf dem Campus planmäßig und nachvollziehbar gewährleistet wird. Durch die Verknüpfung mit Nutzungsdaten kann eine bedarfsgerechte Reinigung umgesetzt werden – das spart Kosten und Ressourcen (Zeit, Reinigungsmittel) und kann die Nachhaltigkeit unterstützen (weniger Chemikalieneinsatz, wenn nicht nötig). Gleichzeitig dokumentiert das System die erbrachten Leistungen, was besonders bei Fremdvergabe wichtig ist, um nachzuweisen, dass der Dienstleister seinen Vertrag erfüllt (bzw. umgekehrt dem Dienstleister nachweisen zu können, wenn er Leistungen nicht erbracht hat). Für die Nutzer wiederum wird über Rückmeldemöglichkeiten sichergestellt, dass deren Anforderungen (Sauberkeit) wahrgenommen werden und schnelle Reaktionen erfolgen, sollte mal etwas nicht stimmen.

• Umzugsantrag und Genehmigung: Interne Umzüge können initiiert werden durch einen Antrag (z. B. Fachbereich stellt Antrag, dass Mitarbeitender X in anderen Raum ziehen soll). Das System sollte eine Möglichkeit bieten, einen Umzugswunsch zu erfassen, inkl. Grund, von Raum A nach Raum B, Wunschtermin. Dieser kann dann einen Freigabe-Workflow durchlaufen (Abteilungsleitung, FM-Leitung zustimmen).

• Umzugsplanung: Sobald ein Umzug feststeht, soll das System als Planungswerkzeug dienen. Es müssen alle Aufgaben koordiniert werden: Möbel abbauen, IT-Abbau/Anschluss, Transport, Wiederaufbau, ggf. Renovierung alter Raum (Maler), Beschilderung anpassen, Aktualisierung der Raumbücher etc. Das System sollte eine Checkliste oder Vorlage für Standard-Umzüge bieten, damit nichts vergessen wird. Idealerweise lassen sich aus der Checkliste Aufgaben generieren und Verantwortliche zuweisen (z. B. IT-Abteilung erhält Aufgabe „Telefon umpatchen“).

• Zeitplanung: Umzüge haben oft eine Timeline (Freitag ab 14 Uhr packen, Samstag Umzug, Sonntag Einrichten, Montag Arbeitsbereit). Das System sollte Umzugstermine festhalten und Kollisionen vermeiden (nicht zwei große Umzüge gleichzeitig, oder nicht Umzug in Gebäudeteil während Prüfungstermine etc., sofern planbar).

• Ressourcen: Wird ein externer Umzugsdienst genutzt? Dann Verbindung zum Vertragsmanagement (Speditionsvertrag) und Lieferantenmanagement (Firma muss eingebunden werden, Termin bestätigen etc.). Interne Ressourcen: z. B. Haustechnik für Möbelabbau, Anzahl Umzugskartons – solche Ressourcen könnten hinterlegt und disponiert werden. Das System könnte z.B. anzeigen „Für Umzug X werden 50 Kartons benötigt, Bestand 100 – ok“.

• Kommunikation: Beteiligte (ziehende Person, ausführende Teams, Vorgesetzte) sollten automatisch Info erhalten. Z.B. „Ihr Umzug ist am …, bitte packen Sie Ihre Sachen bis …“. Oder „IT-Team: am … Rechner von Person X umziehen zu Raum Y“.

• Umzugsdurchführung: Am Tag des Umzugs kann das System als Kontrollliste dienen – Abhaken der erledigten Schritte. Eventuell mobil via Tablet, auf dem der Umzugskoordinator sieht, was als nächstes kommt und wer zuständig ist.

• Nachbereitung: Nach dem Umzug sollte das System ermöglichen, den Abschluss zu dokumentieren: alle Räume aktualisiert (die Person ist jetzt in neuem Raum zugeordnet -Update), Inventar umgezogen (Update Inventar mit neuem Standort), Schlüssel zurückgegeben/neu ausgegeben (Update), Beschilderung aktualisiert, altes Büro ggf. frei zum Buchen markiert. Ein guter Teil dieser Schritte kann automatisiert passieren, wenn die Verknüpfungen stimmen – z. B. sollte die Änderung der Person-Raum-Zuordnung automatisch eine Aufgabe auslösen, die alten Schlüssel einzusammeln.

• Umzugsprotokoll: Alle durchgeführten Umzüge sollten historisch erfasst sein, insbesondere, wer wann von wo nach wo gezogen ist (Verbindung mit Personalstammdaten). Zusätzlich kann man auch Kosten erfassen (falls Umzugskosten intern verrechnet oder als Kennzahl gebraucht werden: z. B. Umzugskosten pro Mitarbeiter-Umzug).

• Auswertungen: Z.B. Anzahl Umzüge pro Jahr, durchschnittliche Umzugskosten, häufige Umzugsgründe, Auslastung der Umzugskapazität.

• Zufriedenheit: Vielleicht Feedback der Umziehenden (Zufriedenheit mit Organisation). Das könnte man optional per kurzem Survey nach dem Umzug einholen – verbessert die Prozesse.

• Großumzüge/Projekte: Falls mal große Umzugsprojekte anstehen (ganzer Fachbereich zieht in Neubau), sollte das System skalieren: Das ließe sich als ein Projekt mit vielen Einzeltickets modellieren. Manche CAFM-Systeme bieten hier eigene Module, aber im Kern kann es das normale Umzugsmanagement mit zusätzlichen Planungsfunktionen (z. B. Visualisierung alter vs. neuer Belegung).

• Integration mit Flächenmanagement: Ein Umzug hat direkten Einfluss auf Flächendaten. Z.B. wird ein Raum frei und kann neu zugewiesen werden. Das System sollte nach einem Umzug automatisch den Raumstatus aktualisieren (z. B. „frei ab 01.10.“). Evtl. kann man aus dem System heraus freie Räume für geplante Umzüge suchen („welche 3 zusammenhängenden Büros könnten wir dem neuen Institut zuordnen?“).

• Umzüge von Sachmitteln: Nicht nur Personen ziehen um, auch Inventar (Möbel, Geräte). Das System sollte Inventarlisten pro Umzug erzeugen können und damit die Aktualisierung im Inventarmodul erleichtern („die folgenden 20 Inventargegenstände wechseln den Standort zu Raum Z“).

• Schlüssel und Zugänge: Verbindung – bei Umzug müssen oft Schlüssel zurückgegeben und neue ausgehändigt werden. Das sollte im Prozess berücksichtigt sein und getrackt werden (automatische Tickets an Schlüsselverwaltung: „bereite Schlüssel für neuen Raum vor, entziehe alten“).

Durch das Umzugsmanagement werden interne Umzüge transparent geplant und effizient abgewickelt. Insbesondere bei häufigen Personalwechseln oder Raumoptimierungen hilft das, alle Beteiligten zu koordinieren und Folgeschritte (IT, Schlüssel, Inventar) nicht zu vergessen. Zudem können so die Auswirkungen von Umzügen auf die verschiedenen Daten im System (Raumbelegung, Inventar, Zugänge) konsistent umgesetzt werden, ohne Medienbruch. Das erhöht die Datenqualität (keine „Karteileichen“, wo jemand noch altem Raum zugeordnet ist) und entlastet die FM-Organisation, weil vieles vordefiniert abläuft.

• Inventarverzeichnis: Das System soll eine zentrale Inventardatenbank bereitstellen. Jedes Asset bekommt einen Datensatz mit eindeutiger Inventarnummer (ggf. Barcode/RFID), Bezeichnung, Typ/Kategorie, Zugehörigkeit (Gebäude, Raum oder Person), technischen Daten (bei Anlagen: Hersteller, Modell, Seriennummer, Leistung etc.; bei Möbeln: Maße, Farbe, Material falls nötig) und Kauf-/Inbetriebnahmedatum. Auch der aktuelle Buchwert bzw. Anschaffungswert kann hinterlegt sein, zumindest als Info oder via Schnittstelle zum ERP.

• Kategorisierung: Es soll möglich sein, Inventar in Klassen und Kategorien zu strukturieren. Z.B. Oberkategorie „Elektrogerät“, Unterkategorie „Beamer“ oder „Laborgerät -> Mikroskop“. Diese Klassifizierung hilft bei Auswertungen (z. B. alle Beamer, Durchschnittsalter etc.). Möglicherweise kann an Normen wie DIN 276 (Kostengruppen) oder IFC-Klassen angelehnt werden.

• Standort und Verantwortlicher: Jedes Inventarobjekt sollte einem Standort (Raum) zugewiesen sein und optional einem Verantwortlichen (z. B. Gerät P gehört zu Lehrstuhl Y, Verantwortlicher Prof. Z). Veränderungen (Umzüge von Geräten, Eigentümerwechsel) sollen nachvollziehbar protokolliert werden.

• Zustand und Wartung: Falls ein Inventarobjekt regelmäßig gewartet wird, muss dies verknüpft sein. Z.B. ein Aufzug als Asset hat Wartungsplan X. Der Zustand (gut, mittel, schlecht / Restlebensdauer) sollte festgehalten werden können. Nach Inspektionen kann der Zustand angepasst werden (z. B. „verschlechtert, Ersatzteile benötigt“), was in die Erneuerungsplanung einfließt.

• Asset-Lifecycle: Das Modul soll den Lebenszyklus jedes Assets abbilden:

• Beschaffung: Möglichkeit, Beschaffungsanforderungen zu starten oder zumindest zu dokumentieren, wann und von wem beschafft (Verknüpfung zum Vertrag/Lieferant, Rechnung).

• Betrieb: Im Betrieb verknüpft mit Wartungs- und Störungsdaten, so dass alle Ereignisse am Asset dokumentiert sind. Jedes Ticket aus 3.6 und jede Wartung aus 3.5, die sich auf das Asset beziehen, sollten sichtbar sein.

• Umbau/Upgrade: Falls ein Asset modifiziert wird (z.B. neuer Motor eingebaut in Maschine, Software-Upgrade), sollte man das historisch notieren können oder über Versionierung abbilden (Asset Version 2 ab Datum X).

• Verlagerung: Standortwechsel (Umzug des Assets) wird protokolliert – das gab es bei 3.8. D.h. das System führt Aufzeichnungen, wo das Asset wann war.

• Außerbetriebnahme: Wenn ein Asset ausgemustert wird, sollte es entsprechend markiert werden (mit Datum, Grund: defekt, verkauft, Spende etc.). Ggf. Integration mit ERP, um die buchhalterische Abschreibung/Entfernung vorzunehmen.

• Entsorgung/Nachhaltigkeit: Dokumentation, ob umweltgerechte Entsorgung erfolgt ist (z. B. Nachweis E-Schrott) kann angehängt werden. Außerdem könnte das System bei der Planung neuer Anschaffungen helfen, indem es aus den Daten alter Assets lernt (z.B. „Gerät X hatte Lebensdauer 5 Jahre, plane Ersatzbudget“).

• Nutzungsdauer und Ersatzplanung: Das System sollte überwachen, wann ein Asset das Ende seiner geplanten Nutzungsdauer erreicht (z.B. gemäß AfA oder internen Richtwerten). Vorher sollte es Hinweise geben für Ersatzinvestitionen. Eine Erneuerungsplanung kann so unterstützt werden – z.B. Liste aller Anlagen älter als 15 Jahre, sortierbar nach Kritikalität/Bedeutung. So sieht man, wo bald Investitionsbedarf besteht.

• Garantie & Gewährleistung: Das System muss erfassen können, ob für ein Asset noch Garantie besteht. Wenn ja, sollte bei Störungsmeldungen an dem Asset ein Hinweis erscheinen „Gerät noch in Garantie – Hersteller kontaktieren statt eigene Reparatur“. Ebenso sollten Wartungsverträge verknüpft sein: Wenn ein Asset unter einen Wartungsvertrag fällt, sollte das im Asset-Datensatz sichtbar sein.

• Finanz- und Vertragsverknüpfung: Jedes Asset kann in Verträge eingebunden sein:

• Wartungsverträge (z.B. Wartung Aufzüge durch Firma Z – deckt Asset Aufzug1, Aufzug2).

• Leasingverträge (falls z.B. Kopierer geleast).

• Mietverträge (z.B. Gebäude-Leasing, dann Asset sind ggf. Gebäudeteile).

Das System soll diese Verknüpfungen abbilden, damit klar ist, welche externen Leistungen an einem Asset hängen. Außerdem sollen Kosten zugeordnet werden können: Anschaffungskosten, bisher aufgelaufene Wartungskosten (aus Instandhaltung summiert), Energiekosten (wenn z.B. Zähler an Gastherme). Dies ermöglicht Life-Cycle-Costing-Analysen: Wie teuer ist uns Anlage X in Summe, lohnt sich ein Austausch auf ein effizienteres Modell?

Zusammengefasst stellt das Asset-Management sicher, dass sämtliche Ausstattung und Anlagen inventarisiert sind und deren Historie und Status transparent ist. Es ermöglicht strategische Entscheidungen über Reparatur oder Ersatz, verbessert die Planung von Investitionen und sorgt für Klarheit, was wo vorhanden ist – um Verluste, ineffiziente Mehrfachanschaffungen oder Sicherheitsrisiken (durch vergessene Altgeräte) zu vermeiden. Durch die Integration mit Wartung und Verträgen entsteht ein vollständiges Bild pro Anlage. In Richtung Digital Twin sind die Asset-Daten der Grundbaustein: Sie werden mit Echtzeit-Sensordaten verknüpft, um ein lebendiges Abbild aller wichtigen physischen Güter der Hochschule zu haben.

• Schließplandokumentation: Die Software muss die Schließhierarchie der Hochschule abbilden. Für mechanische Schließanlagen bedeutet das: Anlegen von Schließkreisen, Schlössern (Zylindern) und Schlüsseln. Jedes Schloss gehört zu einer Tür/Raum, jeder Schlüssel sperrt definierte Schlösser. Es soll möglich sein, einen Schließplan zu hinterlegen, aus dem hervorgeht, welcher Schlüssel welche Türen öffnet. Bei elektronischen Systemen entspricht das den Zutrittsprofilen (Karten/Transponder mit Berechtigungen). Das System sollte beide Welten unterstützen: mechanisch (Schlüssel physisch) und elektronisch (Zutrittskarten/Badges).

• Daten pro Schloss/Zylinder: Nummer, Einbauort (Tür/Raum), Zugehörigkeit zu welcher Schließanlage/Gruppe (z.B. „Hauptgebäude Anlage 1“ oder „FB Wirtschaft Gruppenschloss“).

• Daten pro Schlüssel/Transponder: eindeutige ID, Zugehörigkeit (zu welcher Anlage/Gruppe), Liste der schließbaren Türen oder ein Profil. Bei mechanisch meist Liste der Schließnummern; bei elektronisch ein definiertes Profil (z.B. „Student Allgemeinzugang“).

• Das System sollte idealerweise automatisch aus den hinterlegten Gruppen ermitteln können, welche Schlüssel in welche Türen passen, und Plausibilitätschecks machen (z.B. Widersprüche erkennen).

• Schlüsselausgabe und Rückgabe: Kernfunktion: Verwaltung, wem welche Schlüssel ausgegeben wurden. Für jeden physischen Schlüssel (oder Karte) muss protokolliert sein: ausgegeben an Person X, Datum, ggf. mit Unterschrift (digital/Papier hinterlegt). Genauso Rückgabe mit Datum.

• Das System soll Ausgabebelege erzeugen können (z.B. PDF-Formular, das der Mitarbeiter unterschreibt bei Empfang) und diese digital speichern.

• Hinterlegte Kautionen oder Verträge für externe Personen (z.B. Studierende Wohnheimschlüssel mit 50€ Kaution) sollten vermerkbar sein.

• Offene Posten: Es muss Auswertungen geben, welche Schlüssel noch nicht zurückgegeben wurden (z.B. Person exmatrikuliert, Schlüssel aber noch im Umlauf – kritisch).

• Berechtigungsverwaltung (elektronisch): Für elektronische Zutrittssysteme muss das CAFM die Vergabe von Zutrittsprofilen unterstützen:

• Profile definieren (z.B. „Student“ hat Zugang Mo–Fr 7–20 Uhr zu Gebäude 1 und 2, kein Zugang zu Labor, kein Zugang zu Serverraum).

• Personen diesen Profilen zuordnen. Im Idealfall holt man Gruppenzugehörigkeit aus LDAP („Student der Fakultät ABC“) und das System generiert automatisch passendes Profil.

• Schnittstellen zum Zutrittssystem (z.B. Salto, Kaba) müssen vorhanden sein, sodass Berechtigungen aus dem CAFM übertragen werden können (entweder via API oder im einfachsten Fall CSV-Export der Personen-Berechtigungen, die ins Zutrittssystem importiert werden).

• Temporäre Berechtigungen: Unterstützung für Gästekarten oder zeitlich begrenzte Zugänge (z.B. Handwerker erhält Karte gültig 1 Tag). Das System sollte das verwalten inkl. automatischer Deaktivierung nach Ablauf, sodass keine vergessenen Zugänge aktiv bleiben.

• Multi-Faktor-Zutritt: Das System sollte berücksichtigen, dass zukünftig vermehrt Multi-Faktor-Authentifizierung auch an physischen Türen eingesetzt wird. Beispielsweise Türen, die nur mit Karte und PIN oder Karte und Fingerabdruck geöffnet werden. Das CAFM sollte solche Türen/Schlösser kennzeichnen können (Sicherheitsstufe Hoch, erfordert 2. Faktor) und im Berechtigungsprofil vermerken, ob jemand den 2. Faktor hat. Bei Zutrittsanfragen (an das Sicherheitsteam) sollte das System diese zusätzlichen Anforderungen kenntlich machen (z. B. „Für Serverraum ist zusätzlich Biometrie erforderlich“). Auch die Verwaltung der zweiten Faktoren (PIN-Codes, Biometriedaten – wobei letztere eher im Zutrittssystem verbleiben) sollte konzeptionell unterstützt werden. Insgesamt muss das CAFM mit den Prinzipien von Zero Trust Physical Security mitgehen können, die verstärkt MFA an Türschwellen einsetzen.

• Verlust und Sicherheit: Wenn ein Schlüssel als verloren gemeldet wird, soll das System auf Knopfdruck alle betroffenen Schlösser/Türen identifizieren (z.B. verlorener Generalschlüssel → sehr kritisch; verlorener normaler Schlüssel Nr. 123 → betrifft Raum Y und ggf. Hauptschließung Z). So kann man schnell Maßnahmen einleiten (Schlösser tauschen, Karten sperren).

• Das System sollte einen Prozess "Schlüsselverlust" unterstützen mit Dokumentation der Meldung, ggf. Kosten (manche Organisationen verlangen Ersatzkosten), und Nachverfolgung, ob Schlosswechsel nötig/erfolgt ist.

• Notfallpläne: Man könnte im System Notfallkontakte pro Schlüssel hinterlegen (z.B. wer hat Zweitschlüssel?). Oder definieren, wer im Notfall Zutritt zu sensiblen Bereichen hat.

• Schlüsselbestand: Überblick, wie viele Schlüssel von welcher Sorte vorhanden sind, wie viele ausgegeben, wie viele in Reserve. Bei mechanischen kann man Seriennummern anlegen und den physischen Bestand pflegen. Falls Reserven knapp werden (nur noch 1 Ersatzschlüssel vorhanden), sollte das System einen Hinweis geben. Integration zur Bestellung neuer Schlüssel (einige Schließanlagenhersteller haben Codes – hier müsste man i.d.R. manuell bestellen, aber das System kann die Info bereitstellen).

• Integration Personen und Räume:

• Verknüpfung mit Personal-/Studentendaten: Idealerweise bezieht das System Personendaten aus HR oder der Studentendatenbank, um Namen, Status etc. aktuell zu halten – damit bei Austritt/Exmatrikulation entsprechende Schlüsselrückgaben getriggert werden können.

• Verknüpfung mit Raumdaten: Jedes Schloss bezieht sich auf einen Raum oder Bereich, also Integration mit Raumstammdaten (3.2). Wenn jemand umzieht (3.8), sollte das System anzeigen, dass ein neuer Schlüssel benötigt wird und der alte zurückzugeben ist. Evtl. startet das Umzugsmodul automatisch einen Schlüsselprozess.

• Bei Austritt einer Person (Info aus HR oder manuell), soll ein Alarm kommen: „Person X verlässt am Datum Y, folgende Schlüssel sind noch offen – bitte einziehen“. So geht kein Schlüssel verloren.

• Zutritts-Monitoring: Für elektronische Systeme: Das System könnte, wenn gewünscht, Zugangslogs importieren oder anzeigen. Allerdings ist das datenschutztechnisch sensibel; meist bleibt es im Zutrittssystem. Optional: Logging von Zutritten in kritische Räume (Serverraum) könnte im CAFM zur Auswertung (Später kam es dort zu einem Incident – wer war drin?) genutzt werden. Aber hier gilt strenge DSGVO-Prüfung.

• Reporting und Sicherheit:

• Schlüsselprotokoll: Jederzeit abrufbar, wer welche Schlüssel hat (inkl. temporärer wie Gäste).

• Liste aller Generalschlüssel und wer sie hat (wichtig für Risikoabschätzung).

• Offene Posten: Liste aller ausstehenden Schlüsselrückgaben.

• Kapazitätsauslastung: z.B. „90% der vorhandenen Schließkarten sind ausgegeben“ – falls relevant, z. B. System hat Limit.

• Auswertung Anzahl Verlustfälle pro Jahr, Kosten durch Schlosswechsel etc.

• Vertrags- und Wartungsaspekte: Falls die Schließanlage selber betreut/gewartet wird vom Hersteller, kann das im Vertragsmodul verknüpft sein (Wartungsvertrag Schließsystem). Elektronische Systeme haben evtl. Software-Lizenzen oder Updates – das ist mehr IT, aber sollte zumindest erwähnt werden, falls relevant (Vertrag mit Security-Provider).

• Zukunft: Elektronische Zutritte über Mobile Devices (Handy als Schlüssel) werden häufiger. Das System sollte solche neuen Technologien berücksichtigen, also z.B. die Verwaltung digitaler Berechtigungen (Versenden eines mobilen Schlüssels via App an Gast). Das könnte zwar extern laufen, aber das CAFM sollte dokumentieren, wem so ein Zutritt geschickt wurde (ähnlich einem ausgegebenen Schlüssel) und wann es erlischt.

Dieses Modul verbessert die Sicherheit und Verwaltung immens: Statt papierbasierten Listen ist digital nachvollziehbar, wer Zutritt hat. Das senkt Risiken (z.B. vergessene Schlüsselrückgaben) und reduziert den administrativen Aufwand. Durch Integration mit Personen- und Raumdaten werden Schlüsselprozesse Teil des großen Ganzen (Onboarding, Umzug, Offboarding automatisch mit den passenden Schlüsselfragen). Neue Sicherheitsstandards wie multifaktorielle Zutrittskontrolle können abgebildet werden, was die Hochschule zukunftssicher macht. Im Ereignisfall (Verlust, Diebstahl) kann schnell reagiert werden, da alle Informationen zentral vorliegen.

• Zentrales Vertragsregister: Das System soll ein Vertragsregister bereitstellen, in dem alle relevanten Verträge eingepflegt sind. Pro Vertrag gibt es Kerndaten: Vertragsart, Vertragspartner, Beginn, Ende, Verlängerungsklauseln/Kündigungsfristen, Kosten/Konditionen, Leistungsumfang, zuständiger interner Verantwortlicher.

• Vertragstypen und Felder: Jeder Vertragstyp kann spezifische Felder haben:

• Mietvertrag (die Hochschule als Mieter): gemietete Fläche/Objekt, Mietpreis, Nebenkosten, Indexierung, Kaution, Vermieter.

• Mietvertrag (Hochschule als Vermieter): Mieter, Fläche, Mieteinnahme, Nebenkostenregelung, Index, ggf. Nutzungsauflagen.

• Wartungsvertrag: welche Anlagen abgedeckt, Intervalle, SLAs (Reaktionszeit bei Störung), Pauschalen/Kosten pro Einsatz.

• Dienstleistungsvertrag (z.B. Reinigung): Leistungsbeschreibung (Flächen, Frequenzen), Vergütungsmodell (Pauschale oder nach Leistung), Qualitätskriterien.

• Leasing: Objekt, Leasingrate, Laufzeit, Restwert/Optionen.

• Dokumentenablage: Der vollständige Vertragstext (gescannter Vertrag, PDF) sowie Nachträge, Leistungsbeschreibungen etc. sollen im System hinterlegt werden können, sodass man jederzeit darauf zugreifen kann. Versionierung wichtig: man sollte sehen, was aktuell gültig ist vs. alte Version.

• Fristenmanagement: Ein zentrales Feature: Das System muss Kündigungsfristen und Verlängerungsoptionen überwachen. Beispiel: „Vertrag Reinigung läuft 31.12. aus, Kündigungsfrist 3 Monate vorher“ – Alarm am 30.09., wenn bis dahin keine Verlängerung entschieden. Oder „Mietvertrag verlängert sich auto um 1 Jahr am 01.04. – Erinnerung 01.01. ob gekündigt werden soll“. Diese Fristen sollen im System erfasst und per Workflow/Alert verfolgt werden.

• Indexierungen: Wenn Verträge Indexklauseln haben (z.B. Miete nach Verbraucherpreisindex), sollte das System das dokumentieren. Evtl. kann es automatisch anpassen, ist aber meist zu komplex – doch zumindest ein Hinweis „Miete wird angepasst laut Index xx, nächstes Update erwartet Jan 2024“ wäre gut.

• Optionen: Falls es Verlängerungsoptionen oder Sonderrechte gibt (z.B. Option auf weitere Fläche, Sonderkündigungsrecht bei Förderausfall), sollte das System diese in Freitext oder strukturiert aufnehmen, damit die Verantwortlichen diese nicht vergessen.

• Zahlungspläne: Das System muss nicht zur Finanzbuchhaltung werden, aber zumindest die Kosten und Zahlungszyklen festhalten: z.B. Miete monatlich X Euro, Nebenkosten jährlich Abrechnung, Wartungsvertrag jährlich im Voraus Betrag Y. So kann man eine Übersicht der laufenden FM-Verpflichtungen bekommen und auch das Budget planen.

• Rechnungsprüfung: Optional könnte das CAFM nutzen, um Eingangsrechnungen zu prüfen (z.B. eine Heizkostenabrechnung einer gemieteten Fläche mit den Systemdaten abgleichen). Dies ist aber ggf. in der Finanzsoftware besser aufgehoben. Wichtig ist, dass das FM weiß, welche Kosten laut Vertrag erwartet werden, um Abweichungen zu erkennen. Leistungsverzeichnis und Vertragserfüllung: Wichtig ist, dass man den Umfang der vertraglichen Leistung abbildet, um die Erfüllung prüfen zu können. Z.B. Reinigungsvertrag: welche Gebäude/Flächen, welche Häufigkeit – das kann entweder textlich angehängt sein oder strukturiert: das System könnte erlauben, pro Reinigungsvertrag die übernommenen Flächen zuzuordnen. So kann man dann sehen, ob der Dienstleister diese Flächen laut Soll auch gereinigt hat (Abgleich mit Ist aus Reinigungsmodul).

• Verknüpfung mit Modulen: Verträge sind eng mit anderen Modulen verknüpft:

• Liegenschaftsmanagement: Mietverträge als Mieter oder Vermieter an Objekte geknüpft.

• Instandhaltung: Wartungsverträge an Anlagen geknüpft.

• Reinigungsmanagement: Reinigungsvertrag an Leistungsbereiche geknüpft.

• Dienstleistermanagement: Jeder Vertrag gehört i.d.R. zu einem Lieferanten, diese Verknüpfung muss sichtbar sein („Firma X hat Vertrag Y, Z“).

• Energie/Nachhaltigkeit: Verträge für Energieversorgung – Daten evtl. relevant, z. B. Preise, um Kosten auszuwerten.

• Auswertungen und Portfolio: Das System soll es ermöglichen, das Vertragsportfolio auszuwerten: Anzahl Verträge pro Art (wie viele Miet-, Dienstleistungs-, Wartungsverträge etc.). Gesamtkosten pro Jahr für jede Kategorie (Summe Mieten, Summe Dienstleisterkosten). Übersicht aller Vermietungen (Flächen, Einnahmen, Auslastung der vermieteten Räume). Historie: abgelaufene Verträge archivieren, mit Enddatum, um nachzuvollziehen, welche Leistungen früher bezogen wurden. Anteil Verträge mit Nachhaltigkeitsklauseln oder ESG-Kriterien (falls erfasst, siehe unten).

• Risiko/Governance: Das System könnte festhalten, ob bestimmte Verträge Compliance-Aspekte haben (z.B. Konformität mit Vergaberecht, bestimmte Zertifikate). Dies ist eher in der Vergabephase relevant, aber Hinweise im Vertrag sind sinnvoll. Beispielsweise kann man bei Wartungsverträgen vermerken, ob der Anbieter alle ESG-Kriterien erfüllt hat – etwa „Lieferant hat Code of Conduct unterschrieben“ oder „Nachhaltigkeitsnachweis vorgelegt“. Solche Informationen können dann in ESG-Reportings einfließen (z. B. % der Dienstleister mit ESG-Vertrag).

• Nachhaltigkeitsklauseln: In zunehmendem Maße werden in Verträgen Nachhaltigkeits- und Sozialkriterien verankert (z.B. grüner Strom, faire Löhne bei Dienstleistern). Das System sollte ermöglichen, solche Klauseln oder Attribute zu dokumentieren. Beispielsweise ein Feld „ESG-relevant: Ja“ und Details („Lieferant verpflichtet zu xy“). Bei der Auswertung kann man dann angeben, welche Verträge nachhaltige Beschaffung repräsentieren.

• Dokumentenworkflow: Bei neuen Verträgen könnte das System den internen Freigabeprozess unterstützen (Vertragsprüfung durch Rechtsstelle etc.), aber das geht schon in Richtung eVergabe/Vertragsmanagement-Tool. Für unser Lastenheft reicht: Dokumentation und Benachrichtigung an verantwortliche Personen vor Fristen.

Zusammengefasst bildet das Liegenschafts- und Gebäudemanagement-Modul die Datenbasis für alle weiteren Funktionen. Es stellt sicher, dass alle Gebäude und Räume vollständig erfasst sind, mit ihren wichtigsten Eigenschaften und Dokumenten. Nur mit aktuellen und gepflegten Basisdaten können die folgenden Module (Flächenplanung, Instandhaltung, etc.) effizient arbeiten.

• Energie- und Verbrauchsdaten erfassen: Das System soll alle relevanten Verbrauchsdaten der Liegenschaften zentral sammeln. Insbesondere: Strom, Wärme (Gas/Fernwärme), Wasser, ggf. Kälte (Klimaanlage), Kraftstoffe (für Notstrom, Dienstfahrzeuge).

• Datenquellen: Optimal ist eine automatische Schnittstelle zu Zählern oder Energiemanagementsystemen. Falls nicht vorhanden, muss es einfach gestaltete Erfassungsmasken geben, um manuell Zählerstände periodisch einzugeben oder Verbrauchsmengen zu importieren (z.B. aus Abrechnungen der Versorger via CSV).

• Struktur nach Zählpunkten: Pro Gebäude/Gebäudeteil werden die Zähler definiert. Diese sind ggf. hierarchisch (Hauptzähler vs. Unterzähler für Bereiche/Etagen). Das System sollte Summenbildung beherrschen (z.B. Summe aller Unterzähler vs. Hauptzähler als Plausibilitätscheck).

• Zeitreihen: Verbrauchsdaten sind meist Zeitreihen (Monatsverbrauch, Tagesverbrauch). Das System soll diese zeitlich auflösen können. Möglicherweise auch Lastgänge (viertelstündige Werte), falls Smart Metering angebunden ist – zumindest optional aufnehmen.

• Analyse von Verbräuchen: Das System muss in der Lage sein, Verbrauchsverläufe grafisch und tabellarisch darzustellen. Z.B. Stromverbrauch pro Monat, Vergleich aktuelles Jahr vs Vorjahr, Heizenergie wetterbereinigt, etc.

• Kennzahlen: Energieintensität (kWh pro m² pro Jahr), Wasserverbrauch pro Nutzer, etc., sollen berechnet werden können. Diese Kennzahlen ermöglichen Benchmarking zwischen Gebäuden oder gegenüber Standards (z. B. EnEV/GEG Kennwerte).

• Alerts: Bei ungewöhnlichen Verläufen (z.B. plötzlicher Anstieg gegenüber typisch) sollte das System Alarme generieren, um auf mögliche Probleme hinzuweisen (Leckagen, defekte Steuerung, vergessenes Licht). Hier kann KI helfen, Muster zu erkennen, aber rule-based reicht initial (z.B. >20% Abweichung vom Vorjahr gleichen Monat = Alarm).

• CO₂-Bilanzierung: Wesentlicher Bestandteil: Das System soll automatisch aus den Verbrauchsdaten die CO₂-Emissionen berechnen. Dafür müssen Emissionsfaktoren hinterlegt sein (z.B. 0,000233 t CO₂ pro kWh Strom, spezifisch je nach Strommix; 0,2 kg pro kWh Gas usw., idealerweise editierbar und jährlich updatebar).

• Daraus generiert es die CO₂-Bilanz der Hochschule: Gesamt-CO₂, aufgeschlüsselt nach Scopes (Direkte Emissionen vor Ort, indirekte Energie-Emissionen, evtl. weitere Scope 3 falls erfasst).

• Berichte: z.B. jährlicher CO₂-Fußabdruck, Trends über 5 Jahre, Zielerreichung (gegenüber definierten Zielen, z. B. -30% bis 2030).

• Das System soll mehrere Berichtsformate unterstützen (z.B. nach GHG Protocol Scope 1/2/3, wobei Scope 3 wahrscheinlich nur Abfall, Geschäftsreisen etc., soweit FM-Daten vorhanden). Möglicherweise mit Integration externer Daten (Pendlerverkehr? vermutlich extern).

• Nachhaltigkeitskennzahlen (ESG insgesamt):

• Wasserverbrauch (m³/Jahr).

• Abfallaufkommen (kg oder m³, nach Müllfraktionen), basierend z.B. auf Entsorger-Rechnungen.

• Papierverbrauch der Verwaltung (Anzahl Ries pro Jahr) – falls relevant.

• Anteil Erneuerbare Energien im Strom (z.B. eigener PV-Anteil, Grünstromquote).

• Biodiversitätsmaßnahmen auf dem Campus (z.B. m² Grünfläche, Anzahl Bäume, jedoch eher qualitativ).

• Anzahl Arbeitsunfälle auf dem Campus (und deren Auswertung) – Arbeitssicherheit.

• Barrierefreiheit-Status der Gebäude (Anteil Gebäude barrierefrei zugänglich, Anzahl behindertengerechter Arbeitsplätze etc.).

• Mitarbeiterzufriedenheit im FM-Team (könnte man via HR-Umfragen einspeisen) oder Nutzerzufriedenheit mit FM-Services (durch die Feedbacks aus Helpdesk, Reservierung – z. B. durchschnittliche Zufriedenheitsbewertung Tickets).

• Soziale Projekte durch FM? (Z.B. Bereitstellung von Räumen für soziale Zwecke, aber das ist qualitativ und schwer quantifizierbar).

• Grad der Einhaltung von Prüfpflichten (Kennzahl: „Compliance-Quote 100%“ wenn alle vorgeschriebenen Prüfungen termingerecht erledigt sind, siehe 3.5).

• Zertifizierungen der Organisation oder Gebäude (Umweltmanagement nach EMAS, ISO 50001 Energie, Gebäudezertifikate nach DGNB/LEED).

• Anteil nachhaltiger Beschaffungen im FM (z.B. wie viele Verträge fordern Umweltkriterien, oder wie viel % Volumen an lokale Lieferanten).

• Datenqualität/Nachweisbarkeit: z.B. hat das CAFM selbst ein GEFMA 444 Zertifikat – Indikator dass Daten strukturiert erfasst sind.

• Schnittstellen und Datenimport für ESG: Vieles wird das FM nicht allein liefern – z.B. Mobilitätsdaten (Anteil Radfahrende, ÖPNV) oder Kantinen-Kennzahlen (z.B. Bio-Anteil Essen) könnten aber Teil eines Gesamt-ESG-Berichts sein. Das System sollte daher Schnittstellen haben, um Daten aus anderen Bereichen zu integrieren, oder zumindest manuelle Eingabe zulassen. Wichtig ist, dass es ein zentrales Repository für ESG-Zahlen bietet, damit bei der Berichterstellung alle Daten an einem Ort sind.

• Berichtserstellung und CSRD: Die Corporate Sustainability Reporting Directive (CSRD) verlangt ab 2025ff standardisierte Berichte für größere Organisationen. Das System sollte zumindest die relevanten FM-Daten hierfür bereitstellen. In Zukunft könnten Tools direkt CSRD-Berichte generieren; wir fordern: Reporting-Vorlagen: vordefinierte Berichte „Nachhaltigkeitskennzahlen Jahr X“ mit allen oben genannten Daten, schön formatiert. Exportmöglichkeiten: z.B. als Excel, der in das Gesamt-CSRD-Tool der Hochschule geladen wird, oder als JSON via API. Trends und Zielvergleich: man sollte im System Nachhaltigkeitsziele hinterlegen können (z.B. -5% Energie pro Jahr, -50% CO₂ bis 2030) und das System zeigt den Fortschritt an (Ampel Grün/Gelb/Rot oder in Berichten Abweichung zum Pfad).

• Nachhaltigkeits-Audits: Das System muss auditfähig sein, denn Nachhaltigkeitsdaten können geprüft werden (z.B. beim EMAS-Audit oder durch einen Wirtschaftsprüfer im Rahmen CSRD). Es sollte daher jede Kennzahl auf Rohdaten zurückführen können. Beispiel: Gesamtstrom 2024 = 1.200.000 kWh – das System muss zeigen können, dass das Summe aus Zähler A+B+C ist, deren Werte so im System erfasst wurden (mit Datum, ggf. Quelle hochgeladen). Eine lückenlose Nachvollziehbarkeit und Belegfunktion ist entscheidend. Idealerweise kann man Dokumente (z.B. Abrechnungen, Prüfberichte) direkt bei den Daten hinterlegen, um sie im Audit bereitzustellen. Das System sollte Auditreports bereitstellen (z. B. „zeige alle Eingaben und Änderungen an ESG-Daten mit Benutzer & Zeit“), damit man Vertrauen in die Datenqualität sicherstellen kann.

• Nutzer-Feedback und Awareness: Das System könnte Daten auch an die Nutzer kommunizieren. Beispielsweise ein Energie-Dashboard im Intranet „Heute 10% weniger Stromverbrauch als üblich – danke fürs Energiesparen!“. Das schafft Bewusstsein und animiert zur Mitarbeit. Gamification-Ansätze wären denkbar (Fachbereiche bekommen Feedback zu ihrem Energieverbrauch im Vergleich; das ist sensibel, aber falls gewünscht, kann das System es bereitstellen). Diese Funktionen gehen über reines Monitoring hinaus, zeigen aber, wie FM-Daten aktiv eingesetzt werden können, um Verhalten positiv zu beeinflussen.

Insgesamt hilft das Modul, die ökologische Performance der Liegenschaften zu überwachen und Verbesserungen zu steuern. Es vereinfacht das ESG-Reporting durch zentrale Datenhaltung und unterstützt die Hochschule dabei, ihre Nachhaltigkeitsziele systematisch anzugehen. Dabei werden FM-Daten (die oft einen Großteil des betrieblichen Ressourcenverbrauchs ausmachen) gezielt für strategische Entscheidungen nutzbar gemacht. Durch die Verknüpfung mit dem Digital Twin können Daten in Echtzeit einfließen und Optimierungen (wie KI-gestützte Steuerungen) direkt umgesetzt werden. Somit trägt das CAFM wesentlich zur Zukunftsfähigkeit der Hochschule bei – sowohl ökonomisch (Einsparungen) als auch ökologisch und sozial.

• Lieferantendatenbank: Zentrales Verzeichnis aller relevanten Unternehmen mit Kontaktdaten (Adresse, Ansprechpartner, Notfallnummern, E-Mail, Portal-Login falls vorhanden). Pro Lieferant kann man Kategorien zuordnen (z.B. „Reinigungsfirma“, „Sanitärtechnik-Wartung“, „Bauunternehmen“, „Energieversorger Strom“ etc.), damit man filtern kann. Wünschenswert: Erfassung wichtiger Dokumente/Nachweise zu den Firmen, z.B. ISO-Zertifizierungen, Präqualifikationen, Versicherungsnachweise. So hat man im Blick, ob ein Dienstleister erforderliche Qualifikationen hat und diese aktuell sind.

• Verknüpfung mit Verträgen und Leistungen: Jeder Lieferant ist in der Regel in einen oder mehrere Verträge eingebunden. Das System sollte anzeigen: Firma X hat folgende laufende Verträge (z.B. Reinigungsvertrag Gebäude A, Wartungsvertrag Aufzüge). So sieht man schnell, wofür die Firma zuständig ist. Umgekehrt: Wenn man im Vertrag ist, Verknüpfung zum Lieferantendatensatz. Das vermeidet doppelte Pflege, und Daten wie Kündigungsfristen etc. sind ja im Vertragsteil.

• Leistungsvergabe und -tracking: Das System sollte die Möglichkeit bieten, Leistungsverzeichnisse und Ausschreibungen für FM-Leistungen zu verwalten. Zumindest, wenn ein Vertrag ausläuft, kann man auf Basis der bisherigen Leistungen eine neue Ausschreibung vorbereiten. Nicht zwingend voll im CAFM (manche haben Vergabemodul), aber modulare Unterstützung wäre toll (z.B. Pflichtenheft für Reinigungsleistung aus dem System generieren, basierend auf Fläche und bisheriger Qualität). Alternativ wird das extern gemacht – dann zumindest Dokumentation im System (Ausschreibungsstart, Teilnehmer, Ergebnisse).

• Auftragsverwaltung: Wenn es außerhalb regelmäßiger Verträge Einzelaufträge an Dienstleister gibt (z.B. kleine Reparatur, Umbauprojekt), sollte das System das abbilden. D.h. ein generierter Arbeitsauftrag (aus Instandhaltung oder ad-hoc Bedarf) wird an Extern vergeben. Das System vermerkt: Firma Y, Auftrag Nr, Beschreibung, Termin, Kostenangebot. Nach Ausführung Rückmeldung + Rechnung. So hat man eine Historie aller Einzelaufträge pro Firma (was war wann zu welchem Preis).

• Portal oder Schnittstelle für Dienstleister: Ein fortschrittliches Feature: ein Dienstleister-Portal, wo externe Firmen sich in ihre Aufträge einloggen können. Z.B. Reinigungsdienst sieht hier seine Reinigungspläne und kann Fertigstellung markieren; Wartungsfirma sieht fällige Wartungen, bestätigt Termin und lädt Protokoll hoch. Alternativ via E-Mail-Interaktion: System sendet z.B. automatisiert E-Mail mit Link zum Feedback. Wichtig ist, dass das System die Möglichkeit vorsieht, externen begrenzten Zugriff zu geben, ohne interne Daten zu gefährden (Zugriff nur auf deren Aufträge/Verträge). Das entlastet die FM-Orga, weil Dienstleister eigenständig Status melden können.

• Leistungsmessung und KPIs: Das Modul soll Performance-Indikatoren für Dienstleister sammeln können. Einige Beispiele:

• Termintreue: % der Aufträge fristgerecht erledigt.

• Qualität: z.B. Anzahl Beanstandungen bei Reinigung, oder durchschnittliche Prüfpunktzahl in Qualitätskontrollen.

• Kosten: Budgettreue – bleiben sie im vereinbarten Kostenrahmen oder gibt es viele Nachträge?

• Reaktionszeit: Durchschnittszeit vom Meldung bis vor Ort (für Störungsdienste mit SLA).

• Bewertung und Feedback: Zusätzlich zu messbaren KPIs kann eine subjektive Bewertung gespeichert werden. Z.B. nach Vertragsende hinterlegt der FM-Leiter eine Bewertung (Noten, Sterne) für den Dienstleister. Man könnte auch bei jedem größeren Auftrag eine Feedbackeingabe machen („Arbeit gut ausgeführt?“). So entsteht über die Zeit ein Lieferantenrating im System, was bei künftigen Vergaben hilft (sofern vergaberechtlich zulässig, natürlich muss das sauber dokumentiert sein).

• Lieferantenentwicklung: Das System kann helfen, regelmäßige Gespräche und Audits zu tracken. Z.B. planmäßiges Lieferantengespräch einmal jährlich mit Firma X – als Termin hinterlegbar und Protokoll hochladen. Ebenso Nachhalten, ob vereinbarte Verbesserungsmaßnahmen umgesetzt wurden. So wird aus dem System ersichtlich, wie die Zusammenarbeit sich entwickelt (Kontinuität).

• Compliance und ESG bei Lieferanten: Heutzutage sehr relevant: man will wissen, ob die Lieferanten ESG-Kriterien erfüllen (Stichwort Lieferkettengesetz etc.). Das System sollte Felder haben wie „hat Code of Conduct unterschrieben“, „Umweltzertifikat liegt vor“, „Nachweis über Mindestlohn/Tarif“. Man könnte auch tracken, ob die Firmen z.B. regional ansässig sind (lokaler Beitrag) oder Diversitätskriterien erfüllen (z.B. Frauen-geführtes Unternehmen) – falls relevant. All das unterstützt die Governance in ESG. Bei einer Ausschreibung kann man dann z.B. anhand der Daten sehen, welche Anbieter bereits gewisse Nachhaltigkeitsstandards erfüllen. Im ESG-Report kann man angeben „XX% der FM-Lieferanten haben unseren Code of Conduct akzeptiert“ usw.

• Schnittstellen Beschaffung: Sollte die Hochschule ein zentrales Lieferantenmanagement oder ERP-Procurement nutzen, müsste man entscheiden, wie man die Daten abgleicht. Möglich, dass z.B. Stammdaten von Lieferanten aus SAP kommen, während FM-spezifische Bewertungen im CAFM liegen. Das System sollte Importe/Exporte der Basisdaten erlauben, um Doppelpflege zu minimieren.

Durch das Lieferanten- und Dienstleistermanagement erhält die Hochschule ein Werkzeug, um die externe Leistungserbringung im FM-Bereich transparent und steuerbar zu machen. Man kennt alle Dienstleister, ihre Verträge, ihre Leistungsfähigkeit und Zuverlässigkeit. Bei Problemen (schlechte Qualität, häufige Terminprobleme) kann man frühzeitig reagieren – das System liefert Fakten für Gespräche oder Entscheidungen (z.B. Anbieterwechsel). Gleichzeitig kann man positive Entwicklungen sehen und hat Daten an der Hand, um gute Dienstleister weiter zu binden. In Zeiten von ESG und strengeren Vergaberegeln kann das System helfen, nachhaltige Beschaffung nachzuweisen und zu fördern. Insgesamt professionalisiert dieses Modul das Lieferantenmanagement im FM, was letztlich zu besseren Services und oft auch Kosteneinsparungen führt.

• Performance: Das System muss auch bei umfangreichen Datenmengen zügig reagieren. Als Richtwert sollen typische Abfragen (z.B. Öffnen eines Raum-Stammdatensatzes, Liste aller Tickets eines Monats) in <2 Sekunden laden. Große Auswertungen oder Berichte <10 Sekunden. Bei zig gleichzeitigen Nutzern (z.B. 100 Studierende melden gleichzeitig eine Störung) darf das System nicht merklich langsamer werden.

• Skalierbarkeit: Wie umrissen, sollte die Architektur erweiterbar sein. Wenn sich Nutzerzahlen oder Datenumfang verdoppeln, darf das nicht zu Performanceeinbrüchen führen. Technisch sollte eine Skalierung möglich sein (horizontal via Webserver-Farmen oder vertikal via Hardwareupgrade). Für Cloudangebote: klar definieren, welches Größenlimit inbegriffen ist (z. B. X Datensätze, Y API-Calls).

• Datenvolumen: Das System muss viele Jahre Historie aufnehmen können. Es sollte nicht erforderlich sein, Daten auszulagern, um Performance zu halten – außer bei sehr alten, nicht mehr benötigten Transaktionen, wo ein Archivierungsmechanismus sinnvoll sein kann. Aber Kern: Wenig Einschränkungen bei Datengröße.

• Batch-Verarbeitung: Falls große Importe/Batchjobs laufen (z. B. täglicher Verbrauchsdatenimport), dürfen diese die Online-User-Performance nicht stören (daher evtl. nachts planen oder dedizierte Threads).

• Mobile Performance: Auch auf mobilen Geräten soll die Anwendung flüssig sein. Daher ggf. reduzierte Views oder lokale Zwischenspeicher für oft genutzte Daten.

• Test mit Echtdaten: Wir erwarten vom Anbieter einen Performancetest mit repräsentativen Daten in der Testphase, um obige Ziele zu verifizieren.

• Latenz & Echtzeit: Bei IoT-Echtzeitdaten muss das System in der Lage sein, eingehende Streams ohne große Verzögerung darzustellen (Sekundenbereich). Das ist vor allem relevant, wenn Live-Dashboards genutzt werden – Nutzer sollen nicht minutenlang auf Aktualisierung warten.

• Systemverfügbarkeit: Da das CAFM zentrale Prozesse steuert, wird eine hohe Verfügbarkeit angestrebt. Mindestens 99% im Jahresmittel (entspricht max ~3,65 Tage Downtime/Jahr). Kritische Zeiten (Mo–Fr 7–19 Uhr) sollten nahe 100% liegen. Etwaige Wartungsfenster sind bevorzugt nachts oder am Wochenende einzuplanen.

• Ausfallsicherheit: Bei On-Premises-Betrieb muss die IT-Infrastruktur redundant ausgelegt sein (Datenbank-Backups, Failover-Server). Bei Cloud-Betrieb erwarten wir vom Anbieter Informationen zur Hochverfügbarkeit (Cluster, georedundant?). Geplante Wartungen/Updates des SaaS dürfen den Betrieb nicht unangekündigt stören.

• Backup & Restore: Regelmäßige Backups müssen erstellt werden. Der Anbieter soll das Backup-Konzept darlegen: Frequenz, Aufbewahrungsdauer, Speichermedium, Verschlüsselung. Im Notfallfall muss eine Datenwiederherstellung innerhalb eines definierten Zeitrahmens möglich sein (z. B. <4 Stunden bis System wieder lauffähig mit Stand von max. 24h alt).

• Notfallbetrieb: Falls das System dennoch ausfällt, müssen Workarounds definiert sein (z. B. Tickets per E-Mail sammeln, manuelle Liste für kritische Wartungen etc.) – diese organisatorischen Maßnahmen liegen aber auf Hochschulseite. Das System sollte zumindest Datenexporte erlauben, um regelmäßig z.B. eine Notfall-Liste der wichtigsten offenen Vorgänge extern zu haben.

• Service Level: Sofern SaaS, erwarten wir im Vertrag definierte SLAs zur Verfügbarkeit (z. B. Pönalen bei <99%, etc.).

• Hersteller-Support: Der Anbieter soll qualifizierten Support gewährleisten. Mindestens während der Geschäftszeiten (z.B. 9–17 Uhr) muss ein Support erreichbar sein (Hotline/Helpdesk des Herstellers) für Störungsmeldungen der Software. Reaktionszeiten und mögliche Service Levels werden im Vertrag festgelegt. Kritische Fehler sollen innerhalb 24h bearbeitet werden.

• Updates und Weiterentwicklung: Es wird erwartet, dass die Software regelmäßig (mind. 1–2 mal jährlich) Updates/Patches erhält, welche Fehlerbehebungen und Verbesserungen bringen. Der Prozess für Updates (inkl. Teststellung, Einspielung in Produktivsystem) soll beschrieben sein. Bei Cloud erfolgt das meist zentral; bei On-Prem muss klar sein, wer Update einspielt. Wichtig: Abwärtskompatibilität der Daten und Konfiguration bei Updates.

• Innovations-Roadmap: Da die Hochschule ein zukunftsfähiges System möchte, interessiert uns die Roadmap des Herstellers. Welche größeren Features sind in Planung (z.B. KI-Integration, neue Module)? Wie stellt der Anbieter sicher, dass neue gesetzliche Anforderungen (z.B. geänderte ESG-Vorgaben) zeitnah im System unterstützt werden? Diese strategische Weiterentwicklung wird im Angebot erwartet.

• Anpassbarkeit und Customizing: Kleinere Konfigurationsänderungen (Felder hinzufügen, Bericht anpassen, Rechte ändern) sollten durch Administratoren der Hochschule selbst vorgenommen werden können. Für umfangreicheres Customizing (z.B. neue Workflows, spezielle Integrationen) sollte der Hersteller oder Partner Unterstützung bieten. Alle Anpassungen müssen updatefähig sein, d.h. Updates dürfen das Customizing nicht zerstören. Möglich wird das durch definierte Schnittstellen, Scripting-APIs oder Migrationswerkzeuge, die angepasste Formulare etc. bei Upgrades automatisch mitziehen.

• Dokumentation (für Wartung): Der Anbieter muss vollständige Dokumentationen liefern:

• Administrator-Handbuch (Installation, Konfiguration, Benutzer-/Rechtemanagement, Backup).

• Anwender-Dokumentation für Endnutzer der verschiedenen Module (ggf. Online-Hilfesystem integriert, kontextsensitive Hilfe).

• Technische Schnittstellen-Dokumentation (für die IT bei Integrationen, API-Doku).

• Schulungen: Im Zuge der Einführung werden vom Anbieter Schulungen erwartet. Aber auch darüber hinaus sollte es Trainingsangebote geben (für neue Mitarbeiter, neue Module). E-Learning-Angebote oder regelmäßige Webinare für Admins sind ein Plus.

• Community und Referenzen: Optional: Gibt es eine Anwender-Community (Forum, jährliches User-Treffen) oder einen regelmäßigen FM-Fach-Newsletter vom Hersteller? Dies wäre positiv, da man so von Erfahrungen anderer profitieren kann. Auch Referenzinstallationen an anderen Hochschulen wären interessant, um sich austauschen zu können.

• Gewährleistung: In der Anfangsphase (Gewährleistungszeit nach Abnahme) muss der Anbieter Mängel beheben. Hier gelten die üblichen Regelungen, die im Vertrag festgehalten werden, aber das Lastenheft betont, dass eine zuverlässige Mängelbeseitigung erwartet wird (inkl. angemessener Reaktionszeiten und keine unverhältnismäßigen Versuche).

• Schulungskonzept: Der Anbieter soll ein Schulungskonzept vorlegen, um die verschiedenen Nutzergruppen mit dem System vertraut zu machen. Dies umfasst z.B.:

• Key-User-Schulung für Facility-Manager und Administratoren (tiefergehende Ausbildung in allen Modulen, inkl. Konfiguration).

• Endanwender-Schulung für Service-Mitarbeiter (z.B. Helpdesk-Team, Haustechnik für App-Nutzung, Reinigungsleitung).

• Einfache Einweisungen für Self-Service-Nutzer (ggf. via E-Learning oder Kurzvideos, da hier intuitive Nutzung im Vordergrund steht).

• Trainingsumgebung: Es ist wünschenswert, dass ein Test- bzw. Schulungssystem bereitgestellt wird, auf dem die Nutzer gefahrlos üben können (z.B. separate Mandanten oder Datenbank mit Testdaten). So können sie Abläufe proben, ohne Echtdaten zu beeinflussen.

• Benutzerdokumentation: Verständliche Handbücher bzw. Online-Hilfen in deutscher Sprache müssen vorhanden sein. Sie sollten modular nach Funktionen gegliedert sein. Insbesondere für komplexe Module (Instandhaltung, Flächenplanung) braucht es Beispiele und Best-Practice-Hinweise. Online-Hilfe idealerweise direkt im System verlinkt (F1 für Hilfe zu aktueller Seite).

• Administratordokumentation: Enthält Installation, Backup, Benutzerverwaltung, Konfigurationsoptionen, Troubleshooting etc. Gerade bei On-Prem wichtig, aber auch bei SaaS sollte die Hochschule wissen, wie z.B. User angelegt werden, was zu tun ist bei bestimmten Fehlermeldungen etc.

• Updateschulungen: Bei großen neuen Releases sollte der Anbieter angeben, wie die Nutzer auf dem Laufenden gehalten werden (Release Notes, Webinare, ggf. Vor-Ort-Update-Workshops). Es muss gewährleistet sein, dass Neuerungen bekannt gemacht werden, damit sie genutzt werden können.

• Projektplan Einführung: Der Bieter muss nach Zuschlag einen detaillierten Implementierungsplan erstellen. Darin Meilensteine: Workshop zur Anforderungs-Feinjustierung, Installation/Provisionierung der Software, Konfiguration/Customizing, Schnittstellenentwicklung, Migration, Testphase, Schulungen, Produktivsetzung, Abnahme. Diese Phasen sollen zeitlich und inhaltlich geplant sein, mit Verantwortlichkeiten.

• Methodik: Erwartet wird, dass der Anbieter ein erfahrenes Projektteam stellt und eine bewährte Einführungsmethodik hat (z.B. agiles Vorgehen in Sprints vs. klassisch – je nach Komplexität). Wichtig ist, dass genügend Workshops für die Hochschul-spezifische Anpassung vorgesehen sind.

• Datenmigration: Es sind vorhandene Daten zu übernehmen. Der Anbieter soll darlegen, wie die Migration erfolgt und ggf. Tools/Mapper bereitstellen. Kritisch ist die Qualitätssicherung der migrierten Daten (Abgleich Alt/Neu). Möglicherweise wird ein Probeimport gemacht und validiert, bevor produktiv migriert wird. In der Übergangsphase muss klar sein, ob Doppelpflege nötig ist oder ein harter Cut.

• Schnittstellen-Inbetriebnahme: Falls integrative Schnittstellen zu SAP, AD, GLT etc. vorgesehen sind, müssen diese in der Implementierung getestet werden. Verantwortlichkeiten (wer liefert z.B. AD-Zugriff, wer programmiert evtl. Connectoren) sind früh zu klären.

• Customizing vs. Standard: Das Lastenheft ist umfangreich – der Bieter soll im Angebot kennzeichnen, was davon im Standard seines Produkts vorhanden ist und wo evtl. Anpassungen oder Erweiterungen nötig sind. Anpassungen sollen möglichst vermieden werden zugunsten vorhandener Funktionalität, um Risiken zu senken. Wo Anpassungen nötig sind, müssen sie klar beschrieben und kalkuliert werden. Wichtig: Alle Muss-Anforderungen müssen erfüllt werden – sei es im Standard, durch Customizing oder durch Drittsysteme.

• Test und Abnahme: Vor dem Live-Betrieb wird es eine Testphase geben, in der alle Module mit Echtdaten durchgespielt werden. Abnahmekriterien sind zu definieren (z.B. alle im Lastenheft aufgeführten Muss-Anforderungen erfüllt, keine kritischen Fehler, Performance ok). Ein Abnahmetestprotokoll wird erstellt. Eventuelle Mängel werden festgehalten und müssen bis zur Abnahme oder per Nachbesserung behoben werden.

• Go-Live Unterstützung: Der Anbieter sollte in den ersten Wochen des Produktivbetriebs verstärkten Support leisten (Hypercare), falls Probleme auftreten. Das kann Hotline-Bereitschaft oder vor Ort Unterstützung sein, je nach Vereinbarung.

• Übergang Alt-System: Falls bisher ein anderes System/Prozesse genutzt wurden, muss geklärt sein, wie der Übergang stattfindet. Gegebenenfalls Parallelbetrieb (kurzzeitig) oder Big Bang Umschaltung. Alle Beteiligten sind rechtzeitig zu informieren (Kommunikation, Change Management). Der Anbieter sollte aus Erfahrung Tipps geben (z. B. „erst klein starten mit Helpdesk-Modul, dann ausrollen“ falls das Sinn ergibt).

• Akzeptanz: Ein Risikofaktor bei neuen Systemen ist die Nutzerakzeptanz. Hier sollte der Implementierungspartner unterstützen, z.B. durch Key User Einbindung, Pilotgruppen, und Usability-Optimierungen auf Feedback. Schulung (4.4) spielt große Rolle, aber auch das Einplanen einer Pilotphase, in der man Feinjustierungen machen kann, ist empfohlen.

• Technologische Weiterentwicklung: Die Hochschule erwartet, dass das eingeführte System über viele Jahre nutzbar bleibt und mit Technologiewechseln Schritt hält. Der Anbieter soll eine Strategie aufzeigen, wie neue Trends ins Produkt einfließen (z.B. KI, AR/VR für Gebäude, Digitalisierung von Prozessen). Gibt es einen festen Investitionsplan in R&D? Wie werden Kundenwünsche gesammelt und umgesetzt (User Group, regelmäßige Releases)?

• Erweiterbarkeit: Sollte in Zukunft ein weiteres Modul benötigt werden (z. B. Carsharing-Management, Kantinenmanagement, Smart-Campus-Ideen), muss das System dies modulartig erweitern können oder zumindest über Schnittstellen integrieren. Die Softwarearchitektur muss also offen sein – keine Sackgasse, sondern Plattform-Gedanke. Falls der Anbieter selbst solche Module anbietet, ist es gut zu wissen, was optional verfügbar wäre.

• Integrationsfähigkeit: Der Campus der Zukunft ist hochvernetzt. Das CAFM muss sich in ein Ökosystem einfügen können, z.B. in eine Smart Campus Platform der Hochschule oder Stadt. Das heißt, es sollte Standards unterstützen (siehe OpenAPI, MQTT, etc.) und Daten sowohl konsumieren als auch liefern können. Die Vision ist, dass Facility-Daten, IT-Daten, Nutzer-Feedback, IoT-Sensorik etc. zusammenkommen. Das CAFM soll hierzu einen wesentlichen Beitrag leisten, aber auch neben anderen Systemen bestehen können (Koexistenz mit IoT-Platform, Building Management System, Smart City Dashboards). Dies erfordert Interoperabilität, auf die der Anbieter verpflichtet wird.

• Support für Innovationen der Hochschule: Wenn die Hochschule eigene Entwicklungen machen will (z. B. eine Campus-App entwickeln und ans CAFM andocken, oder ein Data Analytics Projekt auf FM-Daten), sollte der Anbieter das fördern (durch offene Datenzugänge) und nicht behindern (proprietäre Formate, hohe Zusatzkosten für API). Idealerweise gibt es Referenzen, wo ein Kunde kreativ angebunden hat – solche Use Cases würden uns Zuversicht geben.

• Anpassung an gesetzliche Änderungen: In Bereichen wie Arbeitsschutz, Energiegesetzgebung, Datenschutz kann es Änderungen geben, die das System betreffen. Der Anbieter muss gewährleisten, dass er solche Änderungen rechtzeitig in der Software berücksichtigt (z. B. wenn eine neue Prüfverordnung kommt, wird ein Update bereitgestellt, das diese als Vorlage enthält).

• Langfristige Partnerschaft: Die Auswahl eines CAFM ist eine langfristige Entscheidung. Die Hochschule wünscht sich einen Anbieter, der auch in 10+ Jahren noch verlässlich am Markt ist und das Produkt pflegt. Daher werden auch Unternehmenskennzahlen und Strategien bewertet. Ein Commitment zur Weiterentwicklung des IWMS/CAFM und Referenzen, die das Vertrauen stützen, sind hilfreich.

(Dies ist kein klassischer Bestandteil eines Lastenhefts, aber wir möchten hier klarstellen, dass wir nicht nur aktuelle Anforderungen betrachten, sondern auch die Zukunft im Blick haben. Anbieter sollten darauf eingehen, wie sie diese Zukunftsfähigkeit sicherstellen.)