CAFM: Lastenheft/Backlog und Priorisierung

Lastenheft und Product Backlog unterscheiden sich vor allem in ihrer Herangehensweise und Dynamik, obwohl beide die Anforderungen adressieren.

Das Lastenheft ist eher statisch und umfassend, während der Backlog dynamisch und evolvierend ist. Beide Ansätze lassen sich kombinieren – ein Lastenheft liefert oft die erste Anforderungssammlung, die dann im agilen Projekt in einen lebenden Backlog überführt wird. Wichtig ist, in klassischen Projekten trotz Lastenheft Flexibilität für Änderungen zu bewahren (durch Updates und Change-Management) und in agilen Projekten trotz Backlog einen Gesamtüberblick zu behalten (durch initiale Vision und regelmäßige Backlog-Pflege).

Ein CAFM-Lastenheft gliedert sich üblicherweise in bestimmte Abschnitte, um alle relevanten funktionalen, technischen und regulatorischen Anforderungen systematisch abzudecken. Laut GEFMA beschreibt ein Lastenheft alle funktionalen und ablauforientierten Anforderungen an die Software, ihre Schnittstellen sowie den Implementierungsprozess. Außerdem muss es ein Mengengerüst enthalten, also Umfangszahlen zu geplanten Nutzern und zu verwaltenden Objekten/Daten, damit Anbieter die Größenordnung erkennen.

• Projektübersicht und Zielsetzung: Beschreibung des Projektumfangs und der Ziele des CAFM-Projekts. Hier wird festgelegt, was das System leisten soll und warum (z.B. Effizienzsteigerung, Kostentransparenz, bessere Datenqualität). Auch eine Abgrenzung des Scopes (welche FM-Bereiche werden abgedeckt, welche zunächst nicht) wird beschrieben. Zudem gehören ein Überblick über die Ausgangslage und relevante Kennzahlen dazu (z.B. Anzahl Liegenschaften, Nutzer, erwartete Datensätze).

• Rechtliche Rahmenbedingungen: Auflistung aller einschlägigen Gesetze, Normen und Richtlinien, die das CAFM-System unterstützen oder einhalten muss. Dazu zählen z.B. Betreiberpflichten nach Arbeitsstättenverordnung oder Prüfvorschriften, Datenschutzanforderungen (DSGVO bei personenbezogenen FM-Daten), bau- und brandschutzrechtliche Vorgaben sowie FM-spezifische Standards. Beispiel: Flächenmanagement muss DIN 277-konform sein (Flächen nach Nutzungsarten). GEFMA-Richtlinien (wie GEFMA 444) oder ISO-Standards (ISO 41001 für FM-Managementsysteme) werden hier ebenfalls genannt, soweit relevant. Dieser Abschnitt stellt sicher, dass das System zur Compliance beiträgt und der Betreiber seine Pflichten erfüllen kann.

• Organisatorische Ausgangslage: Darstellung der aktuellen FM-Organisation und Prozesse im Unternehmen. Hier werden die bestehenden Abläufe, Verantwortlichkeiten und Schwerpunkte im Facility Management beschrieben: z.B. Anzahl und Art der Gebäude/Standorte, interne vs. externe Leistungserbringung, aktuelle Schmerzpunkte (Medienbrüche, Insellösungen). Wichtig ist auch die Angabe der Nutzergruppen und -anzahl (z.B. wie viele Sachbearbeiter, Techniker, extern Dienstleister das System nutzen sollen), da dies Lizenzen und Dimensionierung beeinflusst. Dieser Teil bildet die Brücke zur Ist-Analyse: Er zeigt, an welchen Stellen im Ablauf das CAFM-System unterstützen soll und wo eventuell organisatorische Änderungen notwendig sind.

• Technische Anforderungen: Beschreibung der vorhandenen und geforderten IT-Rahmenbedingungen. Dazu gehört die Entscheidung Cloud vs. On-Premises, vorhandene Server- und Datenbank-Infrastruktur, Betriebssysteme, Netzwerk (für standortübergreifenden Einsatz) und Endgeräte. Ebenso werden bestehende IT-Sicherheitsvorgaben (z.B. Passwortrichtlinien, VPN-Nutzung) und Identity-Management-Systeme (etwa Active Directory für SSO) dokumentiert. Ziel: Das Lastenheft stellt sicher, dass das neue CAFM-System in die vorhandene IT-Landschaft passt und mit ihr kompatibel ist. Beispiel: Ist Cloud-Software aus Datenschutzgründen unerwünscht, muss On-Premise-Betrieb als Voraussetzung definiert sein. Ebenso können hier Mindestanforderungen (Browserunterstützung, mobile Geräte, Schnittstellenprotokolle) festgelegt werden.

• Fachliche (funktionale) Anforderungen: Dies ist der Kern des Lastenhefts – der Anforderungskatalog der CAFM-Funktionen und Module. Ausgehend von den FM-Prozessen wird beschrieben, welche Anwendungsbereiche das CAFM-System abdecken soll. Übliche Module sind etwa: Flächenmanagement, Instandhaltungsmanagement (Wartungsplanung), Reinigungsmanagement, Schlüssel- und Zugangsverwaltung, Reservierungs- und Buchungsmanagement, Inventar- und Umzugsmanagement, Energiemanagement, Arbeitsschutz, Vertrags- und Budgetverwaltung, Helpdesk/Ticketing usw. Für das konkrete Projekt wird festgelegt, welche dieser Bereiche relevant sind und in welcher Priorität (Reihenfolge der Umsetzung). Jede funktionale Anforderung wird idealerweise klar beschrieben und priorisiert. So könnten z.B. „Prüfungsplanung für technische Anlagen“ als Muss-Anforderung und „Raumbuchungsmanagement“ als Kann-Anforderung (für eine spätere Ausbaustufe) markiert werden. Dieser Abschnitt sollte nichts Wesentliches vergessen – hier helfen anerkannte Kriterienkataloge wie GEFMA 444 als Checkliste für typische CAFM-Funktionen. Zudem muss entschieden werden, welche Module sofort ab Tag 1 eingeführt werden und was evtl. später folgt, um das Projekt nicht zu überfrachten.

• Schnittstellen zu anderen IT-Systemen: Darstellung der Integrationsanforderungen – also mit welchen bestehenden Systemen das CAFM kommunizieren muss. Typische Schnittstellen sind z.B. ERP-Systeme (SAP für Finanzbuchhaltung oder HR-Daten), Gebäudeleittechnik (GLT/BMS für Störmeldungen und Zählerstände), CAD-/BIM-Systeme (für Flächen- und Anlagenpläne), IoT-Sensorik (z.B. Zähler, Raumklima), Zugangskontrollsysteme, Energiemonitoring-Tools oder Dokumentenmanagement-Systeme. Für jede Schnittstelle wird beschrieben: Welche Daten werden ausgetauscht? In welchem Format und wie häufig (Echtzeit vs. Batch)?. Dieser Abschnitt ist wichtig, um Doppelarbeit zu vermeiden und die nahtlose Einbettung in die IT-Landschaft sicherzustellen. Beispiel: Wenn bereits ein ERP mit Anlagenbuchhaltung existiert, soll das CAFM diese Daten übernehmen statt redundant zu pflegen. Auch hier erfolgt eine Priorisierung: Kritische Schnittstellen (etwa der Import von Stammdaten wie Räumen oder Personal) werden als Muss für den Projektstart markiert, andere können später implementiert werden.

• Datengrundlagen und Migration: Beschreibung des Ist-Datenbestands und der Anforderungen an Datenübernahme. Es wird aufgelistet, welche Bestandsdaten vorliegen (z.B. Excel-Listen von Anlagen, CAD-Zeichnungen der Gebäude, Vertragsdatenbanken) und in welcher Qualität bzw. Struktur. Wichtig sind auch einheitliche Schlüssel und Nomenklaturen (Raum- und Gebäudecodes, Bezeichnungen), da ggf. erst Standards eingeführt werden müssen. Das Lastenheft muss klären, wie die Datenmigration ins neue System ablaufen soll und welche Vorarbeiten nötig sind. Beispiel: Wenn CAD-Pläne vorhanden sind, können Räume daraus automatisch übernommen werden; fehlen sie, muss man Zeit für händische Nacherfassung einplanen. Hier wird auch entschieden, welche Daten unbedingt migriert werden (z.B. alle laufenden Wartungsverträge) und welche eventuell erstmal nicht (Archivdaten). Dieser Abschnitt beeinflusst die Aufwandsschätzung erheblich, denn der Umfang und die Qualität der Daten entscheiden über den Migrationsaufwand.

