CAFM-System: Suchfunktionen, Reportgeneratoren, Dashboards und Management-Cockpits

Soll: Das System soll einen benutzerfreundlichen Reportgenerator bereitstellen, mit dem autorisierte Anwender ohne Programmieraufwand individuelle Berichte erstellen können (z. B. per Drag-&-Drop von Feldern oder auf Basis vordefinierter Vorlagen). Abnahmeprüfung: Ein Fachanwender erstellt im Test innerhalb von 10 Minuten einen einfachen Bericht nach Vorgabe (inkl. Feldauswahl und Layout) mittels der grafischen Oberfläche, ohne Hilfe eines Entwicklers. Der erzeugte Bericht entspricht der Vorgabe.

Muss: Die Berichtsfunktion muss Filterkriterien, Gruppierungen, Aggregationen und Zeitreihen unterstützen, um flexible Auswertungen zu ermöglichen. Berichte müssen nach verschiedenen Kriterien eingeschränkt und z. B. nach Organisationseinheiten oder Zeitintervallen gegliedert werden können (einschließlich Summenbildung, Durchschnittswerte über Zeiträume etc.). Abnahmeprüfung: Im Test wird ein Bericht erstellt, der Wartungskosten pro Quartal und pro Gebäude gruppiert ausgibt. Der Reportgenerator ermöglicht die Einstellung entsprechender Filter (Zeitraum Q1–Q4) und Gruppierung (Gebäude); der ausgegebene Bericht zeigt die korrekten gruppierten Summen je Quartal und Gebäude.

Muss: Die Software muss Berichte in gängigen Exportformaten ausgeben können. Mindestens die Formate PDF, MS Excel und CSV sind Pflicht; ein Export als XML ist wünschenswert (Kann). Abnahmeprüfung: Ein Testbericht wird über die Anwendung exportiert. Es werden erfolgreich eine PDF-Datei, eine Excel-Tabelle und eine CSV-Datei generiert, welche in externen Programmen geöffnet werden können und die korrekten Inhalte (Layout, Zahlen, Umlaute) enthalten. (Falls vom Bieter angeboten, wird auch ein XML-Export getestet und auf korrekte Struktur geprüft.)

Soll: Der Reportgenerator soll eine zeitgesteuerte Ausführung von Berichten ermöglichen. Nutzer sollen definieren können, dass bestimmte Berichte automatisch in festgelegten Intervallen generiert und versendet werden (z. B. ein Monatsbericht, der jeweils am 1. des Folgemonats per E-Mail an definierte Empfänger versendet wird). Abnahmeprüfung: Im Test wird ein Bericht so geplant, dass er innerhalb von 5 Minuten nach Teststart automatisch erzeugt und per E-Mail zugestellt wird. Es wird geprüft, dass die E-Mail mit dem aktuellen Bericht im PDF-Format beim vorgesehenen Empfänger ankommt.

Muss: Berichte müssen rollenbasiert sichtbar sein. Das System muss sicherstellen, dass Benutzer nur diejenigen Berichte einsehen oder erzeugen können, die für ihre Rolle freigegeben sind. Ebenso dürfen in einem Bericht nur Daten erscheinen, die der jeweilige Nutzer sehen darf (Rechtefilterung bis auf Feldebene). Abnahmeprüfung: Ein Bericht mit vertraulichen Kennzahlen (z. B. Kosten) wird einmal als Administrator und einmal als normaler Mitarbeiter aufgerufen. Beim Administrator werden alle Daten angezeigt, beim Mitarbeiter sind die vertraulichen Felder ausgeblendet oder der Bericht gar nicht erst zugreifbar. Jede unautorisierte Einsicht führt zum Nichtbestehen der Prüfung.

Soll: Die Software soll Kennzahlen in Dashboards rollenspezifisch sowie nach Mandant oder Organisationseinheit differenziert anzeigen können. Jede Nutzergruppe (z. B. Techniker, Facility-Manager, Geschäftsführung) soll ein auf ihre Bedürfnisse zugeschnittenes Management-Cockpit mit den relevanten KPIs erhalten. Abnahmeprüfung: Es werden Testnutzer mit unterschiedlichen Rollen erstellt (z. B. Techniker, Manager verschiedener Abteilungen). Nach dem Login sieht jeder Nutzer ein anderes Dashboard mit Kennzahlen, die jeweils seinem Verantwortungsbereich entsprechen (z. B. der Technik-Leiter sieht Wartungs- und Störungskennzahlen seiner Anlagen, der Finanzcontroller sieht Kostenkennzahlen). Kein Nutzer sieht Kennzahlen fremder Bereiche.

Soll: Das System soll konfigurierbare Dashboards bereitstellen, in denen sich Nutzer mittels Widgets ihre gewünschte Übersicht selbst zusammenstellen können. Es muss möglich sein, verschiedene Widgets (z. B. Diagramme, Kennzahl-Kacheln, Listen) per Konfiguration hinzuzufügen, anzuordnen und bei Bedarf zu entfernen. Abnahmeprüfung: Ein Testanwender passt sein Dashboard an, indem er ein zusätzliches Kennzahlen-Widget hinzufügt und die Position eines Diagramms per Drag-&-Drop verändert. Die Änderungen werden gespeichert und bleiben auch nach erneutem Anmelden bestehen. Das neue Widget zeigt korrekte Daten gemäß der Konfiguration.

