CAFM: Anforderungserhebung (funktional & nichtfunktional)

• Interviews (Einzel- oder Gruppeninterviews): Im direkten Gespräch mit verschiedenen Stakeholdern (z. B. Objektmanagern, Servicetechnikern, Controllern, IT-Administratoren) werden deren Aufgaben, Probleme und Wünsche erfragt. Interviews ermöglichen es, detailliert auf individuelle Anforderungen einzugehen und Hintergründe zu verstehen. Es sollten strukturierte Leitfäden verwendet werden, um alle relevanten Aspekte abzudecken. Beispiel: In einem Interview mit dem Instandhaltungsleiter wird ermittelt, welche Informationen er für die Wartungsplanung benötigt und welche Berichte aktuell fehlen. Vorteil: Interviews liefern tiefgehende Einblicke und können Missverständnisse sofort klären. Praxis-Tipp: Zur Vorbereitung bietet es sich an, vorhandene Prozessdokumentationen oder Pain Points zu sammeln, damit gezielt nachgehakt werden kann.

• Workshops: Workshops bringen mehrere Stakeholdergruppen zusammen, um Anforderungen gemeinsam zu erarbeiten. Sie sind ideal, um Prozesse abteilungsübergreifend zu betrachten und ein gemeinsames Verständnis zu schaffen. Beispielsweise kann ein Workshop durchgeführt werden, in dem der Soll-Prozess der Störmeldungsbearbeitung am Whiteboard skizziert wird – mit Teilnehmern aus der FM-Organisation, der IT und dem Nutzerkreis. In Prozess-Workshops werden aktuelle Abläufe visualisiert, Schwachstellen identifiziert und gemeinsam Verbesserungsanforderungen formuliert. Workshops fördern die Akzeptanz, da die Beteiligten sich früh einbringen können. Zugleich helfen sie, widersprüchliche Sichtweisen aufzudecken und zu harmonisieren. Wichtig ist eine neutrale Moderation und eine klare Zielsetzung je Workshop. Praxis-Tipp: Gerade Fit/Gap-Workshops sind in CAFM-Projekten nützlich, wenn bereits ein Vorgängersystem existiert oder ein bestimmtes Produkt im Blick ist – dabei wird in Gruppenarbeit überprüft, welche Anforderungen durch Standardfunktionen abgedeckt sind (Fit) und wo Lücken (Gap) bestehen, die besondere Aufmerksamkeit erfordern.

• Fragebögen/Umfragen: Standardisierte Fragebögen können eingesetzt werden, um von einer größeren Anzahl von Beteiligten strukturiert Anforderungen einzusammeln. Dies eignet sich z. B. bei verteilten Organisationen oder wenn viele Endanwender einbezogen werden sollen (etwa alle Hausmeister oder alle Sekretariate). Ein Fragebogen könnte typische Anforderungen auflisten (Checkboxen, Ratings) und Freitextfelder für zusätzliche Wünsche bieten. Die Auswertung zeigt Trends und Mehrheiten. Vorteil: Hohe Reichweite und Vergleichbarkeit der Antworten. Nachteil: Wenig Tiefgang – komplexe Anforderungen oder implizite Bedürfnisse kommen evtl. nicht zur Sprache. Daher sollten Umfragen immer in Kombination mit Interviews/Workshops genutzt werden.

• Use Cases (Anwendungsszenarien): Die Beschreibung von Use Cases ist eine methodische Vorgehensweise, bei der Anforderungen in Form konkreter Nutzungsszenarien formuliert werden. Ein Use Case beschreibt, wie ein Nutzer mit dem System ein bestimmtes Ziel erreicht. Beispiel: „Techniker meldet einen Schaden vor Ort über das mobile CAFM und löst damit einen Workflow zur Reparatur aus.“ Durch solche Anwendungsfälle werden die funktionalen Anforderungen im Kontext deutlich. Use Cases helfen, Prozesse Ende-zu-Ende zu denken und fehlende Systemfunktionen zu identifizieren. Studien zeigen, dass die Entwicklung von Use Cases sehr hilfreich ist, um Prozesse zu erfassen und Anforderungen klar zu definieren. In der Praxis können Use Cases textuell beschrieben oder mit UML/Use-Case-Diagrammen dargestellt werden. Für CAFM empfehlen sich Use Cases z. B. für wiederkehrende Kernprozesse wie „Raumbuchung durchführen“, „Wartungsauftrag abwickeln“ oder „Mietvertrag ändern“. Jeder Use Case liefert eine Reihe konkreter Anforderungen (Schritte, Ausnahmen, benötigte Daten etc.).

• Fit/Gap-Analyse: Diese Methode kommt besonders dann zum Einsatz, wenn bereits eine Software vorausgewählt ist (oder ein bestehendes System abgelöst werden soll). Alle identifizierten Anforderungen werden dabei gegen die Funktionen der bestehenden (oder favorisierten) Lösung gehalten, um zu prüfen, wo es Übereinstimmungen (Fits) gibt und wo Abweichungen (Gaps) auftreten. Ziel ist es, frühzeitig mögliche Lücken aufzudecken: z. B. kann das favorisierte System alle gewünschten Module abdecken, bietet es die benötigten Schnittstellen, erfüllt es die Sicherheitsvorgaben? Wo Lücken identifiziert werden, müssen Gap-Lösungen definiert werden – das können Zusatzentwicklungen, Workarounds oder Prozessänderungen sein. Eine Fit/Gap-Analyse unterstützt somit die Entscheidungsfindung, ob eine Software geeignet ist, und informiert den Implementierungsplan (zusätzlicher Aufwand für Customizing, Integrationen etc. einplanen). Praxisbeispiel: Ein Krankenhaus prüft in einer Fit/Gap-Matrix, welche Anforderungen des technischen Gebäudemanagements durch ein IWMS-Standardprodukt erfüllt werden. Dabei zeigt sich z. B., dass das Modul für Medizinprodukte-Management fehlt (Gap) – das muss entweder anders gelöst oder als Kriterium in der Ausschreibung hervorgehoben werden.

• Benchmarking: Beim Benchmarking vergleicht man entweder das eigene Vorgehen oder die angedachten Anforderungen mit Best Practices und Branchenstandards. Im FM-Umfeld kann Benchmarking zweierlei bedeuten: Prozess-Benchmarking (Vergleich von KPIs und Abläufen mit anderen Unternehmen) oder System-Benchmarking (Vergleich von Software-Funktionalitäten). Für die Anforderungserhebung ist insbesondere letzteres relevant: Man orientiert sich an dem, was führende CAFM-Systeme bieten, und was andere Organisationen erfolgreich nutzen. So lassen sich einerseits Lücken in den eigenen Anforderungen erkennen (habe ich an alle wichtigen Features gedacht?) und andererseits Ambitionsniveau und Zielwerte setzen. Branchenverbände und Studien liefern hierfür Anhaltspunkte. Beispielsweise kann man durch Benchmarking feststellen, dass im Durchschnitt vergleichbarer Unternehmen ein Helpdesk-Modul standardmäßig eingeführt wird – dies könnte das eigene Lastenheft beeinflussen. Oder man erkennt, dass bestimmte Kennzahlen (Cost per Space, Reaktionszeiten) in anderen Organisationen besser sind, und leitet daraus Anforderungen an Reporting und Prozesse ab. Benchmarking identifiziert Verbesserungspotenzial und stellt sicher, dass das Projekt die State-of-the-Art-Anforderungen berücksichtigt. Hinweis: Benchmarking-Daten müssen sorgfältig interpretiert werden – Unterschiede in Organisation und Größe sind zu berücksichtigen, damit man nicht Äpfel mit Birnen vergleicht.

Ein CAFM-Projekt betrifft viele Abteilungen und Personen – entsprechend muss die Anforderungserhebung alle relevanten Stakeholder einbinden.

• FM-Fachbereiche: Die verschiedenen Bereiche des Facility Management (Technisches FM, Infrastrukturelles FM, Kaufmännisches FM, ggf. Spezialbereiche wie Labor- oder Medizintechnik) liefern die inhaltlichen Anforderungen. Ihre Experten wissen, welche Funktionen im Tagesgeschäft benötigt werden (z. B. Wartungsplanung, Reinigungsrunden, Flächenauswertung). Vertreter dieser Bereiche – vom Head of FM bis zu operativen Mitarbeitern – sollten eingebunden sein, um praxisnahe Anforderungen zu formulieren. Oft werden pro Fachbereich Key-User benannt, die die Anforderungen ihrer Domäne zusammentragen.

• IT-Abteilung (IT/IKT): Die Unternehmens-IT ist ein essenzieller Stakeholder für technische und integrative Anforderungen. Sie definiert Vorgaben zur Systemarchitektur, Infrastruktur, Sicherheit und Schnittstellen. IT-Architekten oder IT-Projektmanager stellen sicher, dass das CAFM-System in die bestehende IT-Landschaft passt (Themen: Datenbank- und Serverumgebung, Betriebssysteme, Cloud-Policy, Netzwerk, Firewall, Authentifizierung etc.). Sie bringen auch Erfahrung in Integrationsprojekten ein (z. B. Kopplung an SAP, Active Directory, Gebäudeleittechnik) und achten darauf, dass entsprechende Anforderungen (z. B. „Schnittstelle zu SAP PM zur Auftragsübergabe“) korrekt definiert werden. Die IT hat zudem die Perspektive des künftigen Betriebs: Sie wird das System evtl. betreuen müssen (Updates, Support), daher sind Betriebsvorgaben ebenfalls Teil der Anforderungen (z. B. „Muss auf virtuellen Servern unter Linux laufen“, „Datenbank bevorzugt MS SQL Server“).

• Compliance und Recht/Datenschutz: Im Facility Management spielen eine Reihe von gesetzlichen und normativen Anforderungen eine Rolle. Daher sollten Spezialisten für Compliance, Recht und Arbeitsschutz in die Anforderungsdefinition einbezogen werden, um regulatorische Anforderungen einzubringen. Beispiele: ein Datenschutzbeauftragter achtet darauf, dass Anforderungen gemäß DSGVO gestellt werden (Datenminimierung, Auskunftsrechte, Löschfristen). Der Arbeitssicherheits- oder Betreiberverantwortungs-Beauftragte stellt sicher, dass das System Funktionen bietet, um Betreiberpflichten zu erfüllen (Wartungsfristen einhalten, Prüfbuch führen, Unterweisungen dokumentieren). Weiterhin könnten Qualitätsmanager oder Energiebeauftragte Anforderungen beisteuern (z. B. ISO-50001-konformes Energiemanagement, Nachhaltigkeits-KPIs für ESG-Reporting). Normen und Richtlinien (DIN, VDI) sollten durch diese Experten in Anforderungen übersetzt werden.