• Berichtswesen und Kennzahlen: Definition der Anforderungen an Reports, Auswertungen und Dashboards. Das CAFM-System soll dem FM-Team und Management wichtige Kennzahlen liefern – daher wird festgelegt, welche Key Performance Indicators (KPIs) regelmäßig benötigt werden. Beispiele: Flächenauslastung nach DIN 277, Anzahl und Status offener Tickets, Wartungsrückstände, Reinigungskosten pro m², Energieverbräuche und Emissionen (für Nachhaltigkeitsberichte). Ebenso wird bestimmt, welche Berichtsformate gewünscht sind (tabellarisch, grafisch, Exporte nach Excel/PDF) und in welchen Intervallen (z.B. monatlich, jährlich, ad-hoc). Ohne klare Vorgaben könnte es passieren, dass das gewählte System wichtige Kennzahlen nicht auf Knopfdruck liefern kann. Dieser Abschnitt stellt also sicher, dass Transparenz erreicht wird – einer der Hauptnutzen von CAFM. Priorisiert wird auch hier: Unverzichtbare Berichte zum Go-Live (etwa Flächen- und Wartungsstatusübersichten) werden definiert, zusätzliche können als Kann-Anforderungen aufgenommen werden.

• Betrieb und Support: Festlegung der Betriebsmodelle und Service-Anforderungen für das System. Hier wird beschrieben, wer für den laufenden Betrieb zuständig ist (interne IT, externer SaaS-Anbieter) und welche Supportzeiten/SLA gelten sollen. Beispielsweise muss definiert werden, ob ein 24/7-Zugriff erforderlich ist oder Wartungsfenster nur außerhalb der Geschäftszeiten zulässig sind. Auch Aspekte wie Update- und Release-Management (Häufigkeit von Updates, Testverfahren), Backup und Disaster Recovery und Performance-Anforderungen werden hier adressiert. So kann im Vertrag später eine Mindestverfügbarkeit (z.B. 99% uptime) und Reaktionszeit bei Störungen festgeschrieben werden. Dieser Teil ist wichtig, damit das CAFM-System im Alltag zuverlässig läuft und etwaige Ausfälle das FM-Tagesgeschäft nicht lahmlegen.

• Sicherheit und Berechtigungen: Beschreibung der IT-Sicherheitsanforderungen und Zugriffskonzepte. Das Lastenheft listet auf, welche sensiblen Daten im System liegen werden (z.B. Mitarbeiterdaten, vertrauliche Vertragsdokumente, Schließplandaten) und welche Schutzmaßnahmen erwartet werden. Themen sind z.B. Rechte- und Rollenkonzepte (wer darf was sehen/tun?), Authentifizierung (Single Sign-On, Zwei-Faktor-Authentisierung?), Protokollierung (Audit-Trails) und Datenschutz (Mandantentrennung, Löschkonzepte gemäß DSGVO). Hier werden unternehmensinterne Sicherheitsrichtlinien umgesetzt. Beispiel: Es kann gefordert werden, dass externe Dienstleister nur lesenden Zugriff auf bestimmte Bereiche erhalten, oder dass alle Zugriffe protokolliert und 6 Monate aufbewahrt werden. Ohne einen eigenen Abschnitt zu Sicherheit würden Angebote möglicherweise Lösungen vorschlagen, die den Compliance-Vorgaben des Unternehmens nicht genügen.

• Budget und Wirtschaftlichkeit: Angabe des vorgesehenen Budgets für die CAFM-Einführung und die laufenden Betriebskosten. Hier werden die Kostenrahmen für Software (Kauf oder Miete), Implementierung (Beratung, Schulung, Datenübernahme) und jährlicher Betrieb festgehalten. Ebenso wird der Nutzen quantifiziert, soweit möglich – beispielsweise erwartete Einsparungen oder Effizienzgewinne, ggf. gestützt durch eine Wirtschaftlichkeitsrechnung (wie GEFMA 460). Dieser Abschnitt sorgt für Realitätssinn: Es wird verhindert, dass das Lastenheft “überzogene Anforderungen” enthält, die kein Anbieter im vorgegebenen Budget erfüllen kann. Umgekehrt hilft es, Einsparpotenziale zu erkennen. Entscheidungen in diesem Bereich können sein: Lieber ein kleineres Modulumfang, dafür im Budget bleiben? Oder ein höheres Budget freigeben, um mehr Automatisierung zu erhalten? Insgesamt stellt die Budgetangabe sicher, dass Kosten und Nutzen im Verhältnis stehen und der ROI des Projekts später bewertet werden kann.

Zusätzlich können Anhänge oder spezielle Kapitel Teil des Lastenhefts sein, etwa ein Glossar der Fachbegriffe, Beispielberichte, Mustereingabemasken, etc. Wichtig ist, dass das Lastenheft systemneutral formuliert ist – es beschreibt Was benötigt wird und wozu, nicht welche konkrete Lösung oder Technologie einzusetzen ist. Wie die Lösung umgesetzt wird, ist Gegenstand des Pflichtenhefts bzw. der Anbietervorschläge.

Bei der Erstellung des Lastenhefts sollte man sich an bewährte Formatierungs- und Dokumentationsstandards orientieren, um Vollständigkeit und Vergleichbarkeit sicherzustellen.

• DIN 69901-5 (Projektmanagement-Begriffe): Diese Norm liefert die offizielle Definition von Lastenheft und Pflichtenheft. Danach ist das Lastenheft die „vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrags“. Das Pflichtenheft hingegen enthält die vom Auftragnehmer erarbeiteten Realisierungsvorgaben als Antwort auf das Lastenheft. Aus der Norm und verwandten Standards ergeben sich Anforderungen an den Aufbau: Ein Lastenheft sollte mindestens Projektbeschreibung, Ausgangssituation, Ziele, Anforderungen und Rahmenbedingungen enthalten. Diese klare Struktur nach DIN gewährleistet, dass nichts Wichtiges vergessen wird und das Dokument als vollständige Anforderungsspezifikation dient.

• GEFMA-Richtlinien: In Deutschland gibt der Verband GEFMA (German Facility Management Association) Leitfäden speziell für FM und CAFM heraus. Für Lastenhefte sind insbesondere zwei Dinge relevant: GEFMA 444 und das GEFMA-CAFM-Handbuch. GEFMA 444 enthält einen Katalog von Kriterien für CAFM-Software, der als Checkliste genutzt werden kann, um alle relevanten Funktionen im Lastenheft abzudecken. Viele Unternehmen orientieren sich an diesen 18 Kriterienkatalogen der GEFMA 444, um sicherzustellen, dass z.B. Module für Flächenmanagement, Instandhaltung, Schlüsselverwaltung etc. bedacht wurden. Außerdem beschreibt das GEFMA-Handbuch Best Practices zur Einführung von CAFM-Systemen, einschließlich der Empfehlung eines Stufenplans und der Inhalte eines Lastenhefts. Auch GEFMA 940 (Marktübersicht) kann indirekt helfen: Die dort gelisteten Funktionen und Marktstandards geben Hinweise, welche Anforderungen üblich und realistisch sind. Nicht zuletzt gibt GEFMA mit Richtlinie GEFMA 460 einen Standard für Wirtschaftlichkeitsberechnung vor, der – wie oben erwähnt – im Budget-Teil eines Lastenhefts herangezogen werden kann.

• VDI-Richtlinien und DIN-Normen im FM-Kontext: Je nach Anwendungsgebiet kann es sinnvoll sein, Lastenheft-Inhalte an technischen Richtlinien auszurichten. Beispiel: Die VDI 3814 (Gebäudeautomation) definiert Anforderungen an Schnittstellen zwischen CAFM und GLT – wird ein solches Zusammenspiel gefordert, sollte das Lastenheft darauf Bezug nehmen. Für Flächenmanagement ist die DIN 277 relevant (Begriffe und Kennzahlen zur Flächendefinition) – ein Lastenheft sollte die Einhaltung dieser Norm fordern, um einheitliche Flächenberechnungen zu gewährleisten. Weitere Beispiele: VDI 3810 Blatt 5 / GEFMA 922 für Betreiberverantwortung beschreibt, wie Bedarfsplanung, Betreiberkonzepte und Lastenhefte für Gebäudebetrieb aussehen sollten; DIN EN ISO 41001 liefert Rahmen für ein FM-Managementsystem – das Lastenheft könnte fordern, dass das CAFM-System dabei unterstützt. DIN V 18599 (Energieeffizienz von Gebäuden) könnte relevante Kennzahlen vorgeben, falls Energiemanagement Teil des Umfangs ist, usw. Kurz: Branchenstandards sollten im Lastenheft referenziert werden, um sicherzustellen, dass das System die branchentypischen Anforderungen erfüllt.

