CAFM: Zielbild, Scope und Roadmap

Die Abfolge folgt einer pragmatischen Logik: Zuerst werden Treiber und Leitprinzipien geklärt, anschließend werden Ziel‑Fähigkeiten und Scope dimensioniert, dann wird die Roadmap mit Gates/MVP festgezurrt und schließlich wird die Scope‑Baseline formalisiert (inkl. Change‑Control‑Mechanik). Dass Scope‑Baseline und WBS als zentrale Instrumente zur Steuerung gelten und nicht nur zur initialen Planung dienen, ist in PMI‑nahen Darstellungen ausdrücklich erläutert: Scope Baseline besteht aus Scope Statement, WBS und WBS Dictionary; nach Freigabe sind Änderungen nur über Change‑Control zulässig.

Die Roadmap wird idealerweise so gestaltet, dass sie eine stufenweise Lieferung ermöglicht und zugleich die Management‑Entscheidungen pro Stage/Gate unterstützt.

Die folgenden Richtwerte beziehen sich auf ein „mittelgroßes“ Projekt (ohne Annahmen zur Standortzahl/Integrationsdichte); Aufwand ist deshalb als Korridor zu verstehen. Wo IT‑Integration und Datenstandardisierung stark ausgeprägt sind, verlängert sich die Zielbild‑ und Scope‑Phase typischerweise, weil Schnittstellenkonzepte und Datenanforderungen den Scope substanziell beeinflussen.

Für ein mittelgroßes FM‑Software‑Projekt liegt der Initialaufwand für „Zielbild, Scope und Roadmap“ typischerweise bei ca. 4 bis 10 Kalenderwochen, wobei die Spanne primär durch (a) Standort‑ und Rollenvielfalt, (b) Integrationsdichte und (c) Datenstandardisierungsbedarf getrieben wird. Der Aufwand ist nicht rein „Dokumentationsarbeit“: Er besteht vor allem aus Abstimmungen und Trade‑off‑Entscheidungen, die später teure Kurskorrekturen vermeiden sollen.

In Projekten mit hoher Integrationskomplexität oder hoher Nutzung mobiler Apps ist regelmäßig ein zusätzlicher Schleifendurchlauf erforderlich, weil Schnittstellenkonzept, Betriebsform und Lizenzmodell den Scope unmittelbar verändern können, weil Aufwände für Schnittstellen stark schwanken und teils die Softwareaufwände übersteigen.

Die Rollenstruktur sollte (mindestens) drei Interessenachsen abbilden. Business‑/Nutzenverantwortung (Sponsor), fachliche Anwender‑/Betriebsverantwortung (FM‑Leitung, Prozessowner, Key‑User) und technische Liefer‑/Betriebsverantwortung (IT‑Architektur, IT‑Betrieb, Implementierungspartner). Diese Struktur ist wichtig, weil Roadmap‑Entscheidungen stets Trade‑offs zwischen Nutzen, Machbarkeit, Risiken und Time‑to‑Value beinhalten.

Datenschutz und Informationssicherheit sind je nach Scope nicht „Berater am Rand“, sondern können Scope‑Entscheidungen prägen: Art. 32 verlangt risikoadäquate technische und organisatorische Maßnahmen unter Berücksichtigung von „nature, scope, context and purposes“ und fordert u. a. regelmäßige Wirksamkeitsprüfung; Art. 35 fordert bei voraussichtlich hohem Risiko vorab eine DSFA, die u. a. Zwecke, Notwendigkeit/Verhältnismäßigkeit, Risikoanalyse und Maßnahmen enthält.

Rollen: Sponsor/Auftraggeber (SP), Projektleiter (PL), FM‑Manager/Fachprozessowner (FM), IT‑Leitung/Architekt (IT), Implementierungspartner (IP), Key‑User‑Lead (KU), Datenschutzbeauftragter (DSB), Betriebsrat (BR)

* In der Praxis ist häufig entweder der Sponsor oder die FM‑Leitung „A“; entscheidend ist eine eindeutige Regel „eine Aktivität – ein Accountable“, damit Zielbild‑ und Scope‑Entscheidungen nicht in der Linie hängen bleiben.

** Der Betriebsrat ist kontextabhängig: relevant, wenn das System objektiv geeignet ist, Verhalten/Leistung auszuwerten (z. B. Zeitstempel, Ticketdurchlaufzeiten personenbezogen), oder wenn arbeitsplatzbezogene Datenverarbeitung besonders sensibel ist; das sollte über eine frühe Scope‑Klärung und Datenschutz-/Mitbestimmungsprüfung entschieden werden.

Dieses Arbeitspaket gilt als abgeschlossen, wenn (a) Zielbild, Scope‑Baseline und Roadmap jeweils versioniert und freigegeben sind, (b) die Abgrenzungen und Annahmen nachvollziehbar dokumentiert sind, (c) ein Change‑Control‑Mechanismus für Scope‑Änderungen existiert (inkl. Entscheidungsrechten), und (d) Datenschutz-/Security‑Scoping abhängig vom Scope durchgeführt und dokumentiert wurde.

Eine Scope‑Matrix ist hilfreich, weil FM‑Software‑Scope meist multidimensional ist (Funktionen, Standorte, Rollen, Daten, Integration) und weil Baseline‑Logik verlangt, dass Grenzen nach Freigabe nur kontrolliert geändert werden dürfen.

Die Ausgestaltung von Zielbild, Scope und Roadmap hängt wesentlich von Rahmenbedingungen ab.

• Bei SaaS/Cloud verschiebt sich der Fokus auf Betriebsform, Lizenzmodell, Release-/Patch‑Rhythmus und Provider‑Schnittstellen.

• Bei vielen Standorten ist die Roadmap typischerweise wellenförmig (Pilot → Wellen), und das Zielbild muss stärker standardisieren (Prozess-/Datenharmonisierung), um Skalierung zu ermöglichen; Datenstandardisierung wird als entscheidende Voraussetzung für erfolgreiches digitales FM hervorgehoben.

• Bei hohem Integrationsgrad dominiert die Frage, welche Schnittstellen wann stabil verfügbar sind. Ein Schnittstellenkonzept ist zu erstellen. Aufwände schwanken stark und können die Softwareaufwände übersteigen; in der Roadmap müssen Integrations‑Enabler daher meist früh und als „kritischer Pfad“ eingeplant werden.