• Nutzervertretung (Betriebsrat & Endanwender): Da ein CAFM-System tief in Prozesse eingreift, ist es wichtig, die Perspektive der Endnutzer und der Arbeitnehmervertretung zu berücksichtigen. Endanwender-Vertreter (z. B. Hausmeister-Teamleiter, Sachbearbeiter, Sekretariat) können praktische Anforderungen an die Usability und Funktionalität beitragen – sie wissen, welche Arbeitsschritte am dringendsten verbessert werden müssen. Vor allem aber muss, sofern das System Mitarbeiterdaten erfasst oder Leistung transparent macht, der Betriebsrat nach §87 Abs.1 Nr.6 BetrVG einbezogen werden. CAFM-Systeme protokollieren z. T. Zutritte, Arbeitszeiten (Störmelde-Bearbeitungszeiten) oder Raumnutzungen, was zur Überwachung von Mitarbeitenden geeignet sein könnte. Daher sind früh Betriebsvereinbarungen oder Regelungen zu treffen, welche Daten erfasst werden und wie diese verwendet werden. Die Mitbestimmung stellt sicher, dass das System sozialverträglich eingeführt wird und die Akzeptanz der Belegschaft erhält. Praxis-Tipp: Transparenz gegenüber den Nutzern und Schulungsangebote erhöhen die Bereitschaft, das neue System zu nutzen. Involvieren Sie „kritische Geister“ bewusst früh (z. B. in Workshops), um Vorbehalte abzubauen.

• Management und Budgetverantwortliche: Die Führungsebene (z. B. FM-Leitung, CFO für Budgetthemen, CIO für IT-Strategie) sollte in Meilenstein-Workshops eingebunden sein, um die Prioritäten und strategischen Leitplanken vorzugeben. Sie entscheidet oft, welche Anforderungen Must-haves sind (weil geschäftskritisch) und wo Kompromisse möglich sind. Auch für die Freigabe des Lastenhefts und später die Entscheidung bei Zielkonflikten ist ein Lenkungsgremium im Boot zu haben. Das Management formuliert zudem die übergeordneten Ziele (z. B. Kostensenkung vs. Serviceverbesserung) und legt fest, welche Erfolgskriterien erreicht werden sollen. Diese Vorgaben leiten die Priorisierung der Anforderungen maßgeblich.

• Externe Berater oder Dienstleister: Gegebenenfalls wird ein CAFM-Berater hinzugezogen, der den Anforderungsprozess moderiert und Best Practices einbringt. Er kann als neutraler Moderator zwischen den Interessen vermitteln und hat Erfahrung aus anderen CAFM-Projekten, um z. B. unrealistische Forderungen direkt aufzuzeigen. Ein Berater achtet darauf, dass Anforderungen vollständig und marktkonform sind – das erhöht die Qualität der Ausschreibung und verhindert Fehlkäufe. Wichtig: Auch die beste externe Beratung ersetzt nicht die Einbindung der internen Wissensträger; ideal ist ein gemeinsames Team.

Die Erhebung der Anforderungen sollte als interdisziplinäres Projekt aufgesetzt sein. Ein gemischtes Projektteam – bestehend aus FM-Fachleuten, IT-Architekten, Endanwender-Vertretern und ggf. Beratern – hat sich bewährt. Klare Rollen (wer sammelt fachliche Anforderungen, wer technische, wer moderiert?) vermeiden Lücken und Doppelarbeit. Alle Beteiligten müssen ausreichend Zeit für Workshops und Reviews bekommen. Wichtig ist, mögliche Konflikte im Team offen anzusprechen (z. B. wenn Fachbereich X eine komplexe Sonderlösung will, IT aber aus Wartbarkeitsgründen Standardisierung fordert). Hier hilft es, auf das gemeinsame Projektziel zu verweisen und notfalls Management-Entscheidungen einzuholen. Insgesamt führt eine breite Stakeholder-Einbindung zu höherer Qualität der Anforderungen und fördert die spätere Akzeptanz im gesamten Unternehmen.

Gerade bei umfangreichen CAFM-Projekten entstehen leicht Hunderte von Einzelanforderungen. Diese müssen sinnvoll gegliedert werden, damit Überblick und Nachverfolgbarkeit gewährleistet bleiben.

• Gliederung nach Funktionsbereichen/Modulen: Hier werden Anforderungen entsprechend den typischen CAFM-Leistungsbausteinen gruppiert. So könnte das Lastenheft Kapitel enthalten wie Flächenmanagement, Instandhaltung, Reinigungsmanagement, Vertragsmanagement usw., in denen jeweils die spezifischen Anforderungen aufgeführt sind. Diese Kategorisierung lehnt sich an den Aufbau vieler CAFM-Systeme an, die Module für die einzelnen Fachbereiche bieten. Unter der Überschrift „Instandhaltungsmanagement“ könnten Anforderungen stehen wie: „Wartungsplaner für wiederkehrende Prüfungen nach VDI 3810“, „Mangelmeldungen erfassen (mobil) mit Foto-Upload“, „Hinterlegung von Wartungsverträgen und Service-Level-Agreements“ etc.

• Gliederung nach Geschäftsprozessen: Alternativ (oder ergänzend) kann man die Anforderungen entlang der FM-Prozesse strukturieren. Dabei wird betrachtet, welche Soll-Prozessschritte das System unterstützen soll. Ein Prozessdiagramm der aktuellen und zukünftigen Abläufe kann als Basis dienen. Die Anforderungen werden dann pro Prozessschritt formuliert. Beispiel: Prozess „Störung beheben“ – Anforderungen: „Störungsmeldung erfassen (durch Nutzer oder Techniker)“, „automatische Prioritätszuweisung gemäß Kritikalität der betroffenen Anlage“, „Workorder-Generierung mit Zuordnung zum verantwortlichen Techniker“, „Rückmeldung und Abschluss mit Dokumentation der Maßnahme“. Diese Prozess-Perspektive stellt sicher, dass das System End-to-End-Unterstützung bietet und keine Lücke im Ablauf bleibt. Gerade bei der Integration in vorhandene Abläufe (z. B. Genehmigungsworkflows, Budgetfreigaben) ist die Prozessorientierung sinnvoll. Zudem fördert sie die Diskussion, ob bestehende Prozesse optimiert werden sollten, bevor sie digitalisiert werden (Stichwort „Kein schlechtes analoges Prozessdesign 1:1 digital abbilden“).

• Gliederung nach Benutzerrollen: Hier werden Anforderungen nach den anwendenden Rollen sortiert. Ein CAFM-System hat unterschiedliche Nutzergruppen – vom Servicetechniker über Objektleiter und Dienstleister bis hin zum Berichtsempfänger im Management. Es kann hilfreich sein, die Anforderungen pro Rolle zu sammeln, um sicherzustellen, dass die Bedürfnisse jeder Gruppe erfüllt sind. Zum Beispiel: „Anforderungen der Techniker (Außendienstmitarbeiter): mobile App, offline-Fähigkeit, einfache QR-Code-Scanner-Funktion für Anlagen“; „Anforderungen der Controller: flexibles Reporting, Export in Excel, KPI-Dashboard“; „Anforderungen der Gebäudenutzer: Self-Service für Raumbuchung, Meldung von Störungen per Web-Portal“. Diese Sichtweise verhindert, dass man eine wichtige Nutzerperspektive übersieht, und verdeutlicht, wo ggf. Zielkonflikte bestehen (z. B. zwischen einfacher Bedienung für Endnutzer und Funktionsvielfalt für Experten). In vielen Lastenheften werden Zielgruppen und Anwendungsfälle zu Beginn beschrieben, um den Kontext abzustecken – so verlangt es auch die DIN 69901 für Requirements Engineering. Eine klare Abgrenzung des Anwendungsbereichs und der Nutzergruppen hilft, Fehlentwicklungen am tatsächlichen Bedarf vorbei zu vermeiden.

• Gliederung nach Systemkomponenten/Schichten: In der IT ist es üblich, Anforderungen z. B. in Frontend, Backend, Schnittstellen, Daten etc. zu unterteilen. Im CAFM-Umfeld könnte man z. B. separate Abschnitte machen für Schnittstellenanforderungen, Daten- und Migrationsanforderungen, Berechtigungskonzepte usw.. Diese Kategorien betreffen meist nicht einzelne Fachprozesse, sondern querschnittliche Themen. Eine übliche Struktur (wie im Beispiel-Lastenheft oben angedeutet) wäre etwa: „Technische Anforderungen“, „Schnittstellen“, „Datenbasis/Migration“, „Betrieb und Support“ etc., neben den rein funktionalen Kapiteln. So hat es z. B. FM-Connect in einem Beispiel-Lastenheft gegliedert: funktionale Anforderungen und getrennt davon Schnittstellen, Datengrundlagen, Berichtswesen, Betrieb etc..

Ein bewährter Ansatz ist, das Lastenheft zunächst nach Themengebieten zu gliedern (z. B. Rechtliche Rahmenbedingungen, Organisatorische Ausgangslage, Technische Anforderungen, Funktionale Anforderungen nach Modulen, Schnittstellen, Datenmigration, etc.) und innerhalb z. B. der funktionalen Anforderungen nach Modulen oder Prozessen zu unterteilen. Wichtig ist, eine konsistente Struktur zu wählen, die zu Unternehmen und Projekt passt, und diese durch ein Inhaltsverzeichnis klar ersichtlich zu machen. So können die Leser (intern wie Anbieter) gezielt die für sie relevanten Abschnitte finden.

Eine systematische Kategorisierung erlaubt zudem eine zuverlässige Priorisierung und Nachverfolgbarkeit. Man kann z. B. Anforderungen in einer Tabelle durchnummerieren und den Kategorien zuordnen (Requirement-ID mit Präfix für Modul oder Prozess). In komplexen Projekten empfiehlt sich der Einsatz eines Requirements-Management-Tools, mit dem sich Hierarchien und Verknüpfungen abbilden lassen. Für kleinere Vorhaben reicht oft Excel, aber auch hier sollte man zumindest nach Muss/Kann und Themen gruppieren. Abschließend sei betont: Eine gute Struktur hilft auch bei der Kommunikation im Team – jeder weiß, wo sein Input im Dokument landet – und bei der Bewertung der Angebote (Anbieter können ihre Lösungen modulweise erläutern).

Die Anforderungen in CAFM-Projekten umfassen ein breites Spektrum – von fachlich-inhaltlichen Wünschen bis hin zu Rahmenbedingungen aus IT und Gesetzgebung.