• Dokumentations- und Formatierungsrichtlinien: Unabhängig vom inhaltlichen Standard lohnt es sich, einheitliche Formatierung zu nutzen. Dazu zählt die Nummerierung aller Anforderungen (z.B. FUN-01 für eine funktionale Anforderung, NFR-05 für eine nicht-funktionale), damit man in Angeboten und späteren Tests eindeutig darauf referenzieren kann. Zudem sollte ein Änderungs- bzw. Versionskontrollkapitel vorhanden sein, in dem festgehalten ist, wann welche Version des Lastenhefts erstellt oder angepasst wurde. Viele Unternehmen greifen auf Vorlagen zurück – beispielsweise liefern öffentliche Auftraggeber manchmal ein Gliederungsgerüst nach dem V-Modell XT oder nutzen Standards wie HERMES in der Schweiz. Wichtig ist, dass die Dokumentation konsistent und prüfbar ist: Jede Anforderung sollte ein Prüfmaß oder Abnahmekriterium bekommen, damit klar ist, wann sie erfüllt ist. Auch empfiehlt es sich, zu jeder Anforderung die Priorität und ggf. Verantwortlichkeiten anzugeben. Moderne Tools (Requirements-Engineering-Software, Wiki-Plattformen) können helfen, Formatierungsstandards einzuhalten und gemeinsam an dem Dokument zu arbeiten.

Zusammenfassend sollte man sich bei Format und Inhalt des Lastenhefts an den gängigen Normen orientieren (um Vollständigkeit und Anerkennung sicherzustellen) und hausinterne Vorgaben nicht vergessen (manche Unternehmen haben eigene Styleguides für Ausschreibungsdokumente). In der Praxis hat sich ein Aufbau bewährt, der sich an DIN/V-Modell orientiert und alle oben genannten Kapitel enthält. So wird das Lastenheft zu einem strukturierten, nachvollziehbaren Dokument, das als „roter Faden“ der CAFM-Einführung dient.

Die Inhalte des Lastenhefts entstehen nicht im luftleeren Raum – sie sind direktes Ergebnis der Ist-/Soll-Analyse und der Anforderungserhebungs-Workshops. In der Ist-Analyse werden die bestehenden Prozesse, Systeme und Pain Points des aktuellen Facility Managements erfasst. In der Soll-Analyse wird definiert, wie diese Prozesse künftig aussehen sollen und welche Lücken die neue Software schließen muss.

• Prozessergebnisse übernehmen: Die Analyse der bestehenden FM-Prozesse ist „ein zentraler Bestandteil des Lastenhefts“. Das Lastenheft dokumentiert zu jedem relevanten Prozess, wo genau das CAFM-System unterstützen soll. Zum Beispiel könnte aus der Ist-Analyse hervorgehen, dass der Prozess „Instandhaltung planen“ heute manuell (auf Papier) erfolgt. In der Soll-Definition wird festgelegt, dass das CAFM diesen Prozess digital unterstützen soll (Wartungsplanung mit automatischen Erinnerungen). Entsprechend findet sich im Lastenheft die Anforderung „Das System muss die Planung und Verfolgung wiederkehrender Wartungen ermöglichen“. Praxis-Tipp: Es ist hilfreich, im Lastenheft auf die Herkunft wichtiger Anforderungen zu verweisen – etwa mit Kommentaren wie (Ergebnis Workshop Wartungsprozess, 12.01.). So sieht man, dass die Forderungen auf echter Prozessanalyse basieren.

• Ist-Systeme und Schnittstellen ableiten: Die Dokumentation der gegenwärtigen IT-Umgebung im Lastenheft stellt sicher, dass alle vorhandenen Systeme für Schnittstellen betrachtet werden. Aus der Ist-Analyse weiß man z.B., dass bereits eine digitale Schließanlage oder ein Energie-Monitoring-Tool existiert. Das Lastenheft übernimmt diese Info und spezifiziert: „Schnittstelle zur bestehenden Schließanlagensoftware XYZ: automatisierter Import von Zutrittslogs.“ Ebenso wird berücksichtigt, welche Datenquellen aktuell geführt werden – etwa Excel-Listen für Reinigungspläne – und fordert eine Migration oder Integration. Merke: Was in Ist/Soll als kritisch identifiziert wurde (z.B. Doppelerfassungen in zwei Systemen), muss sich im Lastenheft wiederfinden (Forderung nach einer führenden Datenquelle).

• Soll-Konzept verankern: Die Soll-Analyse definiert oft ein zukünftiges Konzept (inkl. optimierter Prozesse). Das Lastenheft dient dazu, dieses Soll-Konzept verbindlich festzuschreiben, damit der Anbieter es umsetzen kann. Beispiel: In der Soll-Konzeption wurde entschieden, einen zentralen FM-Helpdesk einzuführen. Das Lastenheft enthält daher Anforderungen wie „Das CAFM-System muss ein zentrales Störungs- und Auftragsmanagement (Helpdesk) bereitstellen, über das alle FM-Meldungen erfasst und nachverfolgt werden können“. Diese Anforderung stammt direkt aus der erarbeiteten Soll-Vorstellung des Support-Prozesses.

• Priorisierung aus der Strategie ableiten: In der Konzeptionsphase werden meist Etappen oder Phasen geplant (Stufenplan der CAFM-Einführung). Diese Prioritäten der Soll-Konzeption sollten sich 1:1 im Lastenheft widerspiegeln. Wenn z.B. beschlossen wurde, zuerst Flächen- und Reinigungsmanagement zu digitalisieren und später die Vertragsverwaltung, dann sind die Anforderungen im Lastenheft entsprechend mit „Phase 1“ bzw. „Phase 2“ gekennzeichnet oder als Muss/Kann priorisiert. Somit dient das Lastenheft auch als Brücke von der strategischen Roadmap zur operativen Umsetzung.

• Anforderungserhebung und Workshops: Während der Anforderungserhebung (Interviews mit Nutzern, Workshops mit Stakeholdern) werden viele Details gesammelt. Diese sollten im Lastenheft konsolidiert festgehalten werden. Eine gute Praxis ist es, Einzelanforderungen in Clustern zu bündeln (z.B. alle Wünsche der Haustechnik zusammenfassen unter „Instandhaltungsmodul“). Die Rohinformationen aus Workshops (oft in Form von Whiteboards, Notizen, User Stories) werden im Lastenheft formalisiert. Hier zahlt sich eine zentrale Sammlung aus: „Erfassen Sie den Input aller Beteiligten möglichst zentral und einheitlich. Das hilft dabei, aus den Einzelinteressen einen Gesamtanforderungskatalog für das System zu erstellen.“. Dieser Rat unterstreicht, wie wichtig es ist, die Vielzahl an Anforderungen aus der Erhebung zu harmonisieren und Doppelungen oder Konflikte aufzulösen, bevor sie ins Lastenheft kommen.

Alles, was in der Analysephase erarbeitet wurde – seien es Prozessdiagramme, Schwachstellenlisten, Optimierungsideen oder Systemlandschaftszeichnungen – fließt in strukturierter Form hinein. Dadurch garantiert man die Rückverfolgbarkeit: Jede Anforderung im Lastenheft lässt sich (idealerweise) auf einen Bedarf aus der Analyse zurückführen. Im Umkehrschluss sollte jeder identifizierte Bedarf auch irgendwo im Lastenheft oder Backlog wiederzufinden sein, damit nichts verloren geht.

Nicht alle Anforderungen sind gleich wichtig. Deshalb ist es entscheidend, im Lastenheft bzw. Backlog eine Priorisierung vorzunehmen. Dadurch wird sichtbar, was für den Projekterfolg unverzichtbar ist und was nachrangig behandelt werden kann.

• MoSCoW-Methode (Muss, Soll, Kann, Won’t): Diese aus dem Requirements Engineering stammende Methode kategorisiert Anforderungen in vier Prioritätsstufen. In deutscher Adaption spricht man oft von Muss-, Soll- und Kann-Anforderungen (Won’t bzw. „später“ wird seltener explizit aufgeführt).

