CAFM: Projektauftrag und Projektorganisation

Die Tabelle priorisiert innerhalb dieser Dienstleistung in Must/Should/Nice‑to‑have. Must‑Aktivitäten sind diejenigen, ohne die (a) keine formale Steuerungsfähigkeit besteht oder (b) die spätere Projektführung erfahrungsgemäß „an schleichender Unklarheit“ scheitert (Entscheidungsrechte, Ressourcen, Scope, Daten/Integration als FM‑Spezifika). Should‑Aktivitäten reduzieren typische Implementierungsrisiken (Akzeptanz, Entscheidungsstau, Governance‑Erosion). Nice‑to‑have sind sinnvoll in reifen Organisationen oder bei besonders hoher Sichtbarkeit/Regulierung, aber nicht in jedem Kontext zwingend.

Organisationselemente und Rollenlogik sind so, dass ein „board“ die Steuerung trägt (Executive/Senior User/Senior Supplier) und damit die Interessensachsen Business, Nutzung und Lieferung abdeckt; das lässt sich im FM‑Kontext gut auf Sponsor, FM‑Fachseite und IT/Implementierungspartner übertragen.

Für ein mittelgroßes FM‑Software‑Projekt (ohne Annahmen zu Standorten/Nutzerzahlen) ist für die initiale Erstellung und Freigabe von Projektauftrag und Projektorganisation typischerweise ein Zeitkorridor von ca. 2 bis 6 Wochen realistisch, weil (a) Abstimmungen über Fachbereich, IT, Einkauf/Datenschutz und ggf. Arbeitnehmervertretung in der Praxis kalendarisch limitierend sind und (b) FM‑Spezifika wie Datenumfang und Integrationsbedarf früh „verhandelt“ werden müssen. Diese Korridore sind bewusst als Richtwerte aus Projektpraxis zu verstehen; die Standards definieren vor allem Inhalte/Logik, nicht feste Dauern.

• Hoher Integrationsgrad (ERP/HR/Finance/IAM/BMS): erhöht Abstimmungs- und Governancebedarf, weil ein Schnittstellenkonzept und ein tragfähiges Integrationsvorgehen definiert werden müssen.

• Datenlage/Neuerfassung: erhöht die Notwendigkeit, Datenverantwortlichkeiten früh zu fixieren (Datenbasisstruktur, schrittweiser Aufbau, laufende Pflege).

• Viele Standorte / Rollout in Wellen: erhöht Change‑/Kommunikationsanteil und erfordert meist zusätzliche Rollout‑Teilprojekte mit klarer RACI.

Die nachfolgenden Meilensteine sind typische „Gates“, die als Steuerungsinstrument im Projektauftrag verankert werden. Sie sind bewusst so formuliert, dass sie als Eintritts-/Exit‑Kriterien in Lenkungskreis‑Entscheidungen übernommen werden können.

Die Rollenlogik sollte die drei Grundperspektiven „Business‑Steuerung“, „Nutzerinteressen“ und „Lieferfähigkeit“ stabil abbilden; PRINCE2 beschreibt dies als Board‑Konstruktion aus Executive, Senior User(s) und Senior Supplier(s), die für Richtung und Erfolg/Fehlschlag verantwortlich sind. In FM‑Software‑Programmen lässt sich dies praxisnah auf Sponsor/Auftraggeber (Executive), FM‑Fachverantwortung (Senior User) und Implementierungs-/IT‑Lieferverantwortung (Senior Supplier) abbilden, ergänzt um Datenschutz/Informationssicherheit als Querschnittsfunktion.

Im Projektauftrag ist insbesondere sauber zu regeln, wer „A“ (Accountable) ist: Die PMI‑Definition des Projektcharters betont, dass der Charter das Projekt formell autorisiert und der Projektleitung Autorität gibt, Organisationsressourcen einzusetzen; ohne einen klaren Sponsor und ohne klare Entscheidungskompetenzen wird der Projektauftrag in der Praxis zur „Absichtserklärung“ statt zur Steuerungsgrundlage.

RACI ist als Responsibility Assignment Matrix ein gängiges Werkzeug zur Klarstellung von Rollen/Verantwortlichkeiten; PMI beschreibt den Nutzen u. a. darin, Stakeholderrollen eindeutig festzulegen und damit auch eine Basis für Kommunikationsplanung zu schaffen.

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

* BR typischerweise „I“ oder „C“ abhängig davon, ob und in welchem Umfang mitbestimmungspflichtige Änderungen (z. B. Leistungs-/Verhaltenskontrolle durch Systemnutzung) berührt sind; das ist kontext- und rechtsraumspezifisch und muss im Projektauftrag geklärt werden.

** In vielen Organisationen ist FM fachlich accountable für Anforderungen und Change, während der Sponsor für das Gesamtprojekt accountable bleibt; im Zweifel wird eine eindeutige „Single‑A“-Regel pro Aktivität festgelegt (Governance‑Entscheidung im Projektauftrag).

• Integrationsstrategie und Schnittstellenkonzept: Branchenquellen zu CAFM‑IT‑Integration betonen die Notwendigkeit, ein Schnittstellenkonzept zu erstellen, um Informationsverteilung und Schnittstellenflexibilität zu organisieren; deshalb muss der Projektauftrag früh entscheiden, welche Zielsysteme angebunden werden und wie Entscheidungen zwischen FM, IT und Systemowner getroffen werden.