• Technische Anforderungen: Darunter fallen Vorgaben zur IT-Architektur, Systemtechnik und Betrieb. Ein CAFM-System muss in die bestehende IT-Umgebung passen, daher sind Anforderungen bzgl. Betriebsmodell (Cloud vs. On-Premise), unterstützte Plattformen (Datenbanksystem, Betriebssysteme, Browser, mobile Geräte), Performance und Sicherheit typischerweise im Lastenheft. Beispiele: „Das System muss in der Microsoft Azure Cloud betreibbar sein“, „Unterstützte Browser: Chrome, Firefox in aktuellen Versionen“, „max. Seitenladezeit 3 Sek. im Intranet bei 500 gleichzeitigen Usern“. Ebenso gehört hierher das Benutzer- und Berechtigungskonzept: z. B. „Integration ins Single Sign-On via Active Directory“, „Feingranulares Rollen- und Rechte-System, das mindestens Leser/Editor/Admin unterscheidet“, „Audit-Trail für alle Datenänderungen“. Solche Anforderungen definieren die Grundarchitektur und Betriebsbedingungen. Sie müssen mit der internen IT abgestimmt sein, um spätere Konflikte zu vermeiden (etwa wenn Cloud-Lösungen wegen interner Policies ausgeschlossen sind). Unter technische Anforderungen fallen auch Wartbarkeit und Zukunftssicherheit des Systems („muss containerfähig sein“, „Hersteller garantiert langfristigen Support“, „Konfigurations- statt Programmierungsansatz zur Anpassung“). Im FM-Umfeld spielen zudem CAD/BIM-Integrationen eine Rolle (technisch: Unterstützung von DWG, IFC etc. – als nicht-funktionale Anforderungen ans System zu werten). Auch Leistungsmerkmale der Software wie Skalierbarkeit (z. B. „ausgelegt auf mindestens 1 Mio. m² verwaltbare Fläche und 100.000 Assets“) oder Verfügbarkeit (z. B. „Wartungsfenster nur außerhalb 18-6 Uhr, 99% Uptime SLA“) gehören dazu. Diese technischen Kriterien sichern, dass die Infrastruktur steht und das System zuverlässig läuft.

• Organisatorische Anforderungen: Sie ergeben sich aus der bestehenden Organisation und Prozessen des Unternehmens. Hier wird beschrieben, wie das System in der Organisation verankert wird. Dazu zählen z. B. Anforderungen an die Benutzeranzahl und -struktur (z. B. „ca. 50 gleichzeitige Nutzer, davon 10 Power-User in der Zentrale, restliche verteilte Standortnutzer“), an die Sprachversionen (mehrsprachige Oberfläche, falls international eingesetzt), an die Zugriffskonzepte (z. B. Mandantenfähigkeit, wenn verschiedene Tochtergesellschaften getrennte Datenbereiche haben sollen). Organisatorisch ist auch die Frage, welche Rollen das System nutzen und pflegen: „Es ist ein CAFM-Administrator zu benennen, der die Stammdatenpflege koordiniert“ (dies wäre eher eine Vorgabe im Einführungskonzept als eine Systemanforderung). Dennoch können solche Punkte ins Lastenheft einfließen, um dem Anbieter ein Bild vom Einsatz zu geben und Schulungsaufwände abzuschätzen. Weitere organisatorische Anforderungen können aus betriebsinternen Regelungen kommen: z. B. „Das System muss für externe Dienstleister zugänglich sein (z. B. Reinigungsfirma soll eigene Leistungen dokumentieren können)“ oder „Supportanfragen der Nutzer sollen über ein zentrales Service-Portal (ITSM-Tool) an den CAFM-Support geleitet werden“. Auch Change-Management-Maßnahmen (z. B. Schulungskonzepte) können als Anforderung festgehalten werden. Die organisatorische Ausgangslage (Anzahl Standorte, Aufteilung intern/extern, existierende Prozesse) ist im Lastenheft oft ein beschreibender Teil; daraus lassen sich aber ebenfalls Anforderungen ableiten, z. B. „muss 5 Standorte mit jeweils eigenen Gebäudekatastern abbilden können, aber konsolidierte Auswertungen erlauben“.

• Regulatorische und rechtliche Anforderungen: Facility Management unterliegt zahlreichen Gesetzen, Verordnungen und Normen, die durch das CAFM-System unterstützt oder zumindest nicht behindert werden dürfen. Im Lastenheft sollte explizit aufgeführt werden, welche rechtlichen Rahmenbedingungen relevant sind. Dazu zählen etwa: Betreiberpflichten (z. B. Prüfungen nach Arbeitsstättenverordnung, Technische Prüfverordnung – das System sollte Prüftermine überwachen und Dokumentationen revisionssicher speichern können), Datenschutz (DSGVO) – z. B. Anforderungen, dass personenbezogene Daten anonymisiert auswertbar sein müssen, dass es Rollen für Datenschutzbeauftragte gibt, oder Funktionen wie Consent-Banner bei Self-Service-Portalen. Weiter relevant: Arbeitsschutzvorschriften (VDI 3810, VDI 6022 etc. für technische Anlagen – das System sollte z. B. die Hygieneinspektionen für RLT-Anlagen nach VDI 6022 planen können), Baurecht und Brandschutz (Dokumentation von Fluchtwegen, Brandschutzeinrichtungen), Umweltvorgaben (z. B. Nachweisführung im Energiemanagement nach ISO 50001 oder Umweltmanagement nach ISO 14001). Branchenstandards wie DIN-Normen definieren teils Datenbegriffe: z. B. sollte ein Flächenmanagement-Modul die Flächen nach DIN 277 kategorisieren können; ein Kostenmanagement-Modul die Kosten nach DIN 18960 erfassen. Solche Normanforderungen (z. B. „Einhaltung DIN 276 Kostengliederung im Modul Budgetverwaltung“) erhöhen die Vergleichbarkeit und Compliance. Außerdem gibt es ISO 41011/41012/41013 für FM-Begriffe – ein modernes CAFM sollte diese möglichst abbilden. Regulatorische Anforderungen betreffen auch Dokumentationspflichten: etwa „alle prüfpflichtigen Anlagen müssen mit nächsten Prüfterminen und Prüfhistorie erfasst sein“ oder „Änderungen an sicherheitsrelevanten Daten (z. B. Zutrittsrechten) sind lückenlos zu protokollieren“. Solche Punkte sollten im Anforderungskatalog eindeutig beschrieben sein, da Compliance-Verstöße gravierende Folgen haben können (Haftung, Bußgelder).

• Integrationsanforderungen (Schnittstellen): Kaum ein CAFM-System arbeitet völlig autark – die Datenintegration mit bestehenden IT-Systemen ist oft erfolgskritisch. Daher gehört ins Lastenheft eine klare Liste der benötigten Schnittstellen. Typische Integrationen im FM sind: ERP-Systeme (v. a. SAP oder vergleichbar, für Stammdaten wie Kostenstellen, Anlagenbuchhaltung, Buchungen von Aufträgen, Rechnungsdaten), Personal- und Organisationsdaten (z. B. Anbindung ans HR-System oder Active Directory für Mitarbeiterdaten, Rechte), Finanzbuchhaltung (Übergabe von Kosten), Ticket-System/Helpdesk der IT (wenn FM-Störungen evtl. ins zentrale Ticketsystem überführt werden sollen), Gebäudeautomation (GLT/BMS) – hier vor allem das Auslesen von Zählerständen, Störmeldungen von Anlagen in Echtzeit ins CAFM, IoT-Sensoren (Raumbelegungssensorik, Umweltdaten – falls gewünscht, muss das System IoT-Daten über Standardprotokolle wie MQTT/API einlesen können), CAD- und BIM-Systeme – Anforderungen, CAD-Grundrisse importieren zu können, IFC-Modelle zu nutzen, und idealerweise bidirektional Daten auszutauschen (z. B. Flächenänderungen zurückspielen). Weitere mögliche Schnittstellen: Zutrittskontrollsysteme, Raumbuchungssysteme, CMMS für spezielle Bereiche, DMS (Dokumentenmanagement) etc. Zu jeder Schnittstelle sollte angegeben sein, welche Daten in welcher Richtung ausgetauscht werden und in welcher Frequenz (Echtzeit, täglich, manuell bei Bedarf). Ebenso wichtig: Technologie der Schnittstelle – wird eine offene RESTful API gefordert, sind bestimmte Dateiformate (CSV, XML) zu unterstützen, gibt es Standardprotokolle (BACnet, OPC UA für Gebäudeautomation)? Eine Anforderung könnte lauten: „Offene Schnittstellen: Das System muss eine REST-API zur Verfügung stellen, über die Stammdaten und Bewegungsdaten CRUD-fähig sind“ oder „Import/Export von Daten auch per Excel muss für Administratoren möglich sein“. Schnittstellenanforderungen sorgen dafür, dass das CAFM nahtlos ins bestehende Informationssystem eingebettet wird. Doppel-Erfassungen sollen vermieden werden, z. B. „Personalstammdaten werden führend im HR-System gepflegt und über Schnittstelle X täglich ins CAFM übernommen“. Dies entlastet Benutzer und erhöht die Datenqualität. Im Lastenheft sollte priorisiert werden, welche Schnittstellen zwingend zum Go-Live fertig sein müssen und welche später folgen können. Auch Zuständigkeiten (wer entwickelt die Schnittstelle – Anbieter oder intern?) und vorhandene Schnittstellen-Tools können erwähnt werden.

Zusätzlich zu diesen vier Hauptkategorien können je nach Projekt weitere Querschnitts-Anforderungen auftreten, z. B. Sicherheitsanforderungen (etwa besondere Zugriffsschutz- oder Verschlüsselungsanforderungen, wenn hochsensible Daten wie Sicherheitspläne verarbeitet werden), Berichtswesen/KPI-Anforderungen (Definition, welche Kennzahlen das System auf Knopfdruck liefern soll – z. B. Flächenausnutzungsgrad, Top 10 Störgründe etc.), oder Performance und Umfang (wenn extreme Größenordnung, z. B. „Verwaltung von 1000 Gebäuden und 1 Mio. Dokumenten muss performant möglich sein“). Diese sollten jeweils sauber den Oberkategorien zugeordnet oder separat aufgeführt werden.

Wichtig ist, jedes Requirement mit einem Attribut für die Kategorie zu versehen, damit beim Prüfen der Vollständigkeit nichts übersehen wird. Viele Lastenhefte arbeiten mit Kapiteln für funktionale und nicht-funktionale Anforderungen. Dabei werden technische, organisatorische, regulatorische und Integrationsaspekte oft unter „nicht-funktional“ zusammengefasst, oder noch weiter differenziert (z. B. eigenes Kapitel „Rechtliche Anforderungen“, eigenes Kapitel „IT-Sicherheit“ etc.). Letztlich sollte die Struktur so gewählt sein, dass sie dem Projekt angemessen ist und alle Beteiligten sich darin zurechtfinden.