• Muss-Kriterien (Must): Anforderungen, die zwingend erfüllt werden müssen, damit das System akzeptabel ist. Werden Muss-Anforderungen nicht erfüllt, ist das Projektziel verfehlt. Beispiel: „Einhaltung der DSGVO-Bestimmungen“ oder „Kernmodul Instandhaltung muss vorhanden sein“.

• Soll-Kriterien (Should): Sehr wichtige Anforderungen, die möglichst erfüllt werden sollen, die aber notfalls durch Workarounds kompensiert werden könnten. Hier handelt es sich oft um Features, die den Nutzen erhöhen, aber bei Nicht-Erfüllung das Projekt nicht scheitern lassen. Beispiel: „Modul Schlüsselmanagement sollte verfügbar sein“ – falls nicht, könnte man übergangsweise extern verwalten, aber es wäre stark wünschenswert.

• Kann-Kriterien (Could): Optionale Anforderungen, nice-to-have Features, die bei Gelegenheit mit umgesetzt werden können, aber keine unmittelbare Priorität genießen. Beispiel: „Smartphone-App für Raumbuchungen könnte unterstützt werden.“

• Won’t (oder „Wunschliste“): Dinge, die bewusst nicht in diesem Projekt umgesetzt werden, aber eventuell in Zukunft (oft verzichtet man auf diese Kategorie im Dokument und behandelt es in der Roadmap).

Die MoSCoW-Klassifizierung wird im Lastenheft häufig in einer eigenen Spalte oder Klammerangabe je Anforderung kenntlich gemacht. Im CAFM-Umfeld ist das z.B. in Anforderungskatalogen üblich – so könnten sämtliche gewünschten Grundfunktionen erstmal aufgelistet und dann mit (M), (S) oder (K) markiert werden. Vorteil: Bei der Bewertung von Anbietern kann man Muss-Kriterien als K.O.-Kriterien nehmen (jeder Anbieter, der auch nur eine Muss-Anforderung nicht erfüllt, scheidet aus) und Soll/Kann-Kriterien in die Punktebewertung einfließen lassen. Zudem hilft es intern bei der Phasenplanung: Muss = Phase 1, Soll = Phase 1 (wenn möglich) oder Phase 2, Kann = Phase 2/später. Als Best Practice sollte man wirklich sparsam mit Muss-Kriterien umgehen – nur das absolut Lebenswichtige als Muss definieren. Andernfalls läuft man Gefahr, den Spielraum für Lösungen zu sehr einzuengen („Verzichten Sie darauf, alle gewünschten Funktionalitäten als MUSS-Kriterien zu definieren“).

• Priorisierung nach Business Value: Besonders in agilen Projekten priorisiert der Product Owner den Backlog nach dem geschäftlichen Mehrwert jeder Anforderung. Features, die einen hohen Nutzen oder ROI versprechen, kommen zuerst dran. Dabei fließen mehrere Überlegungen ein: Wie stark verbessert diese Funktion unsere Abläufe oder senkt Kosten? Wie wichtig ist sie für die Nutzerzufriedenheit? Methoden wie Kano-Analyse (Basis-, Leistungs- und Begeisterungsmerkmale) können helfen einzuschätzen, welche Features Kunden wirklich begeistern oder frustrieren würden. In klassischen Lastenheften kann man Business Value ebenfalls berücksichtigen, etwa indem man jeder Anforderung einen Nutzen-Score gibt oder sie bestimmten Nutzenzielen zuordnet. Beispielsweise könnte man vermerken: „(Geschäftswert: Hoch – spart voraussichtlich 50k€ p.a.)“ für eine Anforderung. Letztlich soll der Fokus darauf liegen, mit begrenzten Ressourcen das Meiste für das Unternehmen herauszuholen. In Scrum ist es ausdrücklich Aufgabe des Product Owners, die Backlog-Einträge nach Wertschöpfung fürs Unternehmen zu ordnen. Dabei werden oft Nutzen und Kosten sowie Risiko gemeinsam betrachtet.

• Aufwand-Nutzen-Matrix: Eine pragmatische Methode zur Priorisierung – oft auch in Kombination mit Business Value – ist die Betrachtung des Verhältnisses von Aufwand zu Nutzen. Man kann Anforderungen z.B. in einem Koordinatensystem plotten: X-Achse = Aufwand (Cost), Y-Achse = Nutzen (Value). Die Anforderungen, die einen hohen Nutzen bei relativ geringem Aufwand bringen („Quick Wins“), sollten bevorzugt umgesetzt werden. Dinge mit hohem Aufwand und geringem Nutzen fallen ggf. weg („Low Value“). Dieses Vorgehen ist besonders hilfreich, wenn viele Soll- und Kann-Anforderungen vorhanden sind und man entscheiden muss, was in den ersten Rollout kommt. In agilen Teams geschieht diese Abwägung informell vor jedem Sprint. In der Dokumentation (Lastenheft) kann man zumindest qualitativ den Aufwand (z.B. als S/M/L oder in Personentagen grob) hinzufügen, um Entscheidungen zu untermauern. Beispiel: „Implementierung Gebäude-IoT-Sensorik (Kann) – hoher Aufwand; Nutzen aktuell mittel – → eher nachrangig.“ Atlassian empfiehlt diese Aufwand-Wirkungs-Abwägung ausdrücklich als Teil des Backlog-Managements.

• Risikobasierte Priorisierung: Gerade bei großen Systemeinführungen kann es sinnvoll sein, Anforderungen auch nach dem Projektrisiko zu priorisieren. Ideen: Anforderungen, die mit höchstem Risiko behaftet sind (technisch komplex, unklare Datenlage, Abhängigkeiten), vielleicht früher umsetzen, um schnell Erkenntnisse zu gewinnen („fail early“), oder bewusst später, um erst andere Voraussetzungen zu klären – je nach Kontext. Im Backlog-Umfeld fließt Risiko oft in Methoden wie WSJF (Weighted Shortest Job First) ein: Hier berechnet man eine Prioritätszahl aus (Business Value + Zeitkritikalität + Risikoreduktion) / Aufwand. Damit werden z.B. Aufgaben bevorzugt, die Risiken deutlich reduzieren. Für Lastenhefte kann man Risiko als Attribut jeder Anforderung festhalten (Risiko: hoch/mittel/niedrig). Das ist in Ausschreibungen eher unüblich, aber intern für die Projektplanung hilfreich. Gängiger ist, Risiko im Rahmen der Phasenplanung zu betrachten, z.B. ein Pilotprojekt für riskante Teile vorzusehen.

In der Praxis werden diese Methoden oft kombiniert. Ein Product Owner priorisiert z.B. nach Geschäftswert, berücksichtigt aber auch Aufwand und Risiko, wie im Scrum-Guide beschrieben: „Er [der PO] priorisiert die Inhalte auch basierend auf deren Wertschöpfung fürs Unternehmen (Business Value). Dabei sind neben Nutzen und Kosten auch das Risiko und ggf. weitere Faktoren von Bedeutung.“. Im Lastenheft-Kontext ist es wichtig, zumindest die Muss-Kriterien klar zu benennen und eine grobe Vorstellung zu haben, welche Anforderungen zuerst umgesetzt werden sollen. Oft hilft hier die MoSCoW-Liste als Kommunikationstool mit den Anbietern: Man kann den Bietern mitteilen, welche Punkte Priorität haben (damit diese z.B. in ihrem Projektplan die Muss-Themen in eine frühe Phase legen). Zusammengefasst sorgt Priorisierung dafür, dass wichtige Anforderungen nicht in der Masse untergehen und dass das Projektteam – wie auch die Anbieter – ihren Fokus richtig setzen.

Bei Ausschreibungen und Software-Auswahlprozessen (insbesondere im öffentlichen Sektor, aber auch in vielen Unternehmen) ist es üblich, Anforderungen in Muss-, Soll- und Kann-Kriterien einzuteilen.

• Muss-Kriterien (= Ausschlusskriterien): Diese Anforderungen müssen vom Anbieter erfüllt werden, damit er überhaupt in Betracht kommt. Sie sind nicht verhandelbar. In der Ausschreibungspraxis wird oft eine Liste von Muss-Kriterien angegeben, die jeder Bieter in seinem Pflichtenheft oder Angebot eindeutig bestätigen muss (häufig durch einfache Ja/Nein-Angabe oder Erläuterung). Beispiel: „Das CAFM-System muss mehrmandantenfähig sein.“ Erfüllt ein Anbieter dieses Muss-Kriterium nicht, scheidet er aus dem weiteren Vergabeverfahren aus. Muss-Kriterien sollten wirklich nur die unabdingbaren Mindestanforderungen enthalten – etwa regulatorische Vorgaben (z.B. „System muss DSGVO-konform sein“), kritische Funktionen („Muss ein Wartungsplanungsmodul haben“) oder technische Grundlagen („Muss mit unserer Oracle-Datenbank laufen“ falls unternehmenskritisch). In der Praxis neigen manche dazu, eine Fülle von Punkten als Muss zu deklarieren, um auf Nummer sicher zu gehen. Davor wird jedoch gewarnt: Wenn alle gewünschten Features Muss sind, gibt es kaum Differenzierungsmöglichkeiten und evtl. keinen Anbieter, der alles erfüllt. Best Practice: Muss-Kriterien knapp halten und wirklich nur die K.O.-Kriterien aufnehmen.

