Dienstleistungskatalog für die Implementierung eines CAFM-Systems
Facility Management: FM-Software » Projekt » Implementierung » Dienstleistungskatalog
Dienstleistungskatalog für die Implementierung einer Facility‑Management‑Software
Dieses Dokument bündelt Dienstleistungen (Services/Work Packages), die in den Implementierungsprojekten für Facility‑Management‑Software in mindestens einer Variante vorkommen.
Da Branche/Standorte/Nutzerzahlen/IT‑Landscape/Funktionsumfang variieren, sind Aufwand und Ausprägung einzelner Services bewusst als Low/Medium/High/kontextabhängig klassifiziert. Wo Dienste optional sind, wird das explizit genannt.
Dienstleistungskatalog Implementierung Facility-Management-Software
- Phasenstruktur und Priorisierung
- Dienstleistungs-Katalog
- Kritische Abhängigkeiten und Varianten nach Kontext
- Risiken und Gegenmaßnahmen
- Welche Informationen für die spätere Detailausarbeitung erforderlich sind
Die im Folgenden verwendete Phasenstruktur reicht von Konzeption / Produktauswahl bis Nutzung / Weiterentwicklung. Sie macht die typischen „Risikotreiber“ sichtbar: Daten, Integration, Test/Abnahme und Adoption/Change sind in der Praxis die entscheidenden Engpass‑ und Qualitätshebel.
Prioritätenlogik (kurz):
Must‑have: Ohne diese Leistungen ist ein kontrolliertes Go‑Live mit belastbarer Prozess‑/Daten‑/Betriebsfähigkeit kaum möglich (z. B. Anforderungen, Datenmigration in irgendeiner Form, Test/Abnahme, Betriebsübergabe).
Should‑have: Reduziert nachweislich typische Projektrisiken bzw. sichert Skalierung/Compliance ab (z. B. Daten‑Governance, formalisierte Cutover‑Proben, systematisches Change‑Management).
Nice‑to‑have (optional): Wird bei bestimmten Kontexten faktisch nötig (z. B. Performance‑Tests bei sehr vielen Nutzern/hoher Transaktionslast; Pen‑Tests bei erhöhtem Schutzbedarf; BIM/IoT‑Integration bei entsprechendem Zielbild). Sicherheits‑/Schutzbedarfsanforderungen in gebäudenahen IT/OT‑Kontexten werden in einschlägigen IT‑Sicherheitsrahmenwerken zunehmend explizit adressiert.
Dienstleistungs-Katalog
Aufwand ist qualitativ bewertet; „kontextabhängig“ bedeutet: stark abhängig von Standortzahl, Datenlage, Integrationsgrad, SaaS vs. On‑Premises, Regulatorik und Funktionsumfang.
| Dienstleistung | Phase | Kurze Beschreibung | Typische Rollen/Stakeholder | Aufwand (Low/Medium/High/kontextabhängig) | Abhängigkeiten | Priorität |
|---|---|---|---|---|---|---|
| Projektauftrag und Projektorganisation | Vorbereitung & Strategie | Klärt Ziele, Scope, Verantwortlichkeiten (RACI), Entscheidungswege, Budgetrahmen; Ergebnis ist ein belastbarer Projektauftrag samt Governance. | Auftraggeber/Projektleitung, FM‑Leitung, IT‑Leitung, Controlling | Medium | ⟶ Zielbild/Scope | Must-have |
| Stakeholderanalyse und Kommunikationsrahmen | Vorbereitung & Strategie | Identifiziert Betroffene/Einflussnehmer, Informationsbedarfe und Kommunikationsformate; Ergebnis ist eine Stakeholder‑Landkarte inkl. Kommunikationsrhythmus. | Projektleitung, FM‑Manager, HR/Kommunikation, Key‑User, Betriebsrat (falls relevant) | Medium | ⟶ Change‑Plan, Trainings | Should-have |
| Zielbild, Scope und Roadmap (MVP/Releaseplan) | Vorbereitung & Strategie | Definiert Zielzustand (Module/Prozesse/Standorte), Abgrenzungen und stufenweisen Ausbau; Ergebnis ist eine priorisierte Roadmap (MVP → Erweiterungen). | Auftraggeber, FM, IT‑Architekt, Implementierungspartner, Key‑User | Medium | ⟶ Anforderungen, Architektur | Must-have |
| Wirtschaftlichkeits- und Nutzenanalyse (Business Case) | Vorbereitung & Strategie | Optional, aber häufig sinnvoll: quantifiziert Nutzenhypothesen (z. B. Effizienz, Compliance, Datenqualität) und Kosten; Ergebnis ist ein Entscheidungs- und Steuerungsrahmen für Nutzenrealisierung. | Auftraggeber, Controlling, FM‑Leitung, Einkauf | Kontextabhängig | ⟶ Zielbild/KPIs | Should-have |
| Vorgehensmodell, Termin- und Ressourcenplanung | Vorbereitung & Strategie | Legt Delivery‑Modell (agil/hybrid), Meilensteine, Ressourcen und Qualitäts-/Risikosteuerung fest; Ergebnis ist ein baseline‑fähiger Projektplan. | Projektleitung, PMO, Implementierungspartner, Linienvorgesetzte | Medium | ⟶ Projektauftrag | Must-have |
| Beschaffung, Lizenz- und Vertragsmanagement | Vorbereitung & Strategie | Optional, falls Software/Partner noch zu beschaffen sind: Ausschreibung, Bewertung, Verhandlung, Lizenz-/SaaS‑Modelle; Ergebnis sind Verträge, SLAs, Leistungsbeschreibung. | Einkauf, Legal, IT, FM, Datenschutz, Implementierungspartner | High | ⟶ Anforderungen, Zielbild | Must-have (wenn noch nicht erfolgt) |
| Betriebs- und Hostingentscheidung (SaaS/Cloud/On‑Prem) | Vorbereitung & Strategie | Klärt Betriebsform, Zielarchitektur, Verantwortlichkeiten (Kunde/Provider/Partner); Ergebnis ist ein abgestimmtes Betriebsmodell inkl. Sicherheits-/Compliance‑Rahmen. | IT‑Betrieb, IT‑Architekt, Informationssicherheit, Datenschutz, FM | Kontextabhängig | ⟶ Sicherheitskonzept, Verträge | Must-have |
| Sicherheits- und Datenschutz-Vorprüfung | Vorbereitung & Strategie | Klassifiziert Daten (personenbezogen ja/nein), Schutzbedarf, Grundanforderungen (TOMs) und prüft, ob DPIA‑Pflicht wahrscheinlich ist; Ergebnis ist ein Security/Privacy‑Backlog. | Datenschutz, Informationssicherheit, IT‑Architekt, FM, Legal | Medium | ⟶ Architektur, Rollen/Rechte | Must-have |
| Vorbereitende Standardisierung von FM‑Prozessen und Stammdaten | Vorbereitung & Strategie | Harmonisiert Begriffe/Objektstrukturen (Standorte, Gebäude, Anlagen, Räume, Kostenstellen) als Voraussetzung für Digitalisierung; Ergebnis ist ein vorläufiger FM‑Daten-/Prozessstandard. | FM‑Fachteam, Datenverantwortliche, externe Berater | Kontextabhängig | ⟶ Anforderungen, Datenmodell | Should-have |
| Ist-Prozessaufnahme und Systeminventur | Anforderungen & Prozessdesign | Erfasst heutige Prozesse, Medienbrüche, Schnittstellen, Systemlandschaft; Ergebnis ist eine dokumentierte Ist‑Prozess- und Systemübersicht. | FM‑Prozessowner, IT‑Architekt, Key‑User, ggf. Dienstleister | Medium | ⟶ Soll‑Design | Must-have |
| Soll-Prozessdesign und Harmonisierung | Anforderungen & Prozessdesign | Entwirft Soll‑Prozesse (z. B. Ticket → Auftrag → Abnahme → Reporting), inklusive Rollen/Regeln; Ergebnis ist ein abgestimmtes Prozessmodell als Konfigurationsgrundlage. | FM‑Manager, Prozessowner, Key‑User, Implementierungspartner | High | ⟶ Ist‑Analyse, Zielbild | Must-have |
| Anforderungserhebung (funktional & nichtfunktional) | Anforderungen & Prozessdesign | Übersetzt Soll‑Prozesse in Anforderungen (Funktionen, Daten, Integrationen, Performance, Verfügbarkeit); Ergebnis ist ein priorisiertes Anforderungsset. | Auftraggeber, FM, IT‑Architekt, Informationssicherheit, Key‑User | High | ⟶ Zielbild, Soll‑Prozesse | Must-have |
| Lastenheft/Backlog und Priorisierung | Anforderungen & Prozessdesign | Verdichtet Anforderungen in umsetzbare Epics/User Stories bzw. Lastenheft mit Akzeptanzkriterien; Ergebnis ist ein lieferfähiger Umsetzungsbacklog. | Projektleitung, Implementierungspartner, Product Owner (fachlich), Key‑User | Medium | ⟶ Anforderungen | Must-have |
| KPI-, Reporting- und Steuerungskonzept | Anforderungen & Prozessdesign | Definiert Kennzahlen, Auswertungslogik, Datenquellen und Zielberichte; Ergebnis ist ein Reporting‑Blueprint (inkl. Nutzensteuerung). | FM‑Leitung, Controlling, Data/BI, Key‑User | Medium | ⟶ Datenmodell, Migration | Should-have |
| Integrations- und Schnittstellenanforderungen | Anforderungen & Prozessdesign | Legt fest, welche Systeme wie Daten liefern/empfangen (ERP/HR/Finance/IAM/BMS etc.); Ergebnis ist ein Integrationsbedarf inkl. Prioritäten. | IT‑Architekt, Systemowner, FM, Implementierungspartner | High | ⟶ Schnittstellenkonzept | Must-have (bei jeder IT‑Einbettung) |
| Datenquellenanalyse und Migrationsumfang | Anforderungen & Prozessdesign | Identifiziert Quellen (Excel, Alt‑CAFM, ERP, CAD/BIM) und entscheidet, welche Daten migriert/neu erfasst werden; Ergebnis ist ein Migrationsumfang inkl. Datenverantwortlichen. | Datenverantwortliche, FM, IT, Implementierungspartner | High | ⟶ Datenstandard, Datenmodell | Must-have |
| Rollen- und Berechtigungskonzept (fachlich) | Anforderungen & Prozessdesign | Definiert Rollen (z. B. Melder, Disponent, Techniker, Controller) und Berechtigungsregeln; Ergebnis ist ein fachliches Rollenmodell als Basis für IAM/SoD. | FM‑Leitung, IT‑Security/IAM, Datenschutz, Key‑User | Medium | ⟶ Security/IAM‑Design | Must-have |
| Lösungsarchitektur und Systemlandschaft (inkl. Umgebungen) | Lösungsdesign & Architektur | Entwirft Zielarchitektur (SaaS/Hybrid), Umgebungen (DEV/TEST/PROD), Monitoring/Backup; Ergebnis ist ein umsetzbares Architektur‑ und Umgebungsdesign. | IT‑Architekt, IT‑Betrieb, Implementierungspartner, Security | High | ⟶ Hostingentscheidung | Must-have |
| Datenmodell und Objekt-/Flächen-/Asset-Struktur | Lösungsdesign & Architektur | Definiert Zielobjekte, Attribute, Hierarchien und Schlüssel (Standort‑/Gebäude‑/Raum‑/Asset‑Struktur); Ergebnis ist ein Ziel-Datenmodell inkl. Namens-/ID‑Regeln. | FM‑Datenowner, Implementierungspartner, Data Steward | High | ⟶ Datenstandard, Migration | Must-have |
| Daten-Governance und Datenqualitätskonzept | Lösungsdesign & Architektur | Legt Verantwortlichkeiten, Qualitätsregeln, Prüfmechanismen und Pflegeprozesse fest; Ergebnis ist eine betriebsfähige Datenorganisation (Owner/Steward/Prozesse). | FM‑Leitung, Data Steward, IT, ggf. Compliance | Medium | ⟶ Datenmodell, Migration | Should-have |
| Schnittstellenkonzept und technisches Interface-Design | Lösungsdesign & Architektur | Spezifiziert je Integration Mechanismus (API/Middleware/File), Mapping, Fehlerhandling, Monitoring; Ergebnis ist ein abgestimmtes Schnittstellenpaket (Fach+Technik). | IT‑Architekt, Systemowner, Implementierungspartner, ggf. Middleware‑Team | High | ⟶ Integrationsanforderungen | Must-have |
| Security/IAM-Architektur (SSO, Rollen, Logging) | Lösungsdesign & Architektur | Plant Authentifizierung (SSO), Autorisierung, Protokollierung und Zugriffskontrollen; Ergebnis ist ein Security‑Design, das Datenschutz- und IS‑Vorgaben operationalisiert. | IAM‑Team, Security Officer, Datenschutz, IT‑Betrieb | High | ⟶ Rollenmodell | Must-have |
| Compliance-Konzeption (Datenschutz, Auditfähigkeit, Auftragsverarbeitung) | Lösungsdesign & Architektur | Klärt rechtliche/organisatorische Anforderungen (z. B. TOM‑Dokumentation, Auftragsverarbeitung bei SaaS, Audit‑Nachweise); Ergebnis ist ein Compliance‑Set an Deliverables. | Datenschutz, Legal, IT‑Security, Einkauf, Provider/Partner | Kontextabhängig | ⟶ Verträge, Security‑Design | Must-have |
| Teststrategie und Abnahmekriterien | Lösungsdesign & Architektur | Legt Testarten, Umgebungen, Testdaten, Abnahmekriterien und Defect‑Prozess fest; Ergebnis ist ein Testmasterplan bis UAT/Abnahme. | Testmanager, Projektleitung, Implementierungspartner, Key‑User | Medium | ⟶ Anforderungen, Umgebungen | Must-have |
| Cutover-, Go‑Live- und Rollout-Konzept | Lösungsdesign & Architektur | Plant Datenfreeze, Cutover-Schritte, Rollout‑Wellen (Standorte/Module) und Go‑Live‑Risikoabsicherung; Ergebnis ist ein Cutover‑Runbook. | Projektleitung, IT‑Betrieb, FM‑Ops, Implementierungspartner | High | ⟶ Migration, Tests | Must-have |
| Betriebs- und Supportmodell (ITSM/SLAs) | Lösungsdesign & Architektur | Definiert Supportlevel (L1–L3), SLAs, Ticketkategorien, Release-/Patchprozesse; Ergebnis ist ein Betriebsmodell inkl. Übergabekriterien. | IT‑Service‑Owner, Service Desk, Implementierungspartner, FM‑Leitung | Medium | ⟶ Hosting/Verträge | Must-have |
| Konfigurations- und Dokumentationsmanagement | Lösungsdesign & Architektur | Regelt, wie Konfigurationen versioniert, dokumentiert und freigegeben werden; Ergebnis ist ein nachvollziehbarer „Configuration Baseline“-Ansatz. | Implementierungspartner, IT‑Architekt, PMO | Medium | ⟶ Projektmethodik | Should-have |
| System-Setup und Basis-Konfiguration | Konfiguration & Entwicklung | Richtet Mandant, Grundparameter, Module, Stammdaten-Templates ein; Ergebnis ist eine lauffähige Basiskonfiguration als Startpunkt für Iterationen. | Implementierungspartner, IT‑Betrieb, FM‑Key‑User | Medium | ⟶ Architektur/Umgebungen | Must-have |
| Workflow- und Prozesskonfiguration | Konfiguration & Entwicklung | Konfiguriert Workflows, Statusmodelle, Genehmigungen, Eskalationen; Ergebnis sind produktionsnahe Soll‑Prozesse im System. | Implementierungspartner, FM‑Prozessowner, Key‑User | High | ⟶ Soll‑Prozesse | Must-have |
| Formular-/UI-Konfiguration und Usability-Feinjustierung | Konfiguration & Entwicklung | Passt Masken, Pflichtfelder, Listen, Suchlogik und Nutzerführung an; Ergebnis ist praxistaugliche Bedienbarkeit pro Rolle. | Implementierungspartner, UX, Key‑User | Medium | ⟶ Rollenmodell, Datenmodell | Should-have |
| Berichtswesen/Dashboards umsetzen | Konfiguration & Entwicklung | Baut Standardberichte, Dashboards und ggf. BI‑Anbindungen; Ergebnis ist ein steuerungsfähiges Reporting inkl. KPI‑Definitionen. | BI/Data, Implementierungspartner, FM‑Leitung | Medium | ⟶ KPI‑Konzept, Datenmodell | Should-have |
| Customizing/Erweiterungsentwicklung | Konfiguration & Entwicklung | Optional: entwickelt Erweiterungen (z. B. spezielle Regeln, Integrationslogik, UI‑Extensions); Ergebnis sind getestete, dokumentierte Erweiterungen. | Entwickler, IT‑Architekt, Implementierungspartner, Key‑User | Kontextabhängig | ⟶ Architektur, Tests | Nice-to-have (falls Standard nicht reicht) |
| Mobile Nutzung (Apps/Offline/Barcode) | Konfiguration & Entwicklung | Optional: richtet mobile Flows für Techniker/Servicekräfte ein; Ergebnis ist rollenbasierte mobile Nutzung inkl. Geräte-/MDM‑Vorgaben. | FM‑Ops, IT‑Workplace/MDM, Implementierungspartner | Kontextabhängig | ⟶ Prozesse, Security/IAM | Nice-to-have (bei Field Service häufig nötig) |
| Dokumentenmanagement, Vorlagen und Anhänge | Konfiguration & Entwicklung | Konfiguriert Dokumenttypen, Ablage, Vorlagen (z. B. Checklisten, Prüfprotokolle); Ergebnis ist revisions- und prozesskonforme Dokumentnutzung. | FM‑Ops, Compliance, Implementierungspartner | Medium | ⟶ Rollen/Rechte, Datenmodell | Should-have |
| Automatisierungen/Benachrichtigungen/Regelwerke | Konfiguration & Entwicklung | Implementiert Regeln (z. B. SLA‑Eskalation, Wartungszyklen), Notifications; Ergebnis sind automatisierte, messbare Prozessauslöser. | Implementierungspartner, FM‑Prozessowner | Medium | ⟶ Workflow‑Design | Should-have |
| Rollen/Berechtigungen technisch umsetzen | Konfiguration & Entwicklung | Setzt Rollen in IAM/Applikation um, inkl. Berechtigungsprüfungen; Ergebnis ist ein auditierbares Berechtigungssetup. | IAM, Security, Implementierungspartner | High | ⟶ Rollenmodell, SSO | Must-have |
| Datenbereinigung und Datenaufbereitung | Daten, Integration & Migration | Bereinigt Dubletten, fehlende Pflichtattribute, uneinheitliche Klassifikationen; Ergebnis ist „migrierfähige“ Datenqualität. | Data Owner, FM‑Datenpflege, externe Datendienstleister | High | ⟶ Datenquellenanalyse | Must-have |
| Datenmapping und Transformationsregeln | Daten, Integration & Migration | Definiert Feld‑/Code‑Mappings und Transformationslogik; Ergebnis ist ein freigegebenes Mapping‑Dokument als ETL‑Basis. | Data Steward, Implementierungspartner, Systemowner | High | ⟶ Datenmodell | Must-have |
| Migrationstooling/ETL-Pipelines aufbauen | Daten, Integration & Migration | Setzt ETL‑Prozesse auf (Identify/Extract/Transform/Load/Validate‑Logik); Ergebnis ist eine wiederholbare Migrationspipeline inkl. Protokollen. | Implementierungspartner, Data Engineer, DBA | High | ⟶ Mapping, Umgebungen | Must-have |
| Testmigrationen und Datenvalidierung (Reconciliation) | Daten, Integration & Migration | Führt Iterationen von Testmigrationen aus und validiert Vollständigkeit/Korrektheit; Ergebnis ist ein abgestimmtes „Data Reconciliation“-Protokoll. | Data Owner, Key‑User, Implementierungspartner | High | ⟶ ETL‑Pipelines | Must-have |
| Produktivmigration und Cutover-Datenload | Daten, Integration & Migration | Führt finalen Datenfreeze, produktiven Load und Nachkontrollen durch; Ergebnis ist ein operative Datenbasis zum Go‑Live. | Projektleitung, IT‑Betrieb, Data Owner, Implementierungspartner | High | ⟶ Cutover‑Plan, Tests | Must-have |
| Schnittstellenentwicklung und -konfiguration | Daten, Integration & Migration | Implementiert und konfiguriert Integrationen (inkl. Fehlerhandling); Ergebnis ist ein durchgängiger Datenaustausch mit definierten Betriebsprozessen. | Integrationsarchitekt, Implementierungspartner, Systemowner | High | ⟶ Interface‑Design | Must-have (bei Integration) |
| Identity/SSO-Integration und Provisioning | Daten, Integration & Migration | Bindet SSO an, automatisiert Nutzeranlage/Entzug (Joiner/Mover/Leaver); Ergebnis ist ein sicherer, wartbarer IAM‑Betrieb. | IAM, IT‑Betrieb, Security, Implementierungspartner | Medium | ⟶ Security/IAM‑Design | Must-have |
| Integration Monitoring/Logging (technisch & organisatorisch) | Daten, Integration & Migration | Richtet Monitoring, Alerts und Betriebsdashboards für Schnittstellen ein; Ergebnis ist eine stabil betreibbare Integrationsstrecke. | IT‑Betrieb, Observability/SRE, Implementierungspartner | Medium | ⟶ Schnittstellen | Should-have |
| OT/IoT/BMS/BIM-Integration | Daten, Integration & Migration | Optional: koppelt Gebäudeautomation/IoT/BIM‑Daten (z. B. Zustände, Zähler, Modelle); Ergebnis ist erweiterte Datenbasis für Betrieb/Optimierung. | TGA/GA‑Team, IT/OT‑Security, FM‑Ops, Integrationspartner | Kontextabhängig | ⟶ OT‑Sicherheitsanforderungen, APIs | Nice-to-have (bei Smart‑Building‑Zielbild) |
| Testmanagement (Plan, Testfälle, Defects) | Test & Abnahme | Plant Tests, erstellt Testfälle, steuert Defects/Retests; Ergebnis ist ein nachweisbarer Qualitäts- und Abnahmeprozess. | Testmanager, Key‑User, Implementierungspartner, PMO | Medium | ⟶ Teststrategie | Must-have |
| Systemtest/Konfigurationstest | Test & Abnahme | Prüft Konfiguration und Standardfunktionen; Ergebnis ist freigegebene Systembasis mit geschlossenen kritischen Defects. | Implementierungspartner, Fachtester, IT | Medium | ⟶ Konfiguration | Must-have |
| Integrationstest (End‑to‑End) | Test & Abnahme | Validiert Prozessketten über Systeme hinweg (z. B. ERP→FM→Reporting); Ergebnis ist nachgewiesene E2E‑Fähigkeit inkl. Fehlerhandling. | Integrationsarchitekt, Key‑User, Systemowner | High | ⟶ Schnittstellen, Testdaten | Must-have |
| User Acceptance Test und Fachabnahme | Test & Abnahme | Fachbereiche testen gegen Akzeptanzkriterien und geben frei; Ergebnis ist dokumentierte Abnahme inkl. Restpunkteliste. | Key‑User, Fachbereichsleitung, Projektleitung | High | ⟶ System-/Integrationstest | Must-have |
| Regressionstest und Release-Freeze | Test & Abnahme | Stabilisiert vor Go‑Live (Regression, Freeze‑Regeln); Ergebnis ist eine kontrollierte Release‑Baseline. | Testmanager, Implementierungspartner, PMO | Medium | ⟶ Defect‑Backlog | Should-have |
| Performance-/Lasttest | Test & Abnahme | Optional: testet Antwortzeiten/Batchläufe/Spitzenlast; Ergebnis ist belastbarer Nachweis für Skalierung (oder Tuning‑Backlog). | IT‑Betrieb, Performance Engineer, Implementierungspartner | Kontextabhängig | ⟶ produktionsnahe Daten/Umgebung | Nice-to-have (bei hoher Last meist nötig) |
| Security Testing (Vulnerability/PenTest) | Test & Abnahme | Optional/risikogetrieben: prüft Schwachstellen, Rechteausnutzung, Konfigurationshärtung; Ergebnis ist umgesetzter Maßnahmenplan. | IT‑Security, externer Tester, IT‑Betrieb | Kontextabhängig | ⟶ Security‑Design, testfähige Umgebung | Should-have (bei hohem Schutzbedarf Must) |
| Go‑Live Readiness Review | Test & Abnahme | Prüft Go‑Live‑Kriterien (Daten, Tests, Support, Cutover) und entscheidet; Ergebnis ist eine formale Go‑Live‑Freigabe. | Steering Committee, Projektleitung, IT‑Betrieb, FM | Medium | ⟶ Abnahme, Cutover | Must-have |
| Change Impact Assessment und Change‑Plan | Schulung & Change | Analysiert Auswirkungen auf Rollen/Arbeitsweisen und definiert Maßnahmen (Kommunikation, Training, Widerstandsmanagement); Ergebnis ist ein umsetzbarer Change‑Plan. | Change Manager, Projektleitung, FM‑Leitung, HR | High | ⟶ Stakeholderanalyse | Should-have |
| Trainingskonzept und Schulungsunterlagen | Schulung & Change | Plant rollenspezifische Trainingsformate und erstellt Unterlagen (Guides, Übungen); Ergebnis ist ein wiederholbares Trainingspaket. | Trainer, Key‑User, Implementierungspartner | Medium | ⟶ Prozesse, Konfiguration | Must-have |
| Key‑User/Train‑the‑Trainer | Schulung & Change | Qualifiziert Key‑User als Multiplikatoren; Ergebnis ist interne Befähigung für UAT, Support und Rollout. | Key‑User, Trainer, Implementierungspartner | Medium | ⟶ Trainingsunterlagen | Must-have |
| Endanwender-Schulung und Support-Onboarding | Schulung & Change | Schult Endanwender/Servicekräfte und rollt Supportprozesse aus; Ergebnis ist Nutzungs- und Supportfähigkeit im Alltag. | Trainer, Service Desk, FM‑Ops | Medium | ⟶ Key‑User‑Training | Must-have |
| Betriebsdokumentation und Runbooks | Schulung & Change | Erstellt Betriebs-/Supportdoku (z. B. Monitoring, Schnittstellen, Rechte, Notfälle); Ergebnis sind betriebsfähige Runbooks. | IT‑Betrieb, Implementierungspartner, Security | Medium | ⟶ Betriebsmodell, Integrationen | Must-have |
| Support-Setup (Service Desk, Knowledge Base) | Schulung & Change | Richtet Ticketprozesse, Kategorien, Wissensdatenbank und Eskalationen ein; Ergebnis ist ein skalierbarer Supportbetrieb. | Service Desk, ITSM Owner, FM‑Support, Implementierungspartner | Medium | ⟶ Betriebsmodell | Must-have |
| Pilotierung/Proof of Concept | Rollout & Übergabe | Optional: validiert Prozesse, Daten, Training in kleinem Umfang; Ergebnis ist ein abgesichertes Vorgehen für Skalierung/Rollout. | Projektleitung, Key‑User, Implementierungspartner | Kontextabhängig | ⟶ Konfiguration, Testmigration | Should-have (bei hoher Komplexität praktisch Must) |
| Rollout-Management (Wellen/Standorte/Module) | Rollout & Übergabe | Plant und steuert Rollout in Wellen inkl. Standortkoordination; Ergebnis ist ein kontrollierter, wiederholbarer Rollout‑Mechanismus. | Projektleitung, Rollout Manager, Standort-FM, IT | High | ⟶ Training, Support | Must-have |
| Go‑Live/Cutover Durchführung (inkl. Datenfreeze) | Rollout & Übergabe | Führt Cutover‑Runbook aus, schaltet produktiv, überwacht; Ergebnis ist ein geordneter Go‑Live. | IT‑Betrieb, Projektteam, Implementierungspartner, FM‑Ops | High | ⟶ Go‑Live‑Freigabe | Must-have |
| Hypercare/Early Life Support | Rollout & Übergabe | Stabilisierungsphase mit erhöhter Präsenz, schnellem Defect‑Fix und Nachschulungen; Ergebnis ist Übergang in Regelbetrieb. | Projektteam, Service Desk, Implementierungspartner | Medium | ⟶ Go‑Live | Should-have |
| Übergabe in Betrieb (Handover, SLAs, Verantwortlichkeiten) | Rollout & Übergabe | Übergibt System, Doku, offene Punkte und Betriebsverantwortung; Ergebnis ist formale Betriebsübernahme inkl. SLA‑Start. | IT‑Service‑Owner, FM‑Leitung, Implementierungspartner | Medium | ⟶ Runbooks, Support‑Setup | Must-have |
| Applikationsbetrieb und Monitoring | Betrieb, Support & Weiterentwicklung | Betreibt System (Verfügbarkeit, Monitoring, Backups), steuert Provider; Ergebnis ist stabiler Service mit Messwerten. | IT‑Betrieb, Provider/Partner, Service Owner | Kontextabhängig | ⟶ Betriebsmodell | Must-have |
| Incident/Problem/Change/Release Management | Betrieb, Support & Weiterentwicklung | Etabliert Betriebsprozesse für Störungen, Ursachen, Changes und Releases; Ergebnis ist kontrollierte Weiterentwicklung ohne Betriebschaos. | ITSM Owner, Service Desk, Implementierungspartner | Medium | ⟶ Supportmodell | Must-have |
| Patch-/Upgrade-Management inkl. Regression | Betrieb, Support & Weiterentwicklung | Plant Updates, testet vorab, rollt kontrolliert aus; Ergebnis ist sichere Aktualität (Security/Features) mit minimalen Ausfällen. | IT‑Betrieb, Testmanager, Vendor/Partner | Medium | ⟶ Teststrategie | Should-have |
| Benutzer- und Berechtigungsverwaltung (Lifecycle) | Betrieb, Support & Weiterentwicklung | Pflegt Rollen, Rezertifiziert Zugriffe, setzt Joiner/Mover/Leaver um; Ergebnis ist dauerhaft sichere Zugriffslage. | IAM, Security, Fachadmin, Service Desk | Medium | ⟶ IAM/SSO | Must-have |
| Datenqualitätskontrollen und Stammdatenpflege | Betrieb, Support & Weiterentwicklung | Etabliert regelmäßige Checks, Korrekturprozesse und Verantwortlichkeiten; Ergebnis ist dauerhaft nutzbare Datenbasis. | Data Owner, FM‑Datenpflege, Controlling | Medium | ⟶ Daten‑Governance | Should-have |
| Lizenz- und Lieferantenmanagement | Betrieb, Support & Weiterentwicklung | Überwacht Lizenznutzung, Kosten, SLA‑Erfüllung und Providerleistung; Ergebnis ist wirtschaftlicher, vertragskonformer Betrieb. | Einkauf, Service Owner, Vendor Manager | Low | ⟶ Verträge, KPIs | Should-have |
| Kontinuierliche Verbesserung (Backlog/Roadmap/Benefits) | Betrieb, Support & Weiterentwicklung | Steuert Erweiterungen, process tuning und Nutzenrealisierung; Ergebnis ist ein lebendes System statt „Einmal‑Projekt“. | Auftraggeber, FM‑Leitung, Product Owner, IT | Medium | ⟶ KPI‑Konzept, Betriebsdaten | Should-have |
| Datenschutz-/Sicherheitsreviews und Audit-Nachweise | Querschnitt: Governance, Sicherheit, Compliance | Führt regelmäßige Kontrollen durch (TOM‑Wirksamkeit, Logs, Rezertifizierung), liefert Audit‑Trail; Ergebnis sind belastbare Compliance‑Nachweise. | Datenschutz, IT‑Security, Internal Audit, IT‑Betrieb | Kontextabhängig | ⟶ Logging/IAM, Betriebsprozesse | Should-have (bei Regulierung Must) |
| Datenschutz‑Folgenabschätzung (DPIA) | Querschnitt: Governance, Sicherheit, Compliance | Optional/bedingungsgetrieben: bewertet Risiken und Maßnahmen, wenn Verarbeitung voraussichtlich hohes Risiko birgt; Ergebnis ist DPIA‑Dokumentation inkl. Maßnahmenplan. | Datenschutzbeauftragter, Legal, IT‑Security, Fachbereich | Kontextabhängig | ⟶ Datenklassifikation, Architektur | Nice-to-have (bei DPIA‑Kriterien Must) |
Hinweis zur Integrations- und Datenarbeit als „kritischer Pfad“: In der Praxis ist es üblich, dass Datenbasis und Schnittstellen die Komplexität dominieren; hierzu existieren explizite Branchenhinweise sowohl zur Notwendigkeit standardisierter Datenstrukturen (inkl. Qualitätssicherung und Datenaustausch) als auch zur Notwendigkeit eines Schnittstellenkonzepts und stark schwankenden Aufwänden in der Abhängigkeit von IT‑Umfeld und Funktionsumfang.
Kritische Abhängigkeiten und Varianten nach Kontext
Die folgende Darstellung fokussiert auf Abhängigkeiten, die erfahrungsgemäß über Erfolg/Misserfolg entscheiden, weil sie entweder späte Überraschungen erzeugen oder zentrale Qualitätsrisiken treiben.
Einfaches Abhängigkeitsbild (vereinfachte Skizze):
→ Anforderungen & Soll‑Prozesse
→ Datenmodell & Integrationsdesign
→ Konfiguration/Build
→ Datenbereinigung + Migration (iterativ) + Schnittstellen (iterativ)
→ System-/Integrationstest → UAT/Abnahme
→ Training/Change
→ Cutover/Go‑Live → Hypercare → Regelbetrieb
Datenmigration hängt von Datenqualität und Datenmodell ab. Unsere Praxis zeigt die Notwendigkeit, eine standardisierte Datenbasis aufzubauen und dabei Anforderungen an Datenerfassung, Qualitätssicherung, Datenaustausch und Datenpflege zu berücksichtigen; das ist unmittelbar vorgelagert zu jeder belastbaren Migration. methodisch ist Migration als Kette aus Identifizieren, Extrahieren, Transformieren, Laden und Validieren zu verstehen; ohne definierte Mappings und Validierungsregeln entsteht keine verlässliche produktive Datenbasis.
Integration hängt von API-/Schnittstellenfähigkeit und frühzeitigem Schnittstellenkonzept ab. Für eine anforderungsgerechte Informations- und Wissensverwaltung sind in der Regel Schnittstellen zu bestehender bzw. neuer Software notwendig und es ist ein Schnittstellenkonzept zu erstellen; Aufwände schwanken teils erheblich nach Prozess- und IT‑Komplexität. Herstellerseitige Implementierungsleitfäden weisen zudem darauf hin, dass Integration in Projekten zum Bottleneck werden kann – entsprechend sollten Integrationsaktivitäten frühzeitig geplant und testbar gemacht werden.
Test/Abnahme hängt an „produktionsnahen“ Daten und stabilen Integrationen. UAT ist typischerweise fachlich verantwortet, während Unit/Integration‑Tests stärker bei Implementierungsteam/Technik liegen; diese Rollen- und Testartenlogik ist in Standardvorgehen beschrieben. Für FM‑Software ist das praktisch besonders relevant, weil viele fachliche Akzeptanzkriterien erst mit realistischen Objekt-/Asset-/Flächen- und Bewegungsdaten sowie Schnittstellenflüssen überprüfbar werden.
Change/Training hängt am stabilen Soll‑Prozessdesign. Ein strukturierter Change‑Management‑Plan umfasst üblicherweise konkrete Schritte/Strategien und kann explizit einen Trainingsplan enthalten; ohne saubere Prozess- und Rollenklärung wird Training schnell „Feature‑Tour“ statt Befähigung. Ergänzend ist in etablierten Veränderungsmodellen die aktive Führung/Kommunikation über mehrere Schritte zentral (z. B. Koalition, Vision, Barrieren abbauen, Quick Wins).
Security/Datenschutz-Varianten
wann optional „faktisch verpflichtend“ wird. Sobald personenbezogene Daten verarbeitet werden (z. B. Nutzerkonten, Beauftragte, Leistungs-/Ticketdaten, Zugriffsdaten), sind risikobasierte technische und organisatorische Maßnahmen sowie regelmäßige Wirksamkeitsprüfung einschlägig. Eine DPIA ist erforderlich, wenn die Verarbeitung voraussichtlich ein hohes Risiko birgt; Kriterienbeispiele und rechtlicher Rahmen sind veröffentlicht (Art. 35 und behördliche Hinweise).
Kontextfaktoren, die die Ausprägung einzelner Services stark verändern:
- Standort-/Objektzahl & Heterogenität: treibt Datenmenge, Rollout‑Komplexität, Trainingsaufwand.
- Integrationsdichte (ERP/HR/Finance/IAM/BMS/IoT): treibt Schnittstellenanzahl, Testaufwand und Betriebsüberwachung; Schnittstellenaufwände können erheblich variieren.
- Datenlage (Qualität, Vollständigkeit, Eigentümerschaft): treibt Bereinigung, Migration, Reconciliation und spätere Datenpflege; standardisierte Datenbasis gilt als kritischer Erfolgsfaktor.
- Betriebsmodell (SaaS vs. On‑Prem/Hybrid): verschiebt Aufgaben zwischen Provider und eigener IT (z. B. Patch‑Management, Monitoring, Audit‑Nachweise).
- Schutzbedarf/Regulierung: beeinflusst Security‑Tests, Logging, Rezertifizierungen und DPIA‑Pflichten.
| Typisches Risiko/Problem | Warum es passiert / Woran man es erkennt | Knappe Gegenmaßnahme (Dienstleistungen, die das adressieren) |
|---|---|---|
| Ziele/Scope „wandern“ und Prioritäten zerfasern | Unklare Zielbilder, fehlende Governance, zu viele Module „sofort“ | Projektauftrag + Zielbild/Roadmap + Change Control; klare MVP‑Schnitte (Projektauftrag, Roadmap, Backlog‑Priorisierung) |
| Soll‑Prozesse sind nicht harmonisiert | Standorte/Teams arbeiten unterschiedlich; IT bildet Wildwuchs ab | Verbindliches Soll‑Prozessdesign inkl. Rollen/Regeln; Prozess‑Owner benennen (Soll‑Prozessdesign, Rollenmodell) |
| Datenmigration scheitert an Qualität/Verantwortung | Dubletten, fehlende Attribute, keine Datenowner; Validierung fehlt | Daten‑Governance + Datenbereinigung + iterierte Testmigrationen + Reconciliation; Migration als ETL‑Kette mit Validierung umsetzen |
| Schnittstellen verzögern Go‑Live | APIs unklar, Systemowner spät verfügbar, Fehlerhandling fehlt | Frühzeitiges Schnittstellenkonzept, technische Spezifikation, Monitoring; Integration früh testen; Integration kann Bottleneck werden |
| Tests liefern „falsche Sicherheit“ | Testdaten unrealistisch; UAT zu spät; Defects sammeln sich | Teststrategie mit Testdatenmanagement; UAT früh planen und mit Key‑Usern führen; klare Defekt‑Triage |
| Nutzerakzeptanz bleibt aus | Training zu technisch, fehlender Change‑Plan, Führung nicht sichtbar | Strukturierter Change‑Plan inkl. Zielbildkommunikation und Trainingsplan; Key‑User‑Netzwerk/Multiplikatoren |
| Go‑Live „ohne Betriebsfähigkeit“ | Runbooks fehlen, Support nicht aufgesetzt, SLAs ungeklärt | Betriebs-/Supportmodell, Runbooks, Service Desk Setup, Hypercare, formale Übergabe (Betriebsmodell, Runbooks, Hypercare) |
| Datenschutz/IS‑Compliance wird nachgezogen | Datenklassifikation spät; TOM‑Nachweise fehlen; DPIA übersehen | Privacy/Security‑Vorprüfung zu Beginn, TOM‑Dokumentation und regelmäßige Wirksamkeitsprüfung; DPIA‑Screening und ggf. DPIA |
Welche Informationen für die spätere Detailausarbeitung erforderlich sind
Damit jede Dienstleistung im nächsten Schritt belastbar (inkl. konkreter Deliverables, Checklisten, Aufwandskorridoren und Beispielvorlagen) ausgearbeitet werden kann, benötigen Sie typischerweise die folgenden Eckdaten. Die Tabelle zeigt zugleich, welche Services dadurch „größer/kleiner“ werden.
| Benötigte Kontextinformation | Beispiele/Optionen | Einfluss auf Dienstleistungen |
|---|---|---|
| Organisations- und Standortstruktur | Anzahl Standorte/Gebäude, Internationalität, Betreiber-/Dienstleistermodell | Rollout‑Management, Trainings, Prozessharmonisierung, Datenmodell‑Tiefe, Supportmodell |
| Ziel-Funktionsumfang | Instandhaltung, Helpdesk, Flächen, Assets, Verträge, Energiemonitoring/ESG, Workplace | Backlog‑Umfang, Konfigurationstiefe, Schnittstellen, Reporting, Testumfang |
| Systemlandschaft/Integrationen | ERP, HR, Finance, IAM/SSO, DMS, GIS, BMS/GA, IoT‑Plattform | Schnittstellenkonzept, Integrationsentwicklung, Monitoring/Logging, Security‑Tests, Cutover‑Komplexität |
| Datenquellen & Datenqualität | Alt‑System, Excel, CAD/BIM, Sensorik; Vollständigkeit/Standardisierung | Datenbereinigung, Mapping, Migration, Reconciliation, Daten‑Governance |
| Betriebsmodell | SaaS/Cloud/Hybrid/On‑Prem; Provider‑Rollen | Umgebungssetup, Patch-/Upgrade‑Prozesse, Vertrags-/SLA‑Design, Audit‑Nachweise |
| Nutzergruppen & Rollen | Anzahl Nutzer, Rollenvielfalt, externe Nutzer (Dienstleister) | IAM/Provisioning, Rollen/Berechtigungen, Trainingsdesign, Supportaufwand |
| Sicherheits- und Compliance-Anforderungen | Schutzbedarf, personenbezogene Daten, Auditpflichten, KRITIS‑Nähe | TOM‑Design, Logging, Rezertifizierung, Security Testing, DPIA‑Screening/DPIA |
| Zeit-/Budgetrahmen & Sourcing | interne Kapazitäten, Implementierungspartner, PMO‑Reife | Vorgehensmodell (agil/hybrid), Umfang externer Services, Risikopuffer, Rollout‑Takt |