Die gesammelten Anforderungen müssen in geeigneter Form dokumentiert werden, damit sie für alle verständlich sind und als verbindliche Grundlage dienen. Unterschiedliche Projekte nutzen unterschiedliche Dokumentationsarten, die jeweils Vor- und Nachteile haben.

• Anforderungskatalog (Excel/Tabellarisch): Ein einfacher Weg ist eine Tabelle (z. B. in Excel oder einem RM-Tool) mit allen Anforderungen, die nach Kategorien sortiert und ggf. priorisiert ist. Typische Spalten können sein: Anforderungs-ID, Beschreibung der Anforderung, Kategorie (Funktional/Qualität), Priorität (Muss/Soll/Kann), Quellen/Stakeholder, Bemerkungen und später Erfüllungsgrad je Anbieter. Diese Form eignet sich gut, um bei der Ausschreibung von jedem Anbieter eine Stellungnahme pro Anforderung einzuholen (Erfüllung „ja/nein/teilweise“ + Kommentarfeld). Ein tabellarischer Katalog erleichtert auch die Nachverfolgbarkeit einzelner Anforderungen (Traceability). Allerdings fehlt hier der erläuternde Kontext; daher wird ein reiner Katalog oft ergänzt durch ein erläuterndes Dokument oder zumindest Gliederungspunkte.

• Lastenheft (Fließtext mit Struktur): Das Lastenheft ist in Deutschland die gebräuchliche Form, Anforderungen des Auftraggebers in strukturierter schriftlicher Form festzuhalten. Es enthält neben der reinen Auflistung der Anforderungen auch einleitende Kapitel (Ziele, Scope, Randbedingungen, Begriffserklärungen) sowie oft Use Case-Beschreibungen, Prozessdiagramme oder Mockups zur Verdeutlichung. Ein Lastenheft gliedert sich in Sektionen wie Zielsetzung, Produkteinsatz (Stakeholder & Kontext), Funktionale Anforderungen, Nicht-funktionale Anforderungen, Schnittstellen, etc. Diese narrative Form erlaubt es, Hintergründe anzugeben – z. B. warum eine Anforderung gestellt wird, oder welche Entscheidungsspielräume es gibt. Wichtig ist, dass im Lastenheft die Anforderungen dennoch präzise und überprüfbar formuliert sind, idealerweise in sich selbst stehenden Einzelanforderungen (nummeriert). Ein guter Ansatz ist, jede wichtige Anforderung als „Soll-Aussage“ festzuhalten („Das System soll …“) und ggf. mit Akzeptanzkriterien zu versehen. So wird aus einem losen Wunsch eine testbare Forderung. Beispiel: „Das System soll für jeden Raum die Nettogrundfläche gemäß DIN 277 in m² ausweisen.“ – das ist eindeutig prüfbar. Allgemeine oder mehrdeutige Formulierungen (wie „benutzerfreundlich“ ohne Maßstab) sollten vermieden oder durch messbare Kriterien ersetzt werden. Ein professionelles Lastenheft schafft es, vage Absichten in konkrete Abnahmekriterien zu überführen. Daher sollte man bei jeder Anforderung fragen: „Wie würde ich prüfen, ob das umgesetzt wurde?“. Notfalls ist die Anforderung zu verfeinern..

• Agile Dokumentation (User Stories): In agilen Projekten oder wenn ein iterativer Vorgehensmodell gewählt wird, werden Anforderungen oft in Form von User Stories festgehalten. Eine User Story beschreibt kurz eine Funktion aus Sicht eines bestimmten Nutzers, z. B.: „Als Objektmanager möchte ich eine Übersicht aller offenen Instandhaltungsaufträge sehen, um Prioritäten setzen zu können.“ User Stories sind gut geeignet, den Nutzen und die Motivation hinter einer Anforderung zu kommunizieren. Allerdings ersetzen sie nicht die Detailbeschreibung – die Akzeptanzkriterien jeder User Story müssen ausgearbeitet werden, damit Entwickler genau wissen, wann die Story als erfüllt gilt. In der Praxis könnten User Stories im Rahmen von Scrum genutzt werden, um die Entwicklung zu steuern, während das Lastenheft die Gesamtanforderungen vorgibt. User Stories eignen sich auch für Workshops mit Endanwendern, um deren Bedürfnisse in Alltagssprache zu erfassen. Allerdings muss man aufpassen, dass keine wichtigen nicht-funktionalen Anforderungen dabei unter den Tisch fallen (daher ggf. ergänzende „Technical Stories“ oder Globale Anforderungen definieren). Ein Vorteil von User Stories ist die Priorisierbarkeit pro Sprint und die Förderung der Kommunikation im Team. In einem klassischen Ausschreibungsverfahren sind User Stories alleine jedoch unüblich – dort wird meist ein Lastenheft verlangt. Dennoch können im Anhang eines Lastenhefts illustrative User Stories aufgeführt werden, um dem Anbieter ein besseres Verständnis der Nutzungsszenarien zu vermitteln.

• Prozess- oder modulbezogene Dokumentation: Manche Organisationen erstellen pro Prozess Mini-Lastenhefte oder sogenannte Use Case Specification Sheets. Darin wird pro Anwendungsfall beschrieben: Ziel, beteiligte Rollen, Trigger, Ablauf, benötigte Daten, Ergebnisse. Diese sind sehr hilfreich, um die funktionalen Anforderungen im Zusammenhang zu validieren. Alternativ kann man die Dokumentation modulweise aufteilen, d.h. für jedes geplante Modul ein eigenes Kapitel/Dokument mit Anforderungen. Dies kann z. B. sinnvoll sein, wenn unterschiedliche Anbieter für unterschiedliche Module in Frage kommen (Modularer Einkauf) oder wenn Module in Phasen eingeführt werden. Wichtig ist, dass alle Dokumentationsteile konsistent sind (z. B. gleiche Priorisierungsskala, keine Doppelanforderungen widersprüchlich verteilt).

• Visuelle und sonstige Artefakte: Zusätzlich zum Text können Modelle, Diagramme und Mockups Bestandteil der Anforderungsdokumentation sein. Ein BPMN-Diagramm eines Wartungsprozesses, ein Architekturdiagramm der Systemlandschaft oder ein Wireframe für ein Raumbuchungsformular – solche Darstellungen erleichtern das Verständnis und sollten, wo sinnvoll, eingebunden werden. Sie ersetzen aber nicht die schriftliche Anforderung, sondern illustrieren sie. Im Lastenheft können sie als Abbildung mit Referenz eingebaut werden.

Klarheit, Eindeutigkeit und Prüfbarkeit der Anforderungen stehen an erster Stelle. Jede Anforderung sollte so geschrieben sein, dass ein Außenstehender ohne weitere Erläuterung verstehen kann, was gemeint ist. Es hat sich bewährt, Beispiele oder Akzeptanzkriterien direkt anzufügen, um Interpretationsspielraum zu minimieren. Zum Beispiel: „Das System soll Vertragsdokumente versionieren können (Änderungshistorie mit mindestens Zeitstempel, Benutzer und Änderungsgrund je Version).“ – hier ist klar, was erwartet wird. Außerdem sollten Muss-Anforderungen ausdrücklich als solche gekennzeichnet sein (im Fließtext oder durch Tags), um deren Wichtigkeit hervorzuheben.

Das fertige Lastenheft/Anforderungskatalog sollte von allen Kern-Stakeholdern überprüft und offiziell freigegeben werden (Abnahme der Anforderungen). Damit verpflichtet sich die Fachseite, keine weiteren „heimlichen“ Anforderungen nachzuschieben, und die IT-Seite akzeptiert die Machbarkeits- und Aufwandsbewertung. Änderungen danach müssen per Change Request behandelt werden – das diszipliniert alle Beteiligten, wirklich in der Anforderungsphase vollständig zu sein.

Nicht alle Anforderungen sind gleichermaßen kritisch. Eine Priorisierung ist erforderlich, um Ressourcen zu fokussieren, das Minimum Viable Product (MVP) zu definieren und ggf. phasenweise Einführungen zu planen.

• MoSCoW-Methode: Eine sehr verbreitete Technik ist MoSCoW, ein Akronym für Must, Should, Could, Won’t (sometimes later). Dabei werden Anforderungen in vier Prioritätsstufen eingeteilt:

• Muss-Kriterien (Must-have): Diese Anforderungen sind zwingend notwendig und nicht verhandelbar. Ohne ihre Erfüllung ist der Projekterfolg gefährdet. Sie bilden das Minimalsystem, das auf jeden Fall umgesetzt werden muss. Beispiel: „Gewährleistung der DSGVO-Konformität“ oder „Raumbuchungen müssen im Kalender des Nutzers synchronisiert werden können“ könnte für einen bestimmten Anwendungsfall ein Must-have sein. In einem CAFM-Kontext sind oft die Kernprozesse Muss (z. B. Wartungsplanung in einer technisch geprägten Organisation, oder Flächenmanagement in einem Immobilienunternehmen). Must-haves werden bevorzugt zuerst umgesetzt und getestet, da sie erfolgskritisch sind.

• Soll-Kriterien (Should-have): Diese Anforderungen sind sehr wichtig, aber nicht absolut kritisch. Ihr Fehlen würde das System einschränken, jedoch wäre es noch brauchbar. Oft lassen sich für Should-haves kurzfristige Workarounds finden, falls sie zum Start nicht vollständig da sind. Beispiel: „Mobile App für Techniker zur Auftragsbearbeitung“ könnte ein Should-have sein – wichtig, aber wenn es zunächst eine Laptop-Lösung gibt, wäre es verkraftbar. Should-haves erhöhen typischerweise die Benutzerzufriedenheit oder Effizienz deutlich, sind aber im Zeit- oder Budgetnotfall verschiebbar.

• Kann-Kriterien (Could-have): Diese Anforderungen sind Nice-to-have. Sie bringen Zusatznutzen, haben aber geringe Auswirkungen, wenn sie nicht erfüllt werden. Oft sind es Komfortfunktionen oder Wunschliste-Features, die umgesetzt werden können, falls Ressourcen übrig sind. Beispiel: „Gamification-Elemente im Helpdesk (Punkte für schnelle Ticketlösung)“ – nett, aber verzichtbar. Bei Could-haves ist zu prüfen, ob sie wirklich nötig sind oder lediglich „gold plating“ darstellen. In der Priorisierungsdiskussion kann man viele Coulds identifizieren und ggf. für später vorsehen. Einige Could-Themen wandern auch bewusst in eine „Phase 2“-Liste.