• Soll-Kriterien (= Wertungskriterien): Anforderungen, die sollten erfüllt werden, aber bei Nicht-Erfüllung nicht zum automatischen Ausschluss führen. Diese fließen üblicherweise in die Bewertung der Angebote ein. Jeder Anbieter gibt an (qualitativ oder mit Erfüllungsgrad), inwieweit er die Soll-Anforderungen erfüllt, und erhält dafür Punkte. Soll-Kriterien sind oft wichtige Leistungsmerkmale, die die Qualität der Lösung ausmachen, aber unterschiedlich von den Bietern umgesetzt sein können. Beispiel: „Das System soll ein BIM-Modul zur Visualisierung von 3D-Gebäudemodellen bieten.“ Ein Anbieter mit dieser Funktion erhält dann z.B. die maximale Punktzahl, einer ohne diese Funktion weniger Punkte, scheidet aber nicht zwingend aus. Bei Soll-Kriterien ist es üblich, ein Bewertungsschema anzugeben – z.B. jede Soll-Anforderung wird mit 0, 1 oder 2 Punkten bewertet (0 = nicht erfüllt, 1 = teilweise, 2 = voll erfüllt) und mit einer Gewichtung multipliziert. So entsteht eine gewichtete Summe, die in die Angebotswertung einfließt. Wichtig: Soll-Anforderungen sollten so formuliert sein, dass man eine qualitative Abstufung bewerten kann. Also eher „soll unterstützen“, nicht binär. Z.B. „Das CAFM soll mobile Endgeräte unterstützen“ – hier kann ein Anbieter glänzen (voll offlinefähige App) oder minimal erfüllen (nur Webbrowser am Tablet); entsprechend differenziert man in der Bewertung.

• Kann-Kriterien (= optionale Boni): Anforderungen, die können erfüllt werden – Nice-to-have-Features. Diese werden häufig ebenfalls bewertet, aber mit geringerer Gewichtung oder sie dienen nur dem qualitativen Eindruck. Kann-Kriterien sind nützlich, um Innovationen der Anbieter nicht zu unterdrücken. Anbieter können beschreiben, welche zusätzlichen Funktionen sie anbieten, die über die Anforderungen hinausgehen. Das kann in einem Vergabeverfahren Bonuspunkte geben oder als Tiebreaker dienen. Beispiel: „Das System kann mittels IoT-Sensoren Raumbelegungsdaten in Echtzeit erfassen.“ Solche Dinge sind vielleicht nicht gefordert, aber ein Anbieter könnte es mitliefern und sich damit profilieren. In der Wertung könnte man dafür z.B. ein paar Zusatzpunkte vorsehen oder es fließt in die Gesamtbeurteilung der Lösung ein.

Die Mindestanforderungen (Muss) werden im Lastenheft/Ausschreibungstext klar definiert und müssen von allen erfüllt werden. Die Bewertungskriterien setzen sich dann aus Erfüllungsgraden der Soll- und Kann-Anforderungen, Preis und ggf. Präsentationsleistungen zusammen. Es empfiehlt sich, im Lastenheft selbst die Muss/Soll/Kann-Kennzeichnung vorzunehmen – so wissen die Anbieter genau, worauf es ankommt. Viele Lastenheft-Vorlagen haben hierfür eine Spalte oder man listet die Anforderungen getrennt nach Kategorien.

Der Umgang mit diesen Kategorien will gelernt sein. Best Practices: - Schlüssige Kriterien: Achten, dass Muss-Kriterien wirklich objektiv prüfbar sind (ja/nein). z.B. „Software ist GEFMA 444 zertifiziert (Muss)“ ist klar prüfbar. „Software ist benutzerfreundlich (Muss)“ wäre ungeeignet, weil subjektiv. - Nicht überfrachten: Man sollte nicht alles als Muss definieren. Es ist sinnvoll, nur Kernpunkte (z.B. Erfüllung aller gesetzlichen Pflichten, Module der Phase 1, essentielle Integrationen) als Muss zu setzen. Wenn man z.B. 100 Muss-Kriterien hat, ist die Chance groß, dass kein Bieter jeden Punkt zu 100% erfüllt oder die Angebote sehr ähnlich ausfallen (alle kreuzen formal „ja“ an, aber Unterschiede treten nicht zutage). - Transparenz: Geben Sie den Bietern idealerweise schon in den Ausschreibungsunterlagen einen Hinweis, wie die Gewichtung erfolgt (z.B. „Funktionale Soll-Anforderungen haben 40% Gewicht in der Bewertung“). So können Anbieter ihre Lösungsschwerpunkte darauf ausrichten und wissen, dass sie z.B. bei Kann-Kriterien nicht alle Register ziehen müssen, wenn es gar nicht bewertet wird. - Nachvollziehbarkeit: Dokumentieren Sie die Bewertung der Soll/Kann-Kriterien sorgfältig. Im Lastenheft kann dazu eine Bewertungsmatrix gehören oder man erstellt sie im Zuge der Angebotsauswertung. - Freiräume lassen: Lassen Sie durch Kann-Kriterien Raum für Angebote, die positiv überraschen. CAFM-Anbieter entwickeln sich ständig weiter; es kann Funktionen geben, an die Sie gar nicht gedacht haben, die aber nützlich sind. Diese sollten die Anbieter erwähnen dürfen, ohne dass sie ausgeschlossen sind, nur weil sie nicht im Lastenheft standen.

In internen Auswahlprozessen (ohne förmliche Ausschreibung) kann man Muss/Soll/Kann ähnlich nutzen, aber flexibler handhaben. Es geht letztlich darum, Entscheidungskriterien klar zu haben: Was ist unverzichtbar vs. wo kann man Abstriche machen? So bleibt der Auswahlprozess nachvollziehbar und fair.

Ein Lastenheft endet nicht bei der reinen Beschreibung der Anforderungen – es sollte auch festhalten, woran man später erkennt, dass eine Anforderung erfüllt wurde. Dazu werden Abnahmekriterien definiert, idealerweise zusammen mit Testfällen oder -szenarien. Dies sichert die Überprüfbarkeit jeder Forderung und verankert die Qualitätssicherung bereits in der Anforderungsphase.

• Akzeptanzkriterien je Anforderung: Im agilen Bereich ist es Standard, dass jede User Story im Product Backlog Akzeptanzkriterien hat (die Bedingungen, unter denen der Product Owner die Story als „Done“ akzeptiert). Dieses Prinzip kann und sollte man auch im Lastenheft anwenden. Für jede Anforderung im Lastenheft – insbesondere Muss- und Soll-Kriterien – sollte beschrieben sein, wie die Erfüllung geprüft wird. Dies kann in Form eines kurzen Kriteriums erfolgen, z.B.: „Akzeptanzkriterium: System erzeugt den Report X mit den im Anhang definierten Daten binnen 5 Sekunden.“ Im Lastenheft-Dokument kann man eine eigene Spalte „Abnahmekriterium/Test“ führen oder die Kriterien direkt im Fließtext angeben (etwa in Klammern nach der Anforderung). Ein praktischer Faustregel-Tipp lautet: „Für jede Muss-Anforderung: Akzeptanzkriterium ergänzen.“. Dadurch stellt man sicher, dass nichts Unprüfbares verlangt wird.