• Datenbasis und Datenmanagement: Für CAFM‑Vorhaben ist die Datenbasis (Struktur, schrittweiser Aufbau, laufende Pflege) ein eigenes, methodisch zu betrachtendes Feld; der Projektauftrag muss Datenverantwortung (Owner/Stewards) und Datenumfang zumindest prinzipiell festlegen, sonst entstehen spätere Reibungsverluste in Migration und Betrieb.

• Auswahl/Beauftragung Software & Implementierungspartner (falls noch offen): Branchenleitfäden zur CAFM‑Einführung adressieren explizit die Auswahl von Software und Implementierungspartnern sowie Musterinhalte für Ausschreibungen; in diesem Fall muss der Projektauftrag bereits Leistungsabgrenzungen und Governance‑Schnittstellen zum Beschaffungsprozess enthalten.

• Datenschutz und IT‑Sicherheit: Sobald personenbezogene Daten verarbeitet werden, sind angemessene technische und organisatorische Maßnahmen zu planen und ihre Wirksamkeit regelmäßig zu evaluieren; zudem kann eine Datenschutz‑Folgenabschätzung erforderlich sein, wenn voraussichtlich ein hohes Risiko besteht. Diese Anforderungen sind nicht „nachgelagert“, sondern beeinflussen Rollen-/Berechtigungskonzept und Betriebsmodell, also Inhalte des Projektauftrags.

• Formale Autorisierung: Projektauftrag ist vom Sponsor freigegeben; die Projektleitung ist benannt und mit klaren Befugnissen ausgestattet, Ressourcen anzufordern und Entscheidungen herbeizuführen.

• Governance operational: Lenkungskreis/Steuerkreis ist besetzt, Sitzungstakt und Entscheidungsformate sind festgelegt; es existiert ein verbindlicher Entscheidungslog und ein Eskalationsweg.

• RACI konsistent: RACI ist abgestimmt, widerspruchsfrei (je Aktivität ein klares „A“) und in den Linienbereichen akzeptiert.

• Projektgrundplan vorhanden: Meilensteine/Gates und Freigabepunkte sind definiert (mindestens Requirements‑Freigabe, Lösungsfreigabe, Go‑Live‑Freigabe).

• Querschnitt geklärt: Datenschutz/Informationssicherheit sind eingebunden; es gibt eine belastbare Einordnung, ob zusätzliche Nachweise/Assessments (z. B. DSFA) voraussichtlich notwendig werden.

• Arbeitsumgebung aktiv: Projektablage, Zugriffsregeln, Protokollstandard und Issue-/Risk‑Log sind eingerichtet; Verantwortlichkeiten für Pflege/Reporting sind festgelegt.

Die Risiken sind bewusst auf die Dienstleistung selbst bezogen (nicht auf das gesamte Implementierungsprojekt), weil ein schwacher Projektauftrag die Folgearbeit systematisch destabilisiert.

Die Gliederung kombiniert „klassischen“ Projektcharter‑Inhalt (Autorisation, Ziele, Scope, Autorität) mit einem Governance‑Teil.

• Lenkungskreis (Sponsor/Fach/IT) → Projektleitung/PMO → Teilprojekte (Fachprozesse, Daten, Integration/IT, Test/Qualität, Change/Training).

• Diese Struktur entspricht dem PRINCE2‑Gedanken, dass ein Board auf „Directing Level“ Richtung und Verantwortung trägt und darunter die Projektleitung das Tagesgeschäft steuert.

• Optional (bei hoher IT‑Komplexität): ein Architektur-/Integrationsgremium mit verbindlichen Entscheidungen zu Schnittstellenprioritäten, Datenhoheit und Betriebsfragen; diese Option ist besonders dann sinnvoll, wenn ein CAFM‑System in ein Umfeld vieler FM‑relevanter IT‑Komponenten eingebunden werden muss und Schnittstellendefinition/‑integration eigenständig komplex wird.

• SaaS/Cloud vs. On‑Premises: Bei SaaS verschieben sich technische Betriebsaufgaben (z. B. Plattformbetrieb) stärker zum Anbieter; im Projektauftrag müssen dann insbesondere Verantwortlichkeiten für Release-/Patch‑Fenster, Incident‑Schnittstellen und Sicherheitsnachweise sauber geregelt werden. Gleichzeitig betonen Branchenhinweise, dass CAFM‑Leitfäden an die Cloudifizierung angepasst wurden; das ist ein Indikator, dass Governance und Beschaffung (SLAs, Rollenmodell) in SaaS‑Kontexten häufiger detaillierter ausfallen müssen.

• Viele Standorte vs. wenige: Bei vielen Standorten steigt der Anteil an Rollout‑Koordination, Key‑User‑Netz und Kommunikations-/Trainingsarchitektur deutlich; Change‑Planung sollte dann nicht nur „Kommunikation“, sondern Befähigung und Widerstandsmanagement systematisch abdecken.

• Hoher Integrationsgrad vs. Low‑Integration: Bei hohem Integrationsgrad werden Integrationsentscheidungen (Priorität, Datenhoheit, Monitoring, Fehlerhandling) zum Engpass; die Projektorganisation braucht dann zusätzlich klare Systemowner‑Verantwortung und ein formalisiertes Schnittstellenkonzept.

• Hoher Datenschutz-/Security‑Druck: Wenn FM‑Systeme personenbezogene Daten verarbeiten oder umfangreiche Protokollierung/Tracing vorgesehen ist, sollten Datenschutz und Informationssicherheit bereits im Projektauftrag verbindlich eingebunden werden; Art. 32 verlangt risikoadäquate Maßnahmen inklusive regelmäßiger Wirksamkeitsprüfung, und Art. 35 kann eine DSFA erforderlich machen.