• Wird (vorerst) nicht umgesetzt (Won’t-have): Diese Kategorie enthält Anforderungen, die bewusst aus dem Scope ausgeschlossen wurden – zumindest für den aktuellen Projektrahmen. Sie können eventuell in Zukunft relevant werden, spielen aber jetzt keine Rolle. Die explizite Nennung der „Won’ts“ ist wichtig, um klare Erwartungen zu setzen und späteren Scope Creep abzuwehren. Beispiel: „Integration von KI zur Wartungsprognose“ könnte als Won’t klassifiziert werden, wenn es zwar im Gespräch war, aber aktuell zu aufwändig ist. Won’t heißt nicht „nie“, sondern „nicht jetzt“. Es schafft Transparenz und Wertschätzung, wenn man es auflistet (zeigt, dass Idee XY nicht vergessen, aber bewusst zurückgestellt ist).

Die MoSCoW-Einteilung sollte im Anforderungskatalog kenntlich gemacht werden (z. B. extra Spalte oder farbige Markierung). Sie ermöglicht es, bei der Umsetzung zuerst die Must-haves zu realisieren und auch bei Lieferantenauswahl knallhart zu prüfen, ob alle Musts erfüllt werden. In einer Bewertungsmatrix bei der Ausschreibung könnten z. B. Muss-Kriterien mit KO-Bedingung versehen werden (d. h. ein Anbieter, der ein Muss nicht erfüllt, scheidet aus). Should-/Could-Kriterien könnten bepunktet werden nach Qualität der Umsetzung.

• Kano-Modell: Während MoSCoW die geschäftliche Wichtigkeit aus Auftraggebersicht gewichtet, betrachtet das Kano-Modell die Kundenzufriedenheit bzw. Nutzerzufriedenheit als Maßstab. Noriaki Kano unterscheidet Basisfaktoren, Leistungsfaktoren und Begeisterungsfaktoren, zusätzlich „unerhebliche“ und „Rückweisungsmerkmale“. Übertragen auf CAFM-Anforderungen:

• Basis-Anforderungen (Must-be): Das sind Eigenschaften, die der Nutzer als selbstverständlich erwartet. Ihre Erfüllung steigert die Zufriedenheit nicht über neutral, aber ihre Nichterfüllung führt zu starker Unzufriedenheit. Im CAFM könnte z. B. „Einhaltung gesetzlicher Pflichten“ oder „Grundlegende Bedienbarkeit der Software (stabile Login-Funktion, Speichern ohne Datenverlust)“ als Basisanforderung gelten. Diese müssen unbedingt da sein (deckungsgleich mit Muss-Kriterien).

• Leistungs-Anforderungen (Performance): Dies sind Anforderungen, bei denen „mehr ist besser“ gilt – je besser das System in diesem Merkmal performt, desto zufriedener der Nutzer. Im FM-Kontext könnten das z. B. Berichtsfunktionen sein (je vielfältiger und schneller die Reports, desto zufriedener), oder Responsezeiten (je schneller Tickets bearbeitet werden können, desto besser). Diese Leistungsmerkmale sollte man mit Zielen versehen (z. B. „Bericht XY soll in <5 Sekunden generiert werden können“).

• Begeisterungs-Anforderungen (Excitement): Das sind innovative Features, mit denen der Nutzer nicht gerechnet hat, die aber große Freude oder Mehrwert bringen. Beispiel im CAFM: eine intuitive 3D-Gebäude-Navigation könnte ein Begeisterungsmerkmal sein, oder ein Chatbot, der Auskünfte zu Rauminformationen gibt. Diese Dinge führen zu echter Begeisterung, sind aber nicht erwartet. Für die Priorisierung heißt das: Solche Merkmale können einen Wettbewerbsvorteil darstellen – wenn man sie relativ günstig umsetzen kann, lohnen sie sich trotz geringerer Priorität im klassischen Sinn, weil sie die Akzeptanz pushen.

• Unerhebliche Merkmale: Diese erfüllen keinen erkennbaren Nutzwert – ihr Vorhandensein oder Fehlen macht für den Anwender keinen Unterschied. Solche Anforderungen sollte man idealerweise gar nicht erst stellen (Filter in der Erhebung!). Beispiel: „Software muss 10 verschiedene Farbschemen im UI anbieten“ – den meisten egal, daher unerheblich.

• Rückweisungsmerkmale: Das sind Eigenschaften, die aktiv unerwünscht sind – ihre Umsetzung würde zu Ablehnung führen. Im Kontext einer Software können das z. B. Features sein, die als überwachend wahrgenommen werden (etwa „Aufzeichnen der individuellen Mausbewegungen“ – würde Misstrauen erzeugen und vom Betriebsrat abgelehnt). Solche „Anti-Anforderungen“ gilt es ebenfalls zu kennen und natürlich nicht umzusetzen.

Das Kano-Modell kann genutzt werden, um bei der Priorisierung vor allem zwischen Basis-Muss (Pflicht), Leistungs-Soll (entscheidend für Zufriedenheit) und Begeisterungs-Kann (Bonus) zu unterscheiden. Beispielsweise könnte man alle Muss-Anforderungen nochmal prüfen, ob sie nur Basis abdecken oder ob da nicht implizite Erwartungen sind. Kano wird klassisch durch Kundenbefragungen ermittelt – in einem CAFM-Projekt könnte man die Hauptnutzer fragen, was sie erwarten und was sie begeistern würde. Dadurch kriegt man ein Gefühl dafür, wo eventuell mit wenig Zusatzaufwand ein Wow-Effekt erreicht werden kann (z. B. eine moderne Web-Oberfläche mit Dashboard könnte Begeisterung schaffen, obwohl es kein Muss war).

• Bewertungsmatrix/Nutzwertanalyse: Neben MoSCoW und Kano, die eher kategorisieren, gibt es formalere Ansätze wie die Nutzwertanalyse. Dabei werden Bewertungskriterien festgelegt (z. B. Nutzen für Nutzer, Kosten/Aufwand, Risiken, strategische Bedeutung) und gewichtet. Jede Anforderung erhält in jedem Kriterium einen Score, daraus errechnet sich ein Gesamtprioritätswert. Dieser methodische Ansatz ist in komplexen Projekten hilfreich, um eine ranggerechte Liste aller Anforderungen zu erzeugen und transparent zu machen, warum etwas oben oder unten steht. Beispielsweise könnte man feststellen, dass eine bestimmte Anforderung zwar für die Nutzer nett wäre, aber extrem hohe Kosten verursacht und wenig strategischen Mehrwert – so eine würde in der Matrix schlechter abschneiden trotz Wunsch der Nutzer (diese Argumentation hilft, sie zurückzustellen). In der Praxis wird eine vollumfängliche Nutzwertanalyse eher für große Entscheidungsfragen eingesetzt (welches System wählen), weniger für jede Klein-Anforderung. Aber eine einfache Bewertungsmatrix kann z. B. im Rahmen eines Workshops gemacht werden: Man nimmt alle Could-Anforderungen und lässt die Teilnehmer Punkte (z. B. 1 bis 5) für Geschäftsnutzen und Aufwand vergeben. Daraus ergibt sich ein Ranking oder man identifiziert „Quick Wins“ (hoher Nutzen, niedriger Aufwand) vs. „Nice-to-haves“ (geringer Nutzen, hoher Aufwand). Solche Priorisierungsworkshops sorgen für ein gemeinsames Verständnis und Commitment.

Unabhängig von der Methode sollte die Priorisierung frühzeitig und eindeutig festgehalten werden – idealerweise schon im Lastenheft bei jeder Anforderung. Das verhindert, dass im Projekt alles als gleich wichtig behandelt wird. Eine Klärung durch das Management ist ratsam: welche Ziele stehen im Vordergrund? Daraus leiten sich Muss-Kriterien leichter ab (z. B. wenn „Rechtskonformität“ Ziel Nr.1 ist, dann haben alle Compliance-bezogenen Anforderungen Top-Priorität). Priorisierung ist auch ein Mittel, um Konflikte abzumildern: Wenn zwei Fachbereiche unterschiedliche Dinge am wichtigsten finden, zwingt eine priorisierte Liste zur Diskussion, was für das Gesamtunternehmen vorgeht. Nicht zuletzt ist Priorisierung essentiell für die Planung – sie bestimmt die Reihenfolge der Umsetzung (bei gestaffeltem Rollout) und ist entscheidend für das Scope-Management: Bei Budget- oder Zeitknappheit weiß man, was weggelassen werden kann.

In jedem größeren Projekt treten früher oder später Widersprüche oder Konflikte zwischen Anforderungen auf. Typische Beispiele in CAFM-Vorhaben: Die IT verlangt aus Sicherheitsgründen eine komplexe Zugriffsmatrix, die FM-Anwender wünschen sich aber möglichst einfache, breite Zugriffsrechte – hier kollidieren „Sicherheit vs. Usability“. Oder Fachbereich A will eine sehr spezifische Funktion, die aber dem Standard der Software widerspricht und von Fachbereich B nicht benötigt wird. Auch Datenschutz vs. Informationsbedarf kann ein Spannungsfeld sein (z. B. umfangreiche Protokollierung aller Nutzeraktionen zur Nachvollziehbarkeit steht im Widerspruch zum Datenschutzprinzip der Datensparsamkeit).

• Früh identifizieren: Es ist wichtig, Widersprüche schon in der Anforderungsphase transparent zu machen – z. B. indem Anforderungen nebeneinander gelegt und auf Konsistenz geprüft werden. Wenn ein Lastenheft-Kapitel „Datenschutz“ fordert, „es sollen so wenig personenbezogene Daten wie möglich gespeichert werden“, und im Kapitel „Betrieb“ steht, „Aktivitäten jedes Nutzers sind vollumfänglich zu protokollieren“, dann muss das aufgelöst werden. Eine Konsistenzprüfung des Anforderungskatalogs (am besten durch ein unabhängiges Teammitglied oder Berater) hilft, solche Dinge zu finden.

• Hintergrund verstehen: Oft sind widersprüchliche Anforderungen Ausdruck unterschiedlicher Interessen oder Sichtweisen. Hier hilft es, die zugrunde liegenden Bedürfnisse offenzulegen. Beispiel: Der Wunsch nach vollständiger Protokollierung kommt evtl. aus Compliance-Gründen (Nachweispflicht), während der Widerspruch aus Datenschutz-Angst herrührt. Wenn alle am Tisch wissen, was wirklich wichtig ist (Nachweis vs. Privatsphäre), kann man nach Lösungsalternativen suchen (z. B. Kompromiss: Protokollierung ja, aber Zugriff auf Protokolle nur stark eingeschränkt und Daten nach X Tagen löschen).