• Definition of Done/Testfälle: Ergänzend oder anstelle einzelner Kriterien kann man auf höherer Ebene Abnahmeszenarien beschreiben. Beispielsweise könnte das Lastenheft ein Kapitel „Abnahmetests“ enthalten, in dem die Vorgehensweise zur Abnahme umrissen wird: „Die Abnahme erfolgt nach erfolgreich bestandenem User Acceptance Test (UAT) anhand definierter Testfälle“. Dort kann man festhalten, wie viele Fehler welcher Kategorie toleriert werden (z.B. „keine kritischen Bugs, max. 3 hohe Bugs“ sind akzeptabel). Auch können hier konkrete Testfälle referenziert oder beispielhaft aufgeführt werden. Einige Lastenhefte listen pro Modul einen oder zwei Schlüsselszenarien, die der Anbieter später demonstrieren muss. Beispiel: Für das Modul Flächenmanagement: „Testfall: Fläche aus CAD-Grundriss übernehmen – Beim Import einer DWG-Datei nach DIN 277 sollen automatisch die Nettogrundflächen pro Raum angelegt werden.“ Solche Testfälle geben dem Anbieter ein genaues Bild, was er liefern muss, und dem Auftraggeber Sicherheit bei der Abnahme.

• Verbindung zu Pflichtenheft und Vertrag: Die Abnahmekriterien im Lastenheft haben oft Vertragsrelevanz. Sie können in den späteren Werkvertrag übernommen werden, sodass der Lieferant vertraglich zusichert, nach diesen Kriterien abzuliefern. Alles, was als Abnahmekriterium festgelegt ist, muss am Ende erfüllt sein, sonst liegt ein Mangel vor. Daher sollte man Abnahmekriterien realistisch formulieren – weder zu vage (dann bringt es nichts) noch unerreichbar streng (dann hat man später Streit). Ein guter Abnahmepunkt ist objektiv prüfbar, z.B. „Der Report XY zeigt alle Felder laut Liste Z an“ (prüfbar) statt „Der Report XY ist benutzerfreundlich“ (nicht prüfbar).

• Traceability-Matrix: In komplexen Projekten erstellt man eine Anforderung-Test-Matrix (Traceability-Matrix). Das heißt, man führt auf, welcher Testfall welche Anforderung prüft. Dies kann schon im Lastenheft vorbereitet werden: Jede Anforderung trägt eine ID, jeder Testfall ebenso, und man kann in einer Tabelle zuordnen. So sieht man lückenlos, dass für jede Forderung ein Test vorgesehen ist. Manche Lastenhefte enthalten so eine Tabelle im Anhang oder verweisen darauf, dass der Anbieter im Pflichtenheft eine solche Matrix liefern soll.

• Beispielhafte Abnahmekriterien in Tabellenform: Eine praktische Darstellung im Lastenheft ist eine Tabelle mit Anforderungen, Priorität und zugehörigem Akzeptanzkriterium. So erhält ein Anbieter schnell einen Überblick, woran der Erfolg gemessen wird.

Zwei Anforderungen mit Muss/Soll-Priorität und Abnahmekriterien.

Im obigen Beispiel sieht man, dass für eine funktionale Muss-Anforderung (SSO-Login) das Akzeptanzkriterium präzise festlegt, was getestet wird (Login für Rollen A und B funktioniert). Ebenso wird für eine nicht-funktionale Anforderung (Verfügbarkeit) ein Schwellenwert definiert und wie er gemessen wird. Solche Klarheit hilft enorm bei der späteren Abnahme: Der Auftragnehmer weiß genau, welches Ergebnis er liefern muss, und der Auftraggeber kann objektiv prüfen.

• Testdokumentation einfordern: Das Lastenheft kann auch vorgeben, dass der spätere Lieferant bestimmte Testdokumente erstellt (Testpläne, Protokolle) oder dass gemeinsame Abnahmetests stattfinden. Beispielsweise: „Der Anbieter erstellt bis 4 Wochen vor Go-Live einen Abnahme-Testkatalog, der mindestens alle Muss-Anforderungen prüft, zur Freigabe durch den Auftraggeber.“ Damit stellt man sicher, dass das Thema Tests im Projekt nicht untergeht.

Beide Seiten haben ein gleiches Verständnis, wann eine Leistung als erbracht gilt. Es lohnt sich, bereits bei der Anforderungsdefinition den gedanklichen Test mitzumachen: „Wie würde ich überprüfen, ob diese Anforderung erfüllt ist?“ – Die Antwort darauf sollte man gleich ins Lastenheft schreiben.

Ein Lastenheft spiegelt den Wissensstand zu Projektbeginn wider – doch Projekte sind dynamisch. Es ist daher wichtig, das Dokument (bzw. den agilen Backlog) im Verlauf zu pflegen und zu versionieren, um Änderungen kontrolliert einfließen zu lassen.

Lastenheft-Versionierung: In klassischen Projekten wird das Lastenheft oft als Basisdokument eingefroren, sobald die Ausschreibung läuft oder der Vertrag geschlossen ist. Dennoch können sich während der Implementierung neue Anforderungen oder Anpassungen ergeben (z.B. durch Erkenntnisse aus Workshops, Prototypen oder organisatorische Änderungen). Die Frage ist: Wie damit umgehen?

• Änderungsmanagement etablieren: Bereits im Lastenheft kann man einen Abschnitt Änderungskontrolle vorsehen. Dort wird beschrieben, wie nachträgliche Änderungen genehmigt werden. Üblich ist ein formaler Change Request Prozess: Der Auftraggeber stellt einen Änderungsantrag, der Auswirkungen auf Umfang, Zeit, Kosten beschreibt, und der Auftragnehmer bestätigt (ggf. mit Angebotsnachtrag). So behalten beide Parteien Kontrolle. Jede genehmigte Änderung führt dann zu einer neuen Version des Lastenhefts bzw. einem Anhang. Im Dokument sollte eine Versionshistorie enthalten sein (Version, Datum, Änderungen, Freigabe durch wen). Beispielsweise: Version 1.1 – hinzugefügt Anforderung 5.7 „Mobile App“, beschlossen im Lenkungsausschuss am 01.06.2026.

• Kontinuierliche Pflege vs. Fixierung: Es gibt zwei Extreme: Entweder man ändert das Lastenheft gar nicht mehr (und lebt mit etwaigen Lücken) – oder man aktualisiert es ständig. In der Praxis findet ein Mittelweg statt: Größere Änderungen werden formal dokumentiert (damit Klarheit herrscht), kleinere Klarstellungen eventuell in begleitenden Protokollen festgehalten. Wichtig ist, dass am Ende alle Beteiligten mit der gleichen Version arbeiten. Tipp: Das Lastenheft sollte an zentraler Stelle abgelegt sein (z.B. gemeinsames Projektraum-System), sodass immer die aktuelle Fassung zugänglich ist.

• Agiles Vorgehen bei Lastenhefterstellung: Ein interessanter Ansatz ist, die Erstellung selbst schon agil zu handhaben. Wenn ein Lastenheft über längere Zeit erarbeitet wird (z.B. mehrere Monate), bietet es sich an, in Iterationen zu arbeiten. So kann das Dokument reifen und Schritt für Schritt vervollständigt werden. Man könnte z.B. wöchentliche Sprints definieren, in denen jeweils ein Kapitel des Lastenhefts ausgearbeitet und intern reviewt wird. Björn Schorre, ein Experte für Requirements, berichtet: „Dadurch erhöht sich die Reife des Lastenheftes und oft sind die Teams auch deutlich schneller.“. Agile Methoden (Kanban-Board für Lastenheft-Punkte, regelmäßige Review-Meetings) können hier helfen. Zwar hat man am Ende wieder ein „klassisches“ Dokument, aber der Weg dorthin war iterativ und anpassungsfähig.

In agilen Projekten ersetzt der Product Backlog weitgehend das starre Lastenheft. Die Pflege des Backlogs ist eine kontinuierliche Aufgabe: - Der Product Owner hält den Backlog jederzeit aktuell – neue Erkenntnisse aus dem Team oder geänderte Wünsche des Business fließen laufend ein. - Ein etabliertes Meeting dafür ist das Backlog Refinement (Backlog-Pflege-Termin), in dem das Team und PO regelmäßig (oft wöchentlich oder in jedem Sprint) die Einträge durchgehen, Details verfeinern und Prioritäten prüfen. - Änderungen im Backlog brauchen keine separate Freigabe, da der PO die Hoheit hat. Dennoch ist Transparenz wichtig: Signifikante Änderungen sollte der PO mit Stakeholdern abstimmen, um Konsens zu halten. Tools (Jira, Azure DevOps etc.) protokollieren automatisch jede Änderung (Versionierungshistorie jedes Tickets), sodass nachverfolgbar bleibt, wer wann was geändert hat. - Eine Herausforderung kann sein, zu viele Änderungen vorzunehmen und den Fokus zu verlieren. Daher ist diszipliniertes Priorisieren und eine klare Vision nötig, die als roter Faden dient.

