Lastenheft SAP-CAFM-Integration
Facility Management: FM-Software » Strategie » SAP » Lastenheft
Exemplarisches Lastenheft zur Integration einer On-Premises-CAFM-Software in eine ERP-Landschaft auf Basis von SAP S/4HANA oder SAP ERP
Dieses Lastenheft beschreibt die fachlichen, technischen, sicherheitsrelevanten und betrieblichen Anforderungen für die Integration einer nicht näher spezifizierten On-Premises-CAFM-Software in eine bestehende ERP-Landschaft. Da die genaue CAFM-Lösung, das ERP-Release und die aktivierten Module nicht bekannt sind, ist das Dokument bewusst variantenfähig aufgebaut. Es deckt sowohl eine heutige Business-Suite-/ECC-Landschaft als auch eine aktuelle on-premises-Landschaft auf Basis von S/4HANA ab. Diese Differenzierung ist sachlich erforderlich, weil die Wartungs- und Zukunftsperspektiven unterschiedlich sind: Für Business Suite 7 gilt Mainstream Maintenance bis Ende 2027 und optional Extended Maintenance bis Ende 2030; für S/4HANA 2023 gilt ein siebenjähriger Mainstream-Maintenance-Zeitraum je Release. Vergleichbar ist die Lage bei bestehenden PI/PO-Landschaften, deren Mainstream Maintenance 2027 endet; eine Verlängerung ist bis 2030 möglich.
CAFM-Lastenheft für SAP-ERP-Integration
- Zielbild
- Zielbild und Annahmen
- Fachliches Soll-Modell
- Compliance-Anforderung
- Qualitätssicherung, Migration und Betrieb
Zielbild
Für das Zielbild wird eine lose gekoppelte Integrationsarchitektur empfohlen. Im Regelfall soll das ERP-System die führende Quelle für technische Objekte, Material-/Bestandsinformationen, Geschäftspartner, Kosten- und Buchungsbezüge sowie wartungsrelevante Vorgänge sein; das CAFM-System soll als führendes System für Flächen-, Raum-, Workplace- und FM-spezifische Nutzungsprozesse fungieren, sofern keine SAP-seitige RE-FX- oder EAM-Struktur die Golden-Record-Rolle übernimmt. Diese Trennung folgt sowohl den üblichen CAFM-Teilbereichen gemäß GEFMA444 als auch den in S/4HANA vorhandenen Geschäftsobjekten für Functional Location, Equipment, Maintenance Order, Business Partner, Material Document/Material Stock, Purchase Contract und Service Contract.
Technologieauswahl
Als präferierte Technologieauswahl gilt: released APIs und Standardobjekte vor kundeneigenen Punkt-zu-Punkt-Zugriffen; synchrone Kommunikation nur dort, wo ein echter Geschäftsvorfall eine unmittelbare Rückmeldung erfordert; asynchrone oder batch-orientierte Kommunikation für Massen-, Delta- und Abgleichprozesse. Für moderne Integrationsszenarien sind OData- und SOAP-APIs auf S/4HANA zu bevorzugen; für Bestandslandschaften und breit verfügbare Standardverteilung bleiben RFC/BAPI sowie IDoc/ALE relevant. Als Middleware kommen je nach Randbedingungen direkte On-Premises-Kopplung, SAP Process Orchestration, SAP Integration Suite mit Edge Integration Cell oder eine Drittplattform wie MuleSoft Anypoint Connector for SAP in Betracht. Cloud Integration kann Integrationsflüsse über Cloud-, On-Premises- und Hybrid-Landschaften ausführen; die Edge Integration Cell erlaubt die Verarbeitung in einer privaten Landschaft, und der SAP-Connector basiert auf SAP JCo und unterstützt RFC/BAPI- sowie IDoc-Szenarien.
Annahmen
| Leitentscheidung | Empfehlung |
|---|---|
| Zielarchitektur | Lose gekoppelte service- und nachrichtenorientierte Integration mit kanonischem Datenmodell |
| Führende Systeme | ERP führend für technische Objekte, Material, Geschäftspartner, Kosten; CAFM führend für Räume/Flächen und FM-Nutzungslogik, falls keine RE-FX-Leitstruktur besteht |
| Bevorzugte Protokolle | OData/REST-nahe APIs und SOAP bei released APIs; IDoc/BAPI für stabile Standardverteilung; CSV/ETL nur für Initiallasten und Fallback |
| Transaktionsprinzip | Lokale Commit-Grenzen je System, keine verteilte 2PC über Systemgrenzen; Kompensation und Reprocessing statt globaler Transaktionen |
| Rollout | Wellenförmig nach Standort, Gebäudebereich oder Prozessdomäne; Big Bang nur bei geringer Komplexität |
| Monitoring | Anwendungsprotokoll, IDoc-Monitoring, Gateway-Logs, SAP Application Interface Framework sowie optional SAP Cloud ALM oder SAP Solution Manager |
Zielbild und Annahmen
Der Projektgegenstand umfasst die Integration eines CAFM-Systems mit den fachlichen Domänen Flächen/Räume, technische Anlagen, Wartungsaufträge, Inventar/Material, Verträge, Nutzer und Berechtigungen. Das Lastenheft bezieht ausdrücklich auch deutsche Ausschreibungs- und Compliance-Rahmenbedingungen ein. Im CAFM-Umfeld sind Flächenmanagement, Instandhaltungsmanagement, Vertragsmanagement und Workplace Management etablierte Funktionsdomänen; zugleich stehen im ERP technische Standardobjekte und veröffentlichte Integrationsschnittstellen zur Verfügung, die für ein belastbares Sollbild vorrangig genutzt werden sollen.
| Dimension | Variante A | Variante B | Variante C | Projektwirkung |
|---|---|---|---|---|
| ERP-Kernsystem | SAP ERP 6.0 / Business Suite 7 | S/4HANA on-premise 2022/2023 | S/4HANA on-premise 2025+ | Bestimmt API-Verfügbarkeit, Zukunftssicherheit, Datenmodell und Wartungsstrategie |
| FM-relevante Module | PM, MM, FI, HCM | Asset Management, MM, FI, HCM, optional RE-FX | Asset Management, MM, FI, HCM, RE-FX, Service | Bestimmt, ob Räume, Verträge, Kosten und Nutzer standardnah oder kundeneigen abgebildet werden |
| CAFM-Bauart | Externe On-Premises-Anwendung | SAP-nahes Add-on / ABAP-integriert | Externe Anwendung mit Middleware | Bestimmt Kopplungstiefe, Upgrade-Risiko und Monitoring-Konzept |
| Middleware-Stand | Keine / direkte Kopplung | PI/PO vorhanden | Integration Suite / Edge / Drittmiddleware | Bestimmt Entkopplung, Routing, Mapping, Wiederanlauf und Governance |
| IAM/SSO | Lokales AD/LDAP | SAP SSO/SAML-Landschaft | Zentrales IdP mit Principal Propagation | Bestimmt AuthN/AuthZ, Rollenmapping und Benutzerlebenszyklus |
| Raummodell | CAFM führend | RE-FX führend | Technischer Platz/Z-Objekt führend | Bestimmt Golden Record für Gebäude-/Raumhierarchien |
| Vertragsmodell | CAFM führend | MM-Vertrag / Service Contract führend | RE-FX-Vertrag führend | Bestimmt Verteilung von kaufmännischer vs. FM-fachlicher Vertragslogik |
| Prüffeld der Ist-Analyse | Zu erhebende Information | Bedeutung für das Sollbild |
|---|---|---|
| CAFM-Produkt und Release | Hersteller, Version, On-Prem-Stack, Datenbank, API-Typen, Event-Fähigkeit, Import-/Exportformate | Legt Integrationsmuster, Mapping-Aufwand und Rechtekonzept fest |
| ERP-Release | ECC/EHP oder S/4HANA-Release, Supportstand, aktivierte Business Functions | Bestimmt verfügbare released APIs, Wartungshorizont und Standardobjekte |
| Modulbestand | EAM/PM, MM, FI/CO, HCM, RE-FX, DMS, Workflow, Fiori/Gateway | Bestimmt fachliche Führungsobjekte und Integrationsreichweite |
| Kundeneigene Erweiterungen | Z-Tabellen, Z-BAPIs, BAdIs, User Exits, kundeneigene IDocs, benutzerdefinierte Fiori-Services | Erhöht Analyse-, Test- und Upgrade-Aufwand |
| Identitätslandschaft | AD/LDAP, IdP, SAML, Kerberos, Zertifikats-PKI, PFCG-Rollenmodell | Bestimmt SSO- und Berechtigungsarchitektur |
| Datenqualität | Dubletten, fehlende technische Plätze, uneinheitliche Raumschlüssel, Material-/Seriennummernqualität, veraltete Benutzerkonten | Beeinflusst Migrationsstrategie und Abnahmekriterien |
| Betriebsmodell | 24x7 vs. Bürozeit, DR-Standort, Backup/RPO, SIEM/SOC, vorhandenes Monitoring | Bestimmt SLAs, RTO/RPO und Betriebsorganisation |
| Nichtproduktionslandschaft | DEV, QAS, PREPROD, Schulung, anonymisierte Testdaten | Bestimmt Testkonzept, Rollout-Sicherheit und Rehearsals |
| In Scope | Out of Scope im Basisszenario |
|---|---|
| Stammdaten- und Bewegungsdatenintegration für die benannten Domänen | Vollständige Neugestaltung des ERP-Zielprozesses |
| Rollen- und Berechtigungskopplung | Vollständige ERP-Konversion nach S/4HANA |
| Monitoring, Logging, Fehlerbehandlung, Reprocessing | BIM-Gesamtintegration einschließlich IFC/CDE, sofern nicht separat beauftragt |
| Initialmigration, Delta-Ladeverfahren, Cutover und Backout | Mobile-App-Strategie jenseits der dafür erforderlichen Schnittstellen |
| Grobe Termin-, Aufwand-, Risiko- und SLA-Festlegung | Einführung eines unternehmensweiten MDM-Programms außerhalb der Projektgrenzen |
| Stakeholder / Rolle | Hauptverantwortung |
|---|---|
| Auftraggeber / Lenkungsausschuss | Freigaben, Budget, Zielkonfliktentscheidung, Scope-Entscheidung |
| FM-Leitung / CAFM-Product Owner | Fachliche Anforderungen für Flächen, Räume, Verträge, Serviceprozesse |
| Instandhaltung / EAM-Verantwortung | Referenzprozesse für technische Objekte, Wartungsaufträge, Rückmeldungen |
| Einkauf | Vertrags-, Material- und Beschaffungsbezug, MM-relevante Prozesse |
| Finanzen / Controlling | Kostenobjekte, Kontierung, Belegbezug, Revisions- und GoBD-Anforderungen |
| HR / IAM | Nutzerstammdaten, Organisationsstruktur, Berechtigungslebenszyklus |
| SAP Applikationsverantwortliche | Fachliches ERP-Customizing, released APIs, Regressionen |
| SAP Basis / Infrastruktur | Transportwesen, Zertifikate, Gateway, Performance, Backup, DR |
| Integrationsarchitekt / Middleware-Team | Schnittstellendesign, Message Routing, Fehlerkonzept |
| CAFM-Hersteller / Implementierungspartner | Produktnahe API- und Datenmodellkenntnis, Customizing, Support |
| Informationssicherheit / Datenschutz / Betriebsrat | Freigabe von Sicherheits- und personenbezogenen Verarbeitungsaspekten |
| Key User / Fachtester | Testfälle, UAT, Abnahmeempfehlung, Hypercare-Rückmeldung |
Fachliches Soll-Modell
Das Soll-Modell basiert auf einem kanonischen Integrationsmodell mit klaren Objektidentitäten, Delta-Fähigkeit und belastbarer Objektführerschaft. Für technische Strukturen stehen im ERP die Standardobjekte Functional Location und Equipment zur Verfügung; Functional Locations repräsentieren den Ort der Instandhaltungstätigkeit, Equipment kann an Functional Locations installiert und wieder ausgebaut werden. Für Raummodelle existiert keine universell richtige Standardabbildung: Wenn RE-FX genutzt wird, sind architektonische Objekte wie Gebäude und Raum fachlich naheliegend; ohne RE-FX ist häufig ein Mapping auf Functional Location oder ein kundeneigenes Raumobjekt erforderlich. Für Personen und Benutzer sollte in S/4HANA der Business Partner als zentrales Objekt dienen; Business User und PFCG-Rollen bilden darauf auf. Für Verträge kommen — je nach Fachbedeutung — Purchase Contracts, Service Contracts oder RE-FX-Verträge in Betracht. Für Inventar- und Bestandsbezug stehen Material-, Stock-, Reservation- und Material-Document-APIs zur Verfügung.
Integrationsarchitektur und Schnittstellen
Die Integrationsarchitektur hat vier Aufgaben gleichzeitig zu erfüllen: fachliche Objektkonsistenz, technische Entkopplung, nachvollziehbares Fehlerhandling und Release-Fähigkeit. Dafür sind Standardmechanismen aus der ERP-Welt weiterhin relevant: IDoc/ALE für robuste asynchrone Verteilung, RFC/BAPI für synchrone Funktionsaufrufe, ABAP-Web-Services für SOAP-basierte Services sowie OData-APIs für moderne, veröffentlicht nutzbare Integrationen. Für S/4HANA gilt zusätzlich, dass zahlreiche APIs über den Business Accelerator Hub dokumentiert sind, darunter Functional Location, Equipment, Maintenance Order, Business Partner, Material Document, Material Stock, Purchase Contract und Service Contract. Das ältere Maintenance-Order-API wurde ab S/4HANA 2023 durch eine Nachfolgeversion ersetzt; bei Purchase Contracts wurde Version 1 durch Version 2 abgelöst.
Sicherheit und Compliance
Für Authentifizierung und Single Sign-On sind standardisierte Verfahren verbindlich vorzusehen. Im SAP-Umfeld werden Kerberos, X.509-Zertifikate und SAML 2.0 ausdrücklich als flexibler und sicherer als proprietäre Logon-Tickets empfohlen. Für GUI- und RFC-nahe Szenarien ist SNC zu berücksichtigen; SAP weist darauf hin, dass in einer Default-Konfiguration Benutzername und Passwort über die GUI-Anmeldung ohne SNC unverschlüsselt übertragen werden können. Für OData-/Gateway-Szenarien unterstützt SAP Gateway SAML Assertions, und ICF-Services können auf SSL-Clientzertifikate verpflichtend gestellt werden. In Hybrid-Szenarien kann Principal Propagation über Cloud Connector bzw. Connectivity Service die Nutzeridentität sicher an On-Premises-Systeme weiterreichen.
| Sicherheitsanforderung | Lastenheft-Anforderung |
|---|---|
| Authentifizierung interaktiv | SAML 2.0 oder Kerberos/AD-basierte SSO-Integration; lokales Passwort-Login nur für Break-Glass-User |
| Authentifizierung System-zu-System | mTLS mit technischen Kommunikationsbenutzern oder Zertifikatsauthentifizierung; keine geteilten Dialogbenutzer |
| RFC-Sicherheit | RFC-Destinationen ausschließlich über definierte SM59-Ziele; bei sensitiven Verbindungen SNC aktiv |
| OData-/HTTP-Sicherheit | HTTPS verpflichtend; TLS gemäß aktueller BSI-Empfehlung; HSTS/Reverse-Proxy-Policies projektspezifisch zu prüfen |
| Zertifikatsmanagement | Zentrale PKI, dokumentierter Lebenszyklus, rechtzeitige Rotation, Ersatzketten und Testzertifikate für Non-Prod |
| Autorisierung ERP | PFCG-Rollen mit Least-Privilege, Trennung Single/Composite Roles, Fiori-Kataloge nur rollenbasiert |
| Autorisierung CAFM | Rollenmodell nach Objektklasse, Aktivität und organisatorischem Geltungsbereich; Mapping auf ERP-Berechtigungsklassen |
| SoD / kritische Kombinationen | Trennung von Stammdatenpflege, Freigabe, Buchung, Reprocessing und Berechtigungsadministration |
| Transport- und Inhaltsverschlüsselung | TLS für Übertragung; zusätzliche Verschlüsselung ruhender Daten für besonders schutzbedürftige Felder projektspezifisch |
| Geheimnis-Management | Zugriffsdaten, private Schlüssel, Zertifikats-PSEs und API-Secrets nur in zentralem Secret-Store, kein Klartext in Interfaces |
| Auditierbarkeit | Jede fachlich relevante Mutation muss Benutzer-/Systemkontext, Zeitstempel und Korrelationsschlüssel enthalten |
| Sicherheitsereignisse | Anbindung an SIEM/SOC; Alarmierung bei wiederholten Auth-Fehlern, Queue-Stau, Reprocessing-Häufung, Berechtigungsfehlern |
Die Berechtigungslogik ist in der ERP-Welt konsistent auf Rollen auszurichten: PFCG dient der Rollenpflege; der Zugriff auf Fiori-Kataloge und -Gruppen wird über PFCG-Autorisierungen kontrolliert; Business Roles entsprechen in der On-Premises-Logik PFCG-Rollen. Für Plant-Maintenance-bezogene Funktionen dokumentiert SAP Standard-Autorisierungsprüfungen für Anlegen, Ändern und Anzeigen von Wartungsobjekten. Damit ist eine saubere Trennung in fachliche Rollen, technische Kommunikationsrollen und Supportrollen ausdrücklich möglich und gefordert.
Compliance-Anforderung
| Compliance-Anforderung | Lastenheft-Anforderung für Deutschland |
|---|---|
| DSGVO-Rechtsgrundlage | Für jede personenbezogene Verarbeitung ist die Rechtsgrundlage dokumentiert festzulegen; ohne tragfähige Rechtsgrundlage keine Produktivsetzung |
| Datenminimierung | Nur erforderliche Personen- und Nutzungsdaten in das jeweils andere System übertragen; fakultative Felder standardmäßig deaktiviert |
| Zweckbindung | Personen- und Beschäftigtendaten dürfen nur für klar definierte FM-/Betriebszwecke genutzt werden |
| Privacy by Design | Pseudonymisierung/Maskierung in Non-Prod; restriktive Default-Einstellungen; Protokolle ohne überflüssige Klardaten |
| Betroffenenrechte | Prozesse für Auskunft, Berichtigung, Löschung und Einschränkung müssen systemübergreifend definierbar sein |
| BDSG / Beschäftigtendaten | Bei Nutzer-, Organisations- und Bewegungsdaten mit Personenbezug ist das Beschäftigtendatenregime zu prüfen; Mitbestimmungsfragen frühzeitig adressieren |
| Protokollierung / Detektion | Logging- und Detektionsanforderungen nach BSI-Mindeststandard; Ereignisse kategorisieren, aufbewahren und auswerten |
| TLS / Kryptografie | Verschlüsselungsparameter und Chiffren nach aktueller TR-02102-2 des BSI |
| BCM / RTO-RPO | Zielwerte aus Business-Impact-Analyse gemäß BCM/BSI-Standard 200-4 ableiten |
| NIS-2 | Falls das Unternehmen unter die deutsche NIS-2-Regulierung fällt, sind zusätzliche Sicherheits- und Meldepflichten umzusetzen |
| GoBD | Soweit Verträge, Belegbezüge, Freigaben oder revisionsrelevante Protokolle steuerlich oder handelsrechtlich relevant sind, ist GoBD-konforme Nachvollziehbarkeit sicherzustellen |
| AVV / Dienstleistersteuerung | Bei externer Projekt- oder Betriebsunterstützung sind Rollen von Verantwortlichem/Auftragsverarbeiter und Verträge eindeutig festzulegen |
Die datenschutz- und sicherheitsrechtlichen Anforderungen sind in Deutschland nicht optional: Es müssen Verarbeitungen rechtmäßig, fair, transparent, zweckgebunden und minimiert erfolgen; nach Darstellung der Bundesbeauftragte für den Datenschutz und die Informationsfreiheit gilt das Verbotsprinzip und Privacy by Design ist zentral. Das Bundesamt für Sicherheit in der Informationstechnik fordert aktuelle TLS-Standards sowie Mindestanforderungen an Protokollierung und Detektion; BCM-Anforderungen werden im BSI-Standard 200-4 konkretisiert. Für Deutschland ist zusätzlich zu beachten, dass das neue BSI-Gesetz zur NIS-2-Umsetzung seit Dezember 2025 gilt; ob die Regulierung greift, ist organisatorisch zu prüfen. Für steuerlich/revisionsrelevante elektronische Unterlagen sind die GoBD einschlägig.
Qualitätssicherung, Migration und Betrieb
Für die Zielarchitektur sind nicht-funktionale Anforderungen verbindlich zu definieren und zu messen. Gleichzeitig ist ein belastbares Test-, Migrations- und Betriebskonzept erforderlich. SAP selbst weist in den Operations Guides darauf hin, dass die Produktdokumentation ein tägliches Betriebshandbuch nicht ersetzt; für Betrieb und Monitoring sind deshalb projektindividuelle Runbooks, Alarmierungswege und Verantwortlichkeiten zwingend zu erstellen. Für Tests stehen je nach Landschaft Test Management in SAP Cloud ALM oder im Test Suite von SAP Solution Manager zur Verfügung; für PI-/PO-nahe Regressionstests existieren das PIT-Umfeld sowie die Testing-Funktionen im Umfeld der Integration Suite. Für Transitionen sind SAP Readiness Check und — bei ERP-zu-S/4HANA-Umstellungen — Data Transition Validation einschlägige Werkzeuge. Die Risiko- und Priorisierungslogik dieses Lastenhefts ist insbesondere an zwei extern begründeten Randbedingungen ausgerichtet: erstens den Wartungshorizonten von Business Suite/PI-PO und zweitens den verschärften deutschen Sicherheits- und Datenschutzpflichten einschließlich BSI-Anforderungen und — falls einschlägig — NIS-2.
| Art | Kriterium | Messung / Nachweis |
|---|---|---|
| Fachliches Akzeptanzkriterium | Alle priorisierten Sollprozesse für Raum, Anlage, Auftrag, Inventar, Vertrag, Nutzer und Berechtigung sind im UAT erfolgreich nachgewiesen | UAT-Protokoll mit Freigabe der Fachbereiche |
| Fachliches Akzeptanzkriterium | Führungsobjekte und Änderungsberechtigungen je Domäne sind schriftlich beschlossen | Signiertes Governance-Dokument |
| Technisches Akzeptanzkriterium | Erfolgsquote produktionsnaher Integrationsfälle ≥ 99,5 % im Abnahmelauf | Testreport / Monitoring-Auswertung |
| Technisches Akzeptanzkriterium | Keine offenen P1-/P2-Defekte zum Go-live | Defektboard und Freigabebeschluss |
| Technisches Akzeptanzkriterium | Reconciliation-Abweichung in initialem Produktivload < 0,5 % je Objektklasse; Restabweichungen klassifiziert | Reconciliation-Report |
| Sicherheits-Akzeptanzkriterium | Keine kritischen Security Findings; Berechtigungsmodell und SSO freigegeben | Security-Abschlussbericht |
| Betriebs-Akzeptanzkriterium | Monitoring, Alarmierung, Runbooks, Zertifikatsregister und Supportübergabe vollständig | Betriebsübergabeprotokoll |
| Migrations-Akzeptanzkriterium | Mindestens eine erfolgreiche Cutover-Probe inkl. Backout-Test | Cutover-Protokoll |
| Formales Abnahmekriterium | Lenkungsausschuss bestätigt Zielerreichung, Restpunkteliste und Hypercare-Vorgehen | Abnahmeprotokoll |
| Formales Abnahmekriterium | SLA, Eskalation, Verantwortlichkeiten und Supportwege sind vertraglich fixiert | Betriebs- und SLA-Anlage |
Die Abnahme gilt als erbracht, wenn fachliche Akzeptanz, technische Stabilität, Sicherheitsfreigabe und betriebliche Übernahme gleichzeitig vorliegen. Eine rein technische Inbetriebsetzung ohne freigegebene Governance zu Führungsobjekten, Berechtigungen, Monitoring und Reprocessing erfüllt die Anforderungen dieses Lastenhefts ausdrücklich nicht.