• Priorisieren nach Zielen: Bei echten Zielkonflikten sollte man auf die Projektziele und Unternehmensziele zurückgreifen. Welche Anforderung trägt mehr zur Erreichung der obersten Ziele bei? Im Zweifel muss eine Anforderung zurückstehen, wenn sie dem übergeordneten Ziel entgegenläuft. Beispiel: Wenn Digitalisierung der Prozesse das Hauptziel ist, und eine Fachabteilung wünscht sich aber aus Bequemlichkeit, weiter Papierprozesse parallel zu fahren (konfligiert mit Digitalisierung), dann muss letzterer Wunsch abgelehnt werden. Hier ist Management-Support gefragt, um solche Entscheidungen zu legitimieren.

• Gemeinsame Workshops / Entscheidungen herbeiführen: Widersprüche löst man am besten in einem Moderationsgespräch mit den betroffenen Stakeholdern. Ein neutraler Moderator (Projektleiter oder externer Berater) sollte die Pros und Cons beider Anforderungen beleuchten und idealerweise eine Kompromisslösung erarbeiten lassen. Wichtig ist, dass alle Seiten gehört werden – oft ergeben sich kreative Lösungen, die beide Anliegen bedienen. Beispiel: Der Fachbereich möchte eine sehr spezielle Berichtsform, die Software kann das nicht out-of-the-box – anstatt teuer zu entwickeln, einigt man sich evtl., diese Berichte einmalig außerhalb des Systems zu erstellen, und das System liefert nur die Rohdaten. So wird die eigentliche Anforderung (Information) erfüllt, ohne den Systemstandard zu sprengen.

• Dokumentation der Entscheidung: Damit später keine Diskussion erneut aufflammt, sollte die gefundene Lösung oder der entschiedene Verzicht klar dokumentiert werden – etwa als Anmerkung im Lastenheft („Anforderung X und Y wurden zugunsten von Lösung Z zusammengeführt“).

Was bedeutet es, wenn wir A statt B priorisieren? (Kosten, Zeit, Risiken). So kann das Entscheidungsgremium fundiert abwägen. Bei Bedarf kann man auch Prototypen oder Proof-of-Concepts einsetzen, um zu sehen, ob ein Kompromiss tragfähig ist.

Ein externer Berater könnte sagen, „In anderen Unternehmen wurde auf Feature X verzichtet, weil es zu teuer war, und stattdessen Y gemacht“. Das schafft Akzeptanz, dass man nicht jedem Wunsch folgt.

z. B. zunächst den gemeinsamen Nenner umsetzen, und die strittigen Punkte in Phase 2 adressieren, wenn mehr Erfahrung mit dem System da ist. Evtl. erübrigt sich manches dann oder wird neu beurteilt.

Widersprüchliche Anforderungen sind also nichts Ungewöhnliches – entscheidend ist, offen damit umzugehen und eine Harmonisierung im Sinne des Projektziels herbeizuführen. Priorisierungsmethoden (wie MoSCoW und Kano) sind indirekt auch Werkzeuge zur Harmonisierung, weil sie alle Beteiligten zwingen, sich auf eine Rangfolge zu einigen. Im Zweifel muss die Projektsteuerung bzw. ein Lenkungsausschuss die Entscheidung treffen, welche Anforderung gestrichen oder angepasst wird. Ein dokumentierter Änderungsprozess (Change Request Verfahren) hilft hier ebenfalls: wenn nachträglich eine „vergessene“ Anforderung auftaucht, muss offiziell entschieden werden, ob sie aufgenommen wird (Budget? Was fällt stattdessen weg?). Das diszipliniert ebenfalls, echte Widersprüche aufzulösen statt alles hineinzupacken.

Sind die Anforderungen erhoben und abgestimmt, müssen sie so aufbereitet werden, dass sie im weiteren Prozess – sei es eine Ausschreibung oder die direkte Implementierung – optimal verwendet werden können.

• Eindeutigkeit und Klarheit: Jede Anforderung sollte nur eine mögliche Interpretation zulassen. Vermeiden Sie vage Formulierungen wie „möglichst benutzerfreundlich“ ohne Maßstab. Besser: „Der Workflow zur Raumbuchung soll in max. 5 Schritten abgeschlossen sein“ – hier ist klar, was benutzerfreundlich heißt. Ebenso sollten keine unterschiedlichen Begriffe für das Gleiche verwendet werden (Konsistenz der Begrifflichkeiten durch ein Glossar). Falls Abkürzungen oder firmenspezifische Begriffe genutzt werden, unbedingt erklären. Anforderungen sollten auch kurz und prägnant formuliert sein – keine verschachtelten Sätze mit mehreren Forderungen. Faustregel: eine Anforderung = ein Satz. Wenn man „und“ oder „oder“ benutzt, prüfen, ob es nicht zwei getrennte Anforderungen sind.

• Prüfbarkeit/Testbarkeit: Wie schon erwähnt, sollen insbesondere nicht-funktionale Anforderungen messbar und prüfbar formuliert sein. Es muss also im Lastenheft erkennbar sein, wie man bei Abnahme testet, ob die Anforderung erfüllt wurde. Dazu gehören konkrete Zahlen, Zustände oder Kriterien. Beispiel statt „schnell“ => „innerhalb 2 Sekunden“. Statt „intuitiv“ => „ohne Schulung innerhalb 1 Stunde bedienbar (Usability-Test mit 5 Anwendern)“. Für funktionale Anforderungen bedeutet Testbarkeit, dass für jede Funktion ein Akzeptanzkriterium existiert (z. B. „Ein Nutzer mit Rolle X kann einen neuen Vertrag anlegen und alle Pflichtfelder ausfüllen; beim Speichern wird eine eindeutige Vertrags-ID vergeben“). Im agilen Kontext sind solche Kriterien Teil der User Story Definition of Done; im klassischen Lastenheft können sie als Ergänzung in Klammern oder als separater Absatz „Prüfung“ genannt werden. Das Ziel ist: Nachvollziehbarkeit, ob der Lieferant später die Anforderung erfüllt hat. Dies wird auch wichtig, wenn man Abnahmetests plant.

• Nachvollziehbarkeit (Tracing): Für Ausschreibungen ist es vorteilhaft, wenn Anforderungen durchnummeriert und referenzierbar sind. Dann kann im Pflichtenheft des Anbieters oder im Projektplan stets auf die Anforderungs-ID Bezug genommen werden („Umsetzung zu Anforderung 3.5.7 erfolgt im Sprint 4“). Idealerweise wird eine Requirements Traceability Matrix (RTM) geführt, die jede Anforderung über den Lebenszyklus verfolgt – von der Spezifikation zur Umsetzung und zum Test. Schon im Lastenheft kann man hierfür den Grundstein legen, indem man etwa Anforderungen kapitelweise nummeriert (1.xx für funktional, 2.xx für nicht-funktional etc.). Bei der Bewertung von Angeboten kann man dann auch Anbieter-Aussagen pro Anforderung einfügen. Diese Rückverfolgbarkeit ist bei öffentlichen Vergaben teils vorgeschrieben und bei komplexen Projekten goldwert, um nichts zu vergessen.

• Priorisierung kenntlich machen: Wie oben besprochen, sollten Muss-Anforderungen markiert sein. Für eine Ausschreibung wird oft gefordert, Muss-/Soll-Kriterien zu unterscheiden. Im Dokument sollten Mussforderungen z. B. mit „[M]“ oder durch fettgedrucktes „Muss:“ direkt im Satz kenntlich sein. Das verhindert Missverständnisse und erlaubt es, Angebote schnell auf KO-Kriterien zu checken.

• Konsolidierung und Konsistenz: Vor der Finalisierung sollte das Anforderungsdokument noch einmal bereinigt werden: Doppelungen zusammenfassen, Widersprüche (s. oben) eliminieren, und auf Lücken prüfen. Ein guter Trick ist, die Anforderungen von jemand Unbeteiligtem gegenlesen zu lassen – versteht diese Person alles, erscheinen die Forderungen konsistent? Stimmen die Zahlen in verschiedenen Kapiteln überein (z. B. einmal 5 Gebäude, anderswo 6 Gebäude)? Solche Inkonsistenzen könnten sonst Anbieter ausnutzen oder führen zu falschen Angeboten.

• Beachtung von Ausschreibungsformaten: Falls eine öffentliche Ausschreibung durchgeführt wird, gibt es oft formale Vorgaben (z. B. nach VOL/A oder VgV). Anforderungen müssen dann in bestimmte Kategorien (Muss/Kann) eingeteilt und evtl. mit Gewichtungen versehen werden. Hier sollte man das Lastenheft entsprechend darauf vorbereiten. Auch Bewertungskriterien (z. B. wie werden Kann-Anforderungen bepunktet) sollte man parallel mitentwickeln. Intern kann eine Bewertungsmatrix erstellt werden, die für jedes Angebot erfasst, wie viele Kann-Punkte erfüllt wurden. Dafür ist es hilfreich, wenn die Anforderungen im Dokument eindeutig referenzierbar sind.

• Simulation/Dry-Run: Eine gute Praxis ist, einen Gedanken-Durchlauf der Ausschreibung zu machen: Versetzen Sie sich in den Anbieter und prüfen Sie, ob alle Anforderungen für ihn verständlich wären und ob er darauf antworten kann. Gibt es unklare Stellen, wo jeder Anbieter etwas anderes verstehen könnte? Falls ja, nachschärfen. Ebenso kann man mit dem Team durchspielen: „Wenn wir die Software konfigurieren, können wir zu jeder Anforderung einen Konfigurationspunkt benennen?“. Wenn Anforderungen zu generisch sind (z. B. „System muss flexibel sein“ – wie konfiguriert man das?), dann taugen sie nicht viel. Also weg damit oder präzisieren.

• Zukünftige Änderungen berücksichtigen: Bei Systemkonfiguration (oder auch Vertrag) ist es wichtig, Änderungsanforderungen strukturiert zu behandeln. Im Lastenheft sollte daher möglichst die aktuelle Wahrheit dokumentiert sein, aber man kann z. B. vermerken: „Diese Anforderung ist für Phase 1 optional, könnte in Phase 2 relevant werden.“ So sieht ein Anbieter, dass evtl. später Nachrüstbedarf kommt. Das ist kein Muss, aber hilfreich. Auch sollte man definieren, wie mit neuen rechtlichen Anforderungen umgegangen wird – etwa: „Das System muss Updates erhalten, wenn gesetzliche Vorschriften sich ändern (z. B. neue ESG-Pflichten)“. Solche Zukunfts-Forderungen sind schwer prüfbar, aber man kann zumindest vertraglich festhalten, dass der Anbieter z. B. ein Wartungsvertrag anbieten muss, der solche Updates umfasst.