In hybriden Projekten (agile Umsetzung, aber formales Lastenheft als Vertragsbestandteil) muss man darauf achten, dass Änderungen im agilen Verlauf nicht das ursprüngliche Lastenheft völlig entwerten. Hier empfiehlt sich: - Kleine Detailänderungen (z.B. Feldbezeichnungen, Layout-Entscheidungen) belässt man im agilen Team und muss sie nicht im Lastenheft nachtragen. - Größere Änderungen (Zusatzmodule, andere Prozesse) sollte man formell als Nachtrag dokumentieren, auch im Lastenheft, um Vertragssicherheit zu haben. - Der Backlog kann manuell mit dem Lastenheft abgeglichen werden, z.B. indem man im Backlog markiert, welche User Story welche Lastenheft-Anforderung adressiert. Bei Änderungen muss man prüfen, ob sie außerhalb des ursprünglichen Scopes liegen (dann Change Request).

Nach erfolgter Einführung wird manchmal ein „Abnahme-Lastenheft“ erstellt. Dieses reflektiert dann den endgültigen Stand der umgesetzten Anforderungen. So ein Dokument kann als Grundlage für Betriebsvereinbarungen oder weitere Ausbauschritte dienen. Hier fließen alle Änderungen mit ein, die unterwegs beschlossen wurden. Manche Verträge sehen vor, dass das Pflichtenheft am Ende angepasst wird, um den As-Built-Zustand zu dokumentieren.

Ein Lastenheft ist kein statisches Gesetzestafel. Projekte ändern sich, und das Dokument sollte mitwachsen – kontrolliert. Durch konsequente Pflege und Versionierung bleibt die Anforderungsspezifikation lebendig und nützlich, anstatt nach Start in der Schublade zu verschwinden. In agilen Backlogs ist diese Lebendigkeit gegeben, hier liegt die Kunst darin, den Überblick und die Ordnung zu bewahren, was durch klare Verantwortlichkeiten (PO) und Meetings (Refinement) erreicht wird.

• Herausforderung 1: Unklare oder zu umfangreiche Anforderungen – Oft besteht die Gefahr, dass Anforderungen entweder zu vage formuliert werden (was später Interpretationsspielraum lässt) oder dass man versucht, jedes Detail bis ins Kleinste vorzuschreiben (was Anbieter in der Lösungsfindung einengt und das Dokument aufbläht). Best Practice: Den richtigen Detaillierungsgrad finden. Eine Faustregel: „Zu vage ist teurer… Zu detailliert wird schnell zum Pflichtenheft und blockiert Lösungsinnovation.“. Beschreiben Sie das gewünschte Ergebnis, nicht die genaue Umsetzung. Beispiel: Statt „Die Software muss in C# programmiert sein“ (Lösung vorweggenommen) lieber „Die Software muss modular erweiterbar sein und unseren Leistungsanforderungen genügen“ – wie der Anbieter das erreicht, bleibt ihm überlassen. Er gibt sein Know-how rein und Sie bekommen ggf. eine bessere Lösung. Stellen Sie sich immer die Frage: Welche Details sind wirklich nötig, um unser Ziel zu erreichen, und welche würden den Anbieter nur unnötig einschränken?. Eine hilfreiche Übung ist in diesem Zusammenhang die aus dem Gedys-Artikel: Für jeden Punkt überlegen „unverzichtbar vs. wünschenswert vs. Freiraum für Anbieter“. Dadurch vermeiden Sie, unbewusst zu viel vorzuschreiben.

• Herausforderung 2: Fehlende Einbindung aller Stakeholder – Ein Lastenheft spiegelt idealerweise die Bedürfnisse aller relevanten Nutzergruppen wider. In der Realität wird es manchmal hauptsächlich von der IT oder einer Abteilung geschrieben, ohne Rücksprache mit anderen (z.B. die Hausmeisterei, die das System täglich nutzen muss). Das führt zu Akzeptanzproblemen und Lücken. Best Practice: Frühzeitige und breite Einbindung aller Stakeholder. Holen Sie Input von operativen FM-Teams, Verwaltung, IT, Management etc. durch Workshops und Interviews. Oft bringen diese Beteiligten kritische Anforderungen ein, an die man sonst nicht gedacht hätte (z.B. Bedarf für Mehrsprachigkeit, mobile Offline-Fähigkeit, oder bestimmte Berichtswünsche des Controllings). Involvierte Nutzer fühlen sich außerdem „mitgenommen“ und stehen später hinter der Lösung. Es lohnt sich auch, externe Berater oder erfahrene Key-User einzubeziehen, die bereits andere CAFM-Projekte erlebt haben – sie kennen Stolpersteine. Schließlich: Top-Management-Support suchen (das Lastenheft sollte von der Leitung mitgetragen werden, um Prioritäten abzusichern).

• Herausforderung 3: Prioritäten setzen und gegenüber internen Wünschen standhaft bleiben – In Lastenheft-Workshops entsteht leicht eine Wunschliste, in der jede Abteilung „alles“ haben will. Ohne Priorisierung führt das zu einem überfrachteten Projekt, das weder budget- noch zeitgerecht umzusetzen ist. Best Practice: Priorisierungsmechanismen konsequent anwenden. Nutzen Sie Methoden wie MoSCoW (Muss/Soll/Kann) im Team und diskutieren Sie offen: Was sind die Kernziele? Was hat den höchsten Nutzen?. Erklären Sie Stakeholdern auch die Konsequenzen: Ein Feature mehr bedeutet vielleicht Monate Projektverlängerung oder höhere Kosten. Hilfreich ist es, die Anforderungen in Phasen zu splitten – z.B. eine „Must-haves für Phase 1“ Liste und „Optionen für Phase 2“. So sehen die Nutzer, dass nichts verloren ist, aber man fokussiert zunächst. Dokumentieren Sie diese Entscheidungen im Lastenheft (ggf. im Kapitel Projektphasen oder durch Prioritätsmarkierungen). Und wenn später Begehrlichkeiten aufkommen, verweisen Sie auf diese vereinbarten Prioritäten – das erhöht die Disziplin und verhindert Scope Creep.

• Herausforderung 4: Änderungen im Projektverlauf managen – Kaum ein Projekt läuft 100% nach Plan. Neue gesetzliche Vorgaben, organisatorische Änderungen oder Erkenntnisse aus Pilotphasen können bedeuten, dass das ursprüngliche Lastenheft angepasst werden müsste. Ohne geregeltes Vorgehen führt das zu Chaos: Der Anbieter ist unsicher, was nun gilt, das Team verliert den Überblick. Best Practice: Änderungsmanagement und agile Anpassungsfähigkeit kombinieren. Richten Sie – wie oben beschrieben – einen Change-Prozess ein, um wesentliche Änderungen formal zu behandeln (so bleibt der Vertrag sauber). Gleichzeitig fördern Sie eine agile Haltung im Team: Das Lastenheft ist kein starres Dogma, sondern darf mit guten Gründen weiterentwickelt werden. Haben Sie regelmäßige Checkpoints (z.B. in jedem Steering Committee Meeting: „Gibt es neue Anforderungen oder Abweichungen? Wie gehen wir damit um?“). Im Zweifel: erst Pilotprojekt machen, dann Lastenheft verfeinern – nicht andersherum. Ein schönes Bild dazu: Ein Lastenheft ist eigentlich auch nur ein „Product Backlog, das von einem 5-Jahres-Sprint ausgeht“ (Zitat aus einem Kommentar) – sprich, es suggeriert eine langfristige Sicherheit, die es so gar nicht gibt. Seien Sie sich bewusst, dass auch ein unterschriebenes Lastenheft nicht in Stein gemeißelt ist, wenn die Realität sich ändert. Die Kunst ist, Änderungen kontrolliert einzuführen (so dass alle davon wissen und die Auswirkungen geklärt sind), ohne das gesamte Projekt zu destabilisieren.