Soll: Dashboards sollen interaktive Drill-Down-Funktionen bieten. Der Benutzer muss von aggregierten Kennzahlen oder Diagrammen im Management-Cockpit auf die zugrundeliegenden Detaildaten springen können (z. B. Klick auf die KPI "offene Tickets" öffnet eine Liste der offenen Tickets). Abnahmeprüfung: Im Dashboard klickt der Tester auf ein Balkendiagramm, das die Anzahl der offenen Wartungsaufträge pro Monat zeigt. Daraufhin öffnet das System eine Detailanzeige bzw. Liste, in der alle einzelnen Wartungsaufträge des gewählten Monats aufgeführt sind. Es wird überprüft, dass die Detaildaten mit der angeklickten Kennzahl übereinstimmen.

Soll: Das System soll vielfältige Visualisierungsmöglichkeiten für Kennzahlen anbieten. Dazu gehören mindestens verschiedene Diagrammtypen (z. B. Balken-, Linien-, Torten- oder Donutdiagramme), Tabellen sowie ggf. Heatmaps oder Ampel-/Ampelsysteme zur Darstellung von Zuständen. Dies ermöglicht eine anschauliche Präsentation der FM-Kennzahlen im Dashboard. Abnahmeprüfung: Der Anbieter stellt im Test mehrere Widget-Typen bereit. Der Prüfer fügt je ein Beispiel für ein Balkendiagramm, ein Tortendiagramm und eine Tabelle in ein Dashboard ein. Alle Widget-Typen werden korrekt gerendert und zeigen sinnvolle Beispielwerte. Unterschiedliche Diagrammtypen lassen sich mit konfigurierbaren Datenquellen belegen.

Soll: Die Dashboard-Oberfläche soll ein responsives Design aufweisen, sodass sie auch auf mobilen Endgeräten (Tablet, Smartphone) nutzbar ist. Bei Verkleinerung des Bildschirms müssen sich die Widgets automatisch anpassen (z. B. Umlagerung untereinander), ohne dass Funktionalität oder Lesbarkeit leiden. Abnahmeprüfung: Das Dashboard wird nacheinander auf einem Desktop-Browser, einem Tablet und einem Smartphone (oder simulierten Ansichten) aufgerufen. Es wird bestätigt, dass alle Elemente auch auf kleineren Bildschirmen übersichtlich dargestellt werden (kein horizontales Scrollen nötig, Texte lesbar, Bedienelemente klickbar).

Muss: Die Anwendung muss auch bei großen Datenmengen eine hohe Performance gewährleisten. Typische Benutzeraktionen wie Suchen, Filtern, Laden von Berichten oder Dashboards sollen selbst bei sehr umfangreichen Datenbeständen (z. B. >100.000 Datensätze) in akzeptabler Antwortzeit erfolgen. Abnahmeprüfung: In einem Lasttest werden z. B. 100.000 Datensätze in relevanten Modulen (Tickets, Anlagen, Flächen etc.) erzeugt. Anschließend wird gemessen, dass eine Standardsuche oder das Öffnen eines Dashboard nicht länger als ~5 Sekunden dauert. Überschreiten die Antwortzeiten deutlich den vorgegebenen Wert, gilt die Anforderung als nicht erfüllt.

Muss: Das System muss mandantenfähig sein und eine strikte Rollentrennung auch in Auswertungen sicherstellen. Daten unterschiedlicher Mandanten (z. B. verschiedener Konzernteile oder Kunden) sind logisch getrennt zu verwalten. Außerdem darf ein Benutzer nur die Daten und Berichte seines eigenen Mandanten bzw. entsprechend seiner Rolle sehen (keine bereichsübergreifende Einsicht). Abnahmeprüfung: Es werden zwei Mandanten (A und B) mit je einem Testdatensatz angelegt. Ein Benutzer aus Mandant A versucht, Daten oder Berichte von Mandant B aufzurufen – der Zugriff muss vom System unterbunden werden (keine Ergebnisse bzw. Fehlermeldung). Ebenso wird geprüft, dass ein Mandant-Admin nur die Nutzer und Einstellungen seines Mandanten administrieren kann.

Soll: Die Lösung soll eine hohe Aktualität der Daten sicherstellen. Idealerweise werden Auswertungen mit Echtzeit-Daten bzw. sehr zeitnah aktualisierten Daten befüllt. Falls an gewissen Stellen mit Stichtagsdaten (Datenstand zu einem bestimmten Zeitpunkt) gearbeitet wird – etwa bei Monatsreports oder eingefrorenen Planungsständen – muss dieser Status deutlich gekennzeichnet sein (inkl. Timestamp des Datenstands). Abnahmeprüfung: In der Demonstration wird ein Datensatz (z. B. Raumfläche) geändert. Anschließend wird ein Bericht bzw. Dashboard-KPI abgerufen, der diese Daten nutzt. Es ist ersichtlich, dass der geänderte Wert unmittelbar (spätestens nach kurzem Aktualisierungsintervall) übernommen wurde. Bei geplanten Stichtagsberichten wird im Report der Stand (Datum/Uhrzeit der Daten) angezeigt und entspricht dem erwarteten Stichtag.

Muss: Es sind hohe Sicherheitsstandards bei Auswertungen einzuhalten. Das System muss vor der Ausgabe jeder Suche, jedes Berichts oder Dashboards die Berechtigungen des Benutzers prüfen, sodass keine unautorisierten Daten offengelegt werden. Auch bei Exporten (PDF, Excel etc.) dürfen nur erlaubte Inhalte enthalten sein. Abnahmeprüfung: Ein Benutzer ohne Administrationsrechte versucht, einen Bericht aufzurufen, der eigentlich nur für Administratoren vorgesehen ist. Das System verweigert den Zugriff oder zeigt einen leeren/angepassten Bericht ohne die geschützten Inhalte. Zusätzlich wird kontrolliert, dass ein Export desselben Berichts ebenfalls keinen Verstoß gegen Berechtigungen zulässt (z. B. keine ausgeblendeten Daten im Export enthalten sind).