Sorgfalt und Genauigkeit bei der Aufbereitung der Anforderungen zahlen sich aus. Ein vollständig und klar formuliertes Lastenheft erhöht die Chance, vergleichbare und passende Angebote von Anbietern zu bekommen. Unklare Anforderungen führen sonst dazu, dass Anbieter Worst-Case annehmen (Preiserhöhung) oder eigene Annahmen treffen (die evtl. nicht im Sinne des Auftraggebers sind). Im schlimmsten Fall ignoriert ein guter Anbieter eine schlecht gemachte Ausschreibung. Daher: ausreichend Zeit für den Qualitätssicherungs-Check des Lastenhefts einplanen – es ist die Visitenkarte des Projekts am Markt.

Nachdem die Anforderungen definiert und in einem Vertrag oder Pflichtenheft vom Anbieter übernommen wurden, muss am Projektende überprüft werden, ob alles geliefert wurde, was gefordert war. Dafür werden Abnahmekriterien benötigt, die eng an die Anforderungen geknüpft sind.

• Im Lastenheft sollte möglichst zu jeder Anforderung ein Abnahmekriterium implizit mitformuliert sein (bzw. die Anforderungen selbst so präzise sein, dass sie als Abnahmekriterium dienen können). Wie oben erwähnt: Eine Anforderung, die nicht testbar ist, eignet sich auch nicht als Abnahmekriterium. Daher sind die Merkmale präzise, messbar, vollständig so wichtig. Ein professionelles Lastenheft verwandelt Anforderungen praktisch in Testfälle – in dem Sinne, dass man aus jeder Anforderung ableiten kann, was und wie geprüft werden muss.

• In der Praxis wird zur Abnahme ein Abnahmetest bzw. User Acceptance Test (UAT) durchgeführt. Dazu wird häufig eine Traceability-Matrix genutzt: Jede Anforderung erhält einen Verweis auf einen oder mehrere Testfälle. Beispiel: Anforderung 5.3.1 „System generiert Wartungsplan“ – Testfall 5.3.1: „Benutzer erstellt einen Wartungsplan und überprüft, ob alle Termine gemäß Regel X generiert wurden.“. Diese Testfälle sollten idealerweise gemeinsam von Auftraggeber und Auftragnehmer während der Implementierung erstellt werden. Oft liefert der Anbieter ein Testkonzept oder Pflichtenheft, in dem er beschreibt, wie er die Anforderungen umsetzt und wie sie getestet werden sollen. Der Auftraggeber sollte dem zustimmen. Spätestens vor Go-Live werden dann die Tests durchgeführt (funktionale Tests, Integrationstests, ggf. Performance-Tests auf definierte Last).

• Abnahmekriterien sind also die Konkretisierung der Muss-Anforderungen: Alle Muss-Kriterien müssen in Tests positiv verifiziert werden, um die Abnahme zu bestehen. Für Kann-Anforderungen kann man vereinbaren, dass leichte Abweichungen toleriert werden oder als Change behandelt werden. Wichtig ist, dass im Projektvertrag oder in der Leistungsbeschreibung klar geregelt ist, was die Abnahmekonditionen sind. Viele Verträge verweisen direkt auf das Lastenheft bzw. Pflichtenheft: besteht das gelieferte System alle Tests bezogen auf diese Anforderungen, erfolgt die Abnahme.

• Ein praktischer Ansatz ist es, im Anforderungskatalog eine Spalte „Verifikationsmethode“ zu führen: z. B. D (Demonstration), T (Test), I (Inspektion), A (Analyse). Hier legt man je Anforderung fest, wie sie geprüft wird – etwa durch direkte Benutzerdemonstration im System, durch Auswertung von Reports, durch Code-Inspektion oder Messung. So kann man planvoll die Abnahme vorbereiten.

• Bei Systemen, die z. B. sicherheitsrelevant sind, können auch Abnahme durch Drittprüfer nötig sein (z. B. TÜV-Abnahmen für bestimmte Module). Solche Dinge sollten ebenfalls früh in Anforderungen stehen, damit der Anbieter weiß, dass z. B. eine BSI-Grundschutz-Prüfung Bestand haben muss.

• Validierung bedeutet hier: Sicherstellen, dass das System die wahren Bedürfnisse erfüllt. Das geht über das reine Abhaken der Anforderungen hinaus. Es kann sein, dass alle spezifizierten Anforderungen erfüllt sind, aber die Nutzer dennoch unzufrieden, weil vielleicht etwas wichtiges übersehen wurde oder die Umsetzung zwar gemäß Anforderung ist, aber unpraktisch. Best Practice ist daher, schon während der Implementierung Reviews mit Endnutzern zu machen und eventuell Prototypen oder Teillösungen zu validieren (z. B. einen Pilotbereich mit Echt-Daten testen). So können Korrekturen noch vor der finalen Abnahme einfließen.

• Für die formale Endabnahme empfiehlt es sich, Abnahmeszenarien zu definieren: z. B. „Durchspiele einen vollständigen Wartungsprozess von der Planung bis zur Dokumentation – alle Schritte funktionieren wie erwartet“. Solche End-to-End-Tests ergänzen die Einzelanforderungs-Tests und zeigen, ob das System im Gesamtkontext funktioniert.

• Zusätzlich sollten nicht-funktionale Anforderungen validiert werden: z. B. Lasttest für Performance-Anforderungen (Simulate 100 gleichzeitige Nutzer), Penetrationstest oder zumindest Sicherheits-Check für Security-Anforderungen, Backup/Restore-Test für Verfügbarkeitsanforderungen. Wenn im Lastenheft z. B. „System muss 99% verfügbar sein“ stand, muss man definieren, über welchen Zeitraum das gemessen wird (Monat?) und wie (Monitoring-Tool?). Ggf. fließen solche Punkte dann in Service Level Agreements mit dem Betreiber.

• Bei Abnahme und Validierung gilt: Protokollieren! Jedes getestete Kriterium sollte abgehakt oder mit Befund versehen werden. Offene Punkte ergeben dann Restarbeiten oder Gewährleistungsansprüche. Oft wird eine Abnahmeniederschrift erstellt, in der festgehalten ist, welche Anforderungen erfüllt wurden und welche nicht, inkl. Frist zur Nachbesserung.

• Noch ein Aspekt: Schulung und Usability – schwer in klassischen Anforderungen zu fassen, aber letztlich Teil der Validierung. Man merkt erst beim Test mit echten Usern, ob z. B. eine Oberfläche wirklich intuitiv ist. Hier kann man Abnahmekriterien definieren wie „Testnutzer konnte ohne Anleitung Vorgang X erfolgreich durchführen“. Solche etwas weicheren Kriterien sind schwierig zu messen, aber ein erfahrener Projektleiter wird auf das Nutzerfeedback achten und ggf. Nachbesserung fordern, wenn zwar formal alles da ist, aber unbedienbar.

Abnahmekriterien sind der Maßstab, an dem die gelieferte Lösung gemessen wird. Sie leiten sich aus den Anforderungen ab und müssen schon bei der Anforderungsformulierung mitgedacht werden. Eine enge Verknüpfung von Anforderungen und Tests (Traceability) erleichtert die Übergabe vom Anforderungs- zum Testteam. Der Lohn der Mühe ist am Ende die Gewissheit, dass das CAFM-System tatsächlich das leistet, was man sich zu Beginn vorgenommen hat – ohne Abstriche und böse Überraschungen.

• Herausforderung: Unklare Ziele / fehlender Fokus. Wenn von Beginn an die Zielsetzung des Projekts nicht eindeutig ist, verzettelt sich die Anforderungserhebung leicht. Fachbereiche wünschen sich „alles Mögliche“, weil nicht klar ist, was Priorität hat.

• Best Practice: Projektziele schriftlich fixieren (z. B. in einer Zielmatrix) und mit der Leitung abstimmen, bevor ins Detail gegangen wird. Diese Ziele sollten zu Beginn jedes Workshops kommuniziert werden („Wir führen CAFM ein, um X und Y zu erreichen – darauf richten wir die Anforderungen aus.“). Alles, was dem nicht dient, wird kritisch hinterfragt. Außerdem hilft es, eine Scope-Abgrenzung zu formulieren (welche FM-Bereiche sind in Phase 1 drin, welche explizit nicht). Das verhindert Scope Creep.

• Herausforderung: Fehlende Einbindung wichtiger Stakeholder. Wenn z. B. die IT oder der Betriebsrat zu spät einbezogen werden, können bereits definierte Anforderungen wieder in Frage gestellt werden (z. B. „Diese Cloud-Lösung dürfen wir gar nicht verwenden“).

• Best Practice: Stakeholderanalyse zu Projektstart – Identifizieren Sie alle, die vom System betroffen sind, inkl. „kritischer Geister“. Planen Sie partizipative Formate (Workshops, Interviews) mit jeder relevanten Gruppe ein. Besonders die Mitbestimmung: Früh Kontakt mit dem Betriebsrat suchen, ein gemeinsames Verständnis herstellen (z. B. durch Vorlage eines groben Konzepts wie: „Was soll erfasst werden, welche Kontrollmöglichkeiten wird es nicht geben“). Das schafft Vertrauen. Ebenso die IT: Falls die interne IT keine Kapazitäten hat, ein CAFM zu betreuen, muss evtl. SaaS gewählt werden – das sind Weichenstellungen, die von Anfang an bekannt sein müssen.

• Herausforderung: „Wunschkonzert“-Mentalität / Überfrachtung. Oft neigen Fachabteilungen dazu, alle denkbaren Features zu fordern („wenn wir schon neu machen, dann soll es auch alles können“). Das führt zu überladenen Lastenheften mit 1000+ Anforderungen, die unmöglich alle gleichzeitig erfüllt werden können – entweder scheitert die Umsetzung oder es wird extrem teuer.

• Best Practice: Realitätscheck und Priorisierungsschleifen. Nutzen Sie Methoden wie MoSCoW konsequent, um die wirklich wichtigen Anforderungen herauszuschälen. Stellen Sie kritische Fragen: „Was passiert, wenn wir das Feature nicht haben?“ – Wenn die Antwort „dann finden wir einen Workaround“ ist, ist es kein Must. Holen Sie sich Markteinschätzungen ein: Ein erfahrener Berater kann sagen, welche Anforderungen üblich sind (Standard) und welche exotisch und teuer. Kennzahlen: Ein Lastenheft mit, sagen wir, 200 Muss-Anforderungen und 200 Soll/Kann ist schon sehr umfangreich; wenn jemand 800 Muss-Kriterien aufschreibt, ist das nicht glaubwürdig. Hier hilft es, im Team eine Schmerzgrenzen-Diskussion zu führen: Lieber weniger vollständig, aber dafür erfolgreich einführen und später ausbauen. Ein Sprichwort: „Perfekt ist der Feind von gut.“ – gerade bei Softwareeinführungen sollte man sich auf die Kernbedarfe konzentrieren, statt ein theoretisch perfektes System auf dem Papier zu definieren, das dann nie realisiert wird.