• Herausforderung 5: Datenqualität und Vorarbeiten unterschätzt – In CAFM-Projekten entscheidet die Verfügbarkeit guter Bestandsdaten oft über Erfolg oder Misserfolg. Ein häufiger Stolperstein: Das Lastenheft fordert ambitionierte Funktionen (z.B. detailliertes Anlagenmanagement und lückenlose Wartungshistorie), aber es stellt sich heraus, dass die dafür nötigen Daten gar nicht vorliegen oder extrem unsauber sind. Dann verzögert sich das Projekt, weil erstmal Datenerfassung nachgeholt werden muss, was vorher nicht eingeplant war. Best Practice: Realistische Betrachtung der Datengrundlage schon im Lastenheft. Nehmen Sie, wie oben beschrieben, einen Abschnitt Datengrundlagen auf und analysieren Sie kritisch: Welche Daten haben wir, in welcher Qualität? Planen Sie ggf. Teilprojekte zur Datenaufbereitung vor oder parallel zur CAFM-Implementierung ein. Legen Sie im Lastenheft Verantwortlichkeiten fest (z.B. „Kunde stellt vor Projektstart folgende Daten in strukturierter Form bereit…“). Wenn eine gewisse Datenqualität Voraussetzung für die Abnahme ist, schreiben Sie dies als Muss-Anforderung hinein, beispielsweise „Muss: Es liegt ein vollständiges, aktuelles Raum- und Gebäudebuch gemäß DIN 277 vor.“ Dadurch wird allen klar, dass der Auftraggeber selbst dafür sorgen muss – oder es wird als separate Leistung ausgeschrieben. Kurz: Adressieren Sie das Thema Daten offen, um späteren Frust zu vermeiden.

• Herausforderung 6: Übersehen von Non-Funktionalen Anforderungen – Oft liegt der Fokus sehr stark auf den Fachfunktionen. Dinge wie Performance, Usability, Supportbedingungen, Sicherheit werden weniger konkret gefordert, was dazu führen kann, dass das gelieferte System zwar funktional passt, aber im Alltag Schwierigkeiten macht (z.B. zu langsam ist, oder Bedienung sehr umständlich). Best Practice: Non-Funktionale Anforderungen (NFR) ausdrücklich ins Lastenheft aufnehmen und quantifizieren. Legen Sie z.B. fest: Performance (Antwortzeiten), Skalierbarkeit (max. Anzahl Nutzer), Sicherheitslevel (z.B. Verschlüsselung, Berechtigungstiefe), Verfügbarkeit (SLA), gesetzliche Compliance. Nutzen Sie konkrete Metriken, wo möglich. Das diszipliniert die Anbieter, hier nichts wegzulassen, und gibt Ihnen ein objektives Prüfraster. Gerade im öffentlichen Bereich sind solche Anforderungen oft in separaten Kriterienkatalogen (z.B. EVB-IT Systemvertrag Anlage) enthalten – stimmen Sie Lastenheft und solche Anlagen aufeinander ab, um Konsistenz zu haben.

• Herausforderung 7: Dokumentation und Struktur – Ein Lastenheft kann sehr umfangreich werden (50+ Seiten sind keine Seltenheit). Da den Überblick zu behalten, ist schwierig – sowohl für die Autoren als auch für die Leser (Anbieter). Unstrukturierte oder inkonsistente Dokumente führen zu Missverständnissen und Mehraufwand in der Angebotsphase. Best Practice: Strukturierte Gliederung und Konsistenz prüfen. Verwenden Sie – wie oben – eine klare Gliederung mit Nummerierung. Nutzen Sie Vorlagen oder orientieren Sie sich an Normen (DIN 69901, V-Modell), damit das Lastenheft einen roten Faden hat. Führen Sie am Ende einen Qualitätscheck durch (im Team oder durch einen externen Blick), ob alles konsistent ist: Terminologie vereinheitlicht (z.B. nicht mal „Ticket“ mal „Störmeldung“), keine Widersprüche zwischen Kapiteln, keine Anforderungen doppelt oder an falscher Stelle. Eine Checkliste kann helfen – z.B. hat Rayzr.tech eine Lastenheft-Checkliste publiziert mit Punkten wie „Ziele messbar definiert, Scope klar abgegrenzt, Priorität & Akzeptanzkriterium pro Anforderung, NFRs enthalten, Schnittstellen berücksichtigt, Abnahme definiert“. Solche Listen kann man zur Endkontrolle nutzen.

• Herausforderung 8: Anbieter-Vergleich und Marktsicht – Manchmal wird ein Lastenheft sehr eng an die aktuelle eigene Sicht geschrieben, ohne den Markt der CAFM-Systeme zu kennen. Dann fordert man evtl. exotische Dinge, die kaum ein System standardmäßig bietet, oder man verpasst moderne Lösungsansätze (z.B. BIM-Integration, KI-Funktionen), weil man sie nicht im Blick hatte. Best Practice: Marktbeobachtung einfließen lassen. Nutzen Sie Ressourcen wie die GEFMA-Marktübersicht (GEFMA 940) oder Trendreports, um Ihr Lastenheft „future-proof“ zu machen. Identifizieren Sie aktuelle Trends (IoT, Mobile, BIM, Cloud) und prüfen Sie, ob Ihr Lastenheft dazu Anforderungen stellen sollte – damit Sie eine zukunftsfähige Lösung beschaffen. Gleichzeitig: Hinterfragen Sie sehr spezielle Forderungen – vielleicht gibt es einen etablierten Branchenstandard, der alternativ genutzt werden kann? Stimmen Sie im Zweifel mit Kollegen aus anderen Unternehmen oder Consultants ab, ob Ihr Anforderungspaket realistisch und marktgerecht ist. Diese Validierung kann vor bösen Überraschungen (kein System erfüllt es komplett) schützen.

• Herausforderung 9: Umsetzungskontrolle und Flexibilität – Nach der Vergabe/Auftragsvergabe besteht die Herausforderung, das Lastenheft nicht ad acta zu legen. Es muss während der Implementierung als Referenz dienen. Manche Projekte verlieren das Lastenheft aus dem Blick, und am Ende gibt es ein böses Erwachen, dass manches nicht umgesetzt wurde. Best Practice: Lastenheft als lebendes Referenzdokument nutzen. Gehen Sie mit dem Implementierungspartner/Pflichtenheftautor jede Anforderung durch und lassen Sie darstellen, wie sie umgesetzt wird – das ist ja der Sinn des Pflichtenhefts. Führen Sie regelmäßige Abgleiche durch (z.B. in Statusmeetings: Welche Lastenheft-Punkte wurden bereits erfüllt, welche stehen an?). Markieren Sie im Lastenheft oder einer Traceability-Matrix den Fortschritt. So bleibt das Team fokussiert auf die vereinbarten Ziele. Gleichzeitig: Seien Sie flexibel, wenn sich bessere Lösungen zeigen. Wenn das Lastenheft z.B. einen bestimmten Bericht forderte, und im Zuge des Projekts stellt sich heraus, dass eine Dashboard-Lösung sinnvoller ist, dann sollte man pragmatisch sein und das Lastenheft (per Change Request) anpassen oder zumindest die Änderung dokumentieren.

- Use Case orientieren: Beschreiben Sie Anforderungen möglichst am Prozess entlang (Use Cases/User Stories), nicht isoliert funktional – so behält man den Kontext. - Beispiele geben: Wo möglich, fügen Sie Beispiele oder Skizzen hinzu (z.B. ein Beispielreport, ein Screenshot eines bestehenden Tools, den es zu ersetzen gilt). Bilder sagen oft mehr als Worte und reduzieren Interpretationsspielraum. - Pilot und Phasen einplanen: Nutzen Sie Pilotprojekte und gestufte Rollouts. Tipp aus der Praxis: „Führe ein repräsentatives Pilotprojekt durch“. Dadurch kann man das Lastenheft in kleinem Rahmen validieren und Lessons Learned in Phase 2 einfließen lassen. - Schulung und Change Management bedenken: Anforderungen an Schulung, Dokumentation und Change Management nicht vergessen – diese sollten ebenfalls ins Lastenheft (oder begleitende Dokumente), damit im Angebot Leistungen dafür enthalten sind. - Erfahrungswerte nutzen: Sprechen Sie mit anderen Unternehmen, die CAFM eingeführt haben, oder ziehen Sie spezialisierte Berater hinzu. Sie kennen häufig die Stolpersteine (z.B. Schnittstellenprobleme, Aufwand der Datenmigration) und können schon in der Anforderungsphase darauf hinweisen.

Mit diesen Best Practices erhöht sich die Wahrscheinlichkeit, dass das Lastenheft/Backlog wirklich zum Steuerungsinstrument für Ihr CAFM-Projekt wird – es bleibt aktuell, relevant und führt das Projektteam auf dem effizientesten Weg zum Ziel. Eine sorgfältige, realistische Planung und laufende Anpassung dort, wo nötig, sind der Schlüssel, um aus der Last der Lastenhefterstellung einen Nutzen für das Projekt zu ziehen und am Ende ein erfolgreich implementiertes CAFM-System in Betrieb zu nehmen.