• Herausforderung: Unklare oder implizite Anforderungen. Einige Anforderungen werden manchmal vorausgesetzt, aber nicht dokumentiert („das versteht sich doch von selbst“). Z. B. erwartet jeder, dass eine Software eine Backup-Funktion hat, aber wenn es nicht gefordert war, ist es evtl. nicht Teil des Angebots.

• Best Practice: Review durch Dritte – lassen Sie jemanden mit frischem Blick das Lastenheft lesen. Nutzen Sie vorhandene Checklisten.

• Herausforderung: Kommunikation und unterschiedliche Sprache. FM-Fachleute, IT-Experten und Berater sprechen teilweise unterschiedliche „Sprachen“. Das kann zu Missverständnissen führen – z. B. versteht der FMler unter „Raum“ etwas anderes als der ITler unter „Speicherplatz“.

• Best Practice: Glossar und Moderation. Führen Sie ein Begriffs-Glossar im Lastenheft (gern als Tabelle im Anhang), wo alle wichtigen Begriffe definiert sind (Raum = physischer Raum nach DIN 277, nicht „memory“ etc.). Bitten Sie die Teilnehmer in Workshops, Abkürzungen oder Jargon zu erklären. Ein erfahrener Moderator kann hier vermitteln und darauf achten, dass ein gemeinsames Verständnis entsteht. Visualisierung (z. B. zeichnen eines Gebäudebaumdiagramms) hilft, um sicherzugehen, dass alle dasselbe Bild vor Augen haben.

• Herausforderung: Änderungsmanagement (moving targets). Während man Anforderungen erhebt, ändern sich manchmal Rahmenbedingungen: Eine neue DSGVO-Auslegung, ein Wechsel im Management mit neuen Zielen, eine technische Innovation am Markt, die plötzlich relevant wird. Oder interne Entscheider ändern ihre Meinung. Wenn die Anforderungserhebung lange dauert, gerät man so auf moving targets.

• Best Practice: Agiles Element einbauen. Auch wenn man klassisch vorgeht, kann man Zwischenergebnisse iterativ validieren. Halten Sie früh einen Entwurf des Lastenhefts fest und lassen Sie ihn absegnen, statt monatelang im stillen Kämmerlein zu sammeln. Bauen Sie Puffer für neue Erkenntnisse ein, aber ziehen Sie auch eine Deadline, ab wann keine neuen Anforderungen mehr rein dürfen (oder diese dann für Phase 2 aufgehoben werden). Dokumentieren Sie Änderungswünsche explizit und führen Sie eine Change-Liste. Das hält die ursprüngliche Anforderungsliste stabil und zeigt transparent, was später hinzugekommen ist. Im Zweifel lieber ein, zwei Änderungen aufnehmen als wichtige Dinge zu ignorieren – aber bewusst entscheiden und Stakeholder informieren, was das für Auswirkungen hat (Zeit, Kosten).

• Herausforderung: Mangelnde Dokumentation während der Erhebung. Viele Workshops, viele Ideen – wenn das nicht konsequent dokumentiert wird, gehen Punkte vergessen oder falsch in das Lastenheft ein. Gerade bei längeren Projekten besteht die Gefahr, dass Aufzeichnungen fehlen oder in persönlichen Notizen versanden.

• Best Practice: Zentrales Requirements-Log führen. Nach jedem Interview/Workshop sofort die Ergebnisse in den Anforderungskatalog überführen. Protokolle anfertigen und verteilen – und das Wichtigste: von den Teilnehmern freigeben lassen („Haben wir Ihre Anforderungen richtig verstanden?“). Ein Tool (z. B. Jira, Excel-Liste in SharePoint, o. ä.) das alle Anforderungen listet, sollte möglichst früh geführt werden und allen Beteiligten transparent zugänglich sein. So können auch alle mitverfolgen, welche Anforderungen schon erfasst wurden (verhindert Doppelmeldungen). Änderungsverlauf sollte protokolliert sein.

• Herausforderung: Zu hohe Detailtiefe vs. zu abstrakt. Die Kunst bei Anforderungen ist der richtigen Detaillierungsgrad. Zuviel Detail (z. B. vorschreiben, welcher Farbcode ein Button haben soll) schränkt Lösungen unnötig ein und verwirrt – das gehört eher ins Pflichtenheft des Anbieters. Zu wenig Detail (z. B. „System soll Berichte liefern“ – ja welche denn?) ist nicht testbar.

• Best Practice: Level finden: Orientieren Sie sich an der Frage: Was soll fachlich erreicht werden? Und woran würden wir erkennen, dass es erreicht ist? – das ist die richtige Ebene. Technische Umsetzungsdetails (wie etwas programmiert wird) gehören dem Anbieter. Als Faustregel: Anforderungen sollten lösungsneutral formuliert sein, aber so konkret, dass ein Dritter die Leistung verstehen kann. Also nicht „Das System soll modern sein“ (zu abstrakt), sondern „Das System soll als Web-Anwendung im Browser laufen, keine lokale Installation erfordern“ (konkret, aber lösungsneutral genug, da viele Wege zu Web-Anwendung führen). Wenn Stakeholder zu sehr ins Wie abdriften, moderieren Sie zurück zum Was/Warum. Ausnahme: Es gibt harte Präferenzen (z. B. „wir wollen keine Cloud“ – das ist ein Was in Bezug auf Betriebsart).

• Herausforderung: Akzeptanz und Change-Management. Manchmal äußern Mitarbeiter keine Anforderungen aus Angst oder Unsicherheit („wenn ich sage, was ich will, kommt vielleicht raus, dass meine Stelle überflüssig wird“). Oder sie sind generell skeptisch gegenüber dem neuen System und boykottieren es passiv (liefern keine Infos).

• Best Practice: Offene Kommunikation und Einbindung. Erklären Sie den Nutzen des neuen Systems für alle Beteiligten und betonen Sie, dass niemand ersetzt, sondern unterstützt werden soll. Nutzen Sie Workshops auch als Change-Maßnahme: z. B. zeigen Sie schon Mockups oder Demo-Systeme, um Neugier zu wecken. Sorgen Sie für „Quick Wins“ – Anforderungen, die schnell spürbare Erleichterung bringen, priorisieren, damit die Nutzer früh positiv beeinflusst werden. Und: Schulen Sie die Leute im Vorfeld (z. B. „Was ist CAFM überhaupt?“), damit sie kompetent Anforderungen formulieren können. Ein informierter Nutzer liefert bessere Anforderungen.

• Herausforderung: Externe Dienstleister einbeziehen. In FM sind oft Fremdfirmen involviert (Reinigungsdienst, Wartungsfirmen). Deren Anforderungen (z. B. an eine Schnittstelle oder ans mobile Arbeiten) werden gerne vergessen, da sie nicht im Haus sind.

• Best Practice: In Lieferverträgen verpflichten und gezielt abfragen. Man kann Haupt-Dienstleister bitten, Anforderungen an das CAFM zu nennen (etwa: „Wir als Wartungsfirma brauchen eine Möglichkeit, unsere Einsatzberichte ins System hochzuladen“). Im Idealfall bindet man einen Vertreter der größten Dienstleister in einen Workshop ein. So vermeidet man, ein System einzuführen, das an der Praxis der Dienstleister vorbei geht (z. B. die Reinigung hat keine Smartphones, aber das System würde es verlangen – dann muss man Lösungen finden).

Orientierung an Normen und Standards: Nutzen Sie verfügbare Leitfäden als Checkliste. Das gibt Sicherheit, nichts Essenzielles zu übersehen. - Zeit genug einplanen: Anforderungserhebung braucht Zeit. Je nach Projektgröße können es mehrere Wochen bis Monate sein. Planen Sie Puffer ein und fangen Sie früh an – es lohnt sich, hier gründlich zu sein, um später nicht mit teuren Change Requests konfrontiert zu werden. - Erfahrung nutzen: Sprechen Sie mit anderen Unternehmen, die CAFM eingeführt haben, über deren Lessons Learned. Oft erhält man wertvolle Hinweise (z. B. „Wir hätten damals mehr auf Datenqualität achten sollen“ – daraus lernt man und schreibt strengere Anforderungen an die Datenmigration). - Daten nicht vergessen: Neben Funktionen immer an die Daten denken – Welche Daten sind für die Funktion nötig, liegen die vor, in welcher Qualität? Anforderungen an Datenübernahme und -aufbereitung sind absolut erfolgskritisch (man sagt: „Garbage in, garbage out“). Daher Anforderung: „Vor Projektstart ist ein vollständiges Raum- und Anlagenverzeichnis zu erstellen“ oder „Anlagen erhalten Eindeutige IDs nach Schema XYZ“. Diese Arbeiten müssen ins Konzept integriert werden. - Flexibilität bewahren: Trotz aller Planung sollte man mental bereit sein, Anforderungen auch mal umzustoßen, wenn sich herausstellt, dass sie falsch waren. Vielleicht merkt man im Zuge einer Testinstallation, dass ein gefordertes Feature unpraktisch ist – dann korrigieren. Anforderungen sind kein Selbstzweck, sondern sollen Nutzen stiften. Also regelmäßig prüfen: Erfüllt diese Anforderung ein echtes Bedürfnis? Und ist das Bedürfnis noch aktuell?

Es ist die Anforderungserhebung für CAFM-Systeme eine anspruchsvolle, aber enorm wichtige Phase. Sie entscheidet maßgeblich über Budgettreue, Termintreue und Nutzen des späteren Systems. Mit klarer Zielorientierung, umfassender Stakeholder-Einbindung, strukturiertem Vorgehen und sorgfältiger Dokumentation lassen sich die typischen Klippen umschiffen. Dann wird das Lastenheft zum robusten Fundament, auf dem die erfolgreiche CAFM-Implementierung aufbauen kann – nachvollziehbar, prüfbar und zielgerichtet. Best Practice lässt sich in einem Satz zusammenfassen: Investieren Sie in gute Anforderungen, denn sie zahlen sich im gesamten Projektverlauf vielfach aus. (Wer hier spart, zahlt später drauf in Form von Fehlkonfigurationen, Akzeptanzproblemen und steigenden Kosten). Dem ist nichts hinzuzufügen – außer: Viel Erfolg beim Anforderungserheben!