IT-Konzept SAP / ERP: Integration, Kostenstruktur, Beschaffung

Die Kostenstruktur ist in einmalige Implementierungskosten und wiederkehrende Betriebskosten zu gliedern. Einmalig zu berücksichtigen sind Lizenzen beziehungsweise Subscriptions, Systemeinrichtung, Rollen- und Berechtigungskonzeption, Interface-Entwicklung, Middleware-Konfiguration, Datenbereinigung und Migration, Testmanagement, Abnahmeunterstützung und Cutover. Wiederkehrend zu berücksichtigen sind Softwarewartung oder Cloud-Subscription, HANA- beziehungsweise Plattformbetrieb, Zertifikats- und Schlüsselmanagement, Integrationsmonitoring, 2nd- und 3rd-Level-Support, Release- und Patchmanagement sowie Backup- und Recovery-Betrieb. Im SAP-Funktionsumfang ist dokumentiert, dass einzelne Features separate Lizenz- oder Subskriptionsbedarfe auslösen können. Für die vergabeseitige Strukturierung der Beschaffung ist eine modulare Leistungsbestellung entlang der FM- und ERP-Funktionsbereiche sachgerecht; DIN EN ISO 41012 adressiert strategische Beschaffung und die Entwicklung von Vereinbarungen im Facility-Management-Kontext.

Die Beschaffung ist so auszugestalten, dass die Module MM, PM/EAM und FI/CO als Grundumfang beauftragt werden; SD ist als Optionsmodul zu behandeln. Der Ausschreibungsumfang muss mindestens die fachliche Konfiguration, die Datenmigration, die Integrationsleistungen, die Testunterstützung, die Betriebsübergabe, das Monitoringkonzept, die Sicherheitskonfiguration und die Supportleistungen erfassen. Für Beschaffungs- und Freigabeprozesse sind die in SAP dokumentierten flexiblen Workflows für Purchase Orders und Purchase Requisitions verbindlich einzubeziehen; für Instandhaltungsaufträge sind die dokumentierten Approval-Workflows für Maintenance Orders vorzusehen.

Das Stammdatenmodell hat technische, organisatorische, kaufmännische und servicedeskbezogene Objekte zu umfassen. Technische Kernobjekte sind Functional Location, Equipment, Meldung, Auftrag, Aufgabenliste und gegebenenfalls Wartungsposition. Organisatorische und kaufmännische Kernobjekte sind Company Code, Plant, Purchasing Organization, Purchasing Group, Supplier beziehungsweise Business Partner, Cost Center, Internal Order, Material, Service Master und gegebenenfalls WBS-Elemente. Das CAFM liefert Flächen-, Gebäude-, Raum- und FM-spezifische Standortattribute; das Service-Desk-System liefert Ticket-ID, Ticketkategorie, Priorität, SLA-Zeitstempel und Kommunikationsstatus. SAP stellt für Functional Locations, Equipment, Cost Centers und Business Partners dokumentierte Stammdatenobjekte und OData-Services bereit.

Das Datenmodell muss pro Objekt eine eindeutige Quellsystemführerschaft, einen Primärschlüssel, technische und fachliche Pflichtattribute, Versionierungsregeln, Zeitstempel, Verantwortlichkeiten und Archivierungsregeln ausweisen. Für die Kopplung mit CAFM und Service Desk sind mindestens die Schlüsselpaare Objekt-ID ERP, Objekt-ID CAFM, Standort- oder Raum-ID, Ticket-ID, Order-ID und Kostenobjekt-ID vorzusehen. Bei GLT-Ereignissen ist ein normalisierter Event-Key zu übergeben; Rohzeitreihen verbleiben in GLT beziehungsweise Historian. Für das informationsbezogene Ordnungsmodell ist die Orientierung an DIN EN ISO 19650 sachgerecht, weil diese Normenreihe Informationsanforderungen, Austausch, Versionierung und Bereitstellungsprozesse für den Lebenszyklus von Bauwerken adressiert.

Die Zuordnung basiert auf den in SAP dokumentierten Funktionsbereichen für Beschaffung, Instandhaltung, Kostenrechnung, Business Partner und Workflows sowie auf den dokumentierten REST-Fähigkeiten von CAFM-Plattformen und den OPC-UA-Spezifikationen.

Das Rechte- und Rollenmodell ist rollenbasiert aufzubauen und fachlich nach Einkauf, TTS-Betriebsführung, Instandhaltung, Finance/Controlling, Service Desk, Stammdatenmanagement, Schnittstellenbetrieb und Revision zu trennen. SAP weist Business Roles als zentrales Strukturierungselement für Zugriffe aus; ausgelieferte Rollen sind lediglich als Templates zu verwenden und projektspezifisch zu härten. Für technische Benutzer, Integrationsbenutzer und Dialogbenutzer sind getrennte Rollen, eigene Kennungen und eigenständige Rezertifizierungszyklen festzulegen. Das BSI definiert Identitäts- und Berechtigungsmanagement als Prozess für Zuweisung, Entzug und Kontrolle von Rechten.

Sicherheitsseitig sind föderierte Identitäten und ein IAM-Ansatz mit rollenbasierter Zuweisung, technischen Service-Accounts, MFA für privilegierte Zugriffe, verschlüsselter Kommunikation, Audit-Logging und revisionssicherer Nachvollziehbarkeit vorzusehen. SAP Cloud Identity Services umfassen Identity Authentication, Identity Provisioning, Identity Directory und Authorization Management; Identity Provisioning unterstützt den Lebenszyklus von Identitäten und Berechtigungen zwischen Cloud- und On-Premise-Anwendungen. Für Kommunikationsarrangements werden in SAP TLS-gesicherte Verbindungen beschrieben; HANA unterstützt Daten-, Log- und Backup-Verschlüsselung. HANA-Auditing erlaubt die Konfiguration von Audit Policies und Audit Trails, während das BSI Protokollierung als eigenständigen Schutzbaustein behandelt.

Das Reporting ist zweistufig auszulegen: operatives Reporting im ERP für Aufträge, Meldungen, Bestellungen, Rechnungen und Kosten sowie konsolidiertes Reporting für TTS-Steuerung über ERP-, CAFM-, GLT- und Service-Desk-Daten. Für Maintenance Analysis stellt SAP standardisierte Analyseinhalte zu Meldungen und Aufträgen bereit. Zwingend vorzusehen sind Kennzahlen zu Auftragsdurchlaufzeit, offener Backlog, Materialverfügbarkeit, Kosten je Objekt, externe und interne Leistungsanteile, SLA-Erfüllung, Alarm-zu-Auftrag-Quote, First-Time-Fix, Rechnungslaufzeit und Bestandsqualität der Stammdaten. Die Reportingplattform kann im ERP eingebettet oder an ein externes BI-Werkzeug angebunden werden; die führenden Quellsysteme bleiben unverändert.

Die Migrationsstrategie ist phasenweise und objektbezogen aufzubauen. Vor dem ersten Ladungslauf sind Datenprofiling, Dublettenerkennung, Pflichtfeldprüfung, Schlüsselharmonisierung, Klassifikationsmapping und Führungsentscheidungen pro Stammdatenobjekt abzuschließen. Für Business Partner, Kostenstellen, Functional Locations, Equipment, Materialstämme, Service-Stämme und offene Bewegungsdaten sind getrennte Migrationsobjekte, Transformationsregeln und fachliche Abnahmeprotokolle zu führen. SAP dokumentiert Datenmigration und Business-Process-Testing als eigenständige Projektbausteine. Für Upgrade- und technische Umstellungsszenarien sind Maintenance Planner, stack.xml, Software Update Manager und Readiness Check als verbindliche Werkzeuge einzuplanen.

Test und Abnahme haben mindestens Stammdatentests, Schnittstellentests, Workflowtests, Rollen- und Berechtigungstests, Integrations- und Regressionstests, Lasttests für Massenschnittstellen, Fehlerfalltests, Backup/Restore-Tests sowie Cutover-Proben zu umfassen. Die fachliche Abnahme ist erst erreicht, wenn die Vollständigkeit der Stammdaten, die Belegkonsistenz über ERP, CAFM, GLT und Service Desk, die korrekte Kontierung, die Freigabeworkflows für Beschaffung und Maintenance Orders sowie die Fehler- und Retry-Behandlung der Schnittstellen nachgewiesen sind. Das BSI fordert für Datensicherungskonzepte die kurzfristige Wiederaufnahme des IT-Betriebs; HANA dokumentiert Backup-Katalog, Recovery und Auditing als eigenständige Betriebsfunktionen.

Die Phasenlogik folgt der in SAP dokumentierten Trennung von Datenmigration, Business-Process-Testing und Upgrade-/Wartungswerkzeugen sowie den BSI-Anforderungen an Datensicherung und Wiederanlauf.

Der Betrieb ist mit klaren Verantwortlichkeiten für Applikation, Schnittstellen, Stammdaten, Berechtigungen, Monitoring, Incident-, Problem- und Change-Bearbeitung zu organisieren. Mindestumfang des Supports sind 1st-Level-Annahme im Service Desk, 2nd-Level-Fachsupport für ERP und TTS-Prozesse sowie 3rd-Level-Support für Hersteller, Integrationsplattform und Datenbank. Für kritische Störungen der Auftragsanlage, Bestellabwicklung, Rechnungsschnittstellen, Rollenvergabe, Alarmübergabe und Backup-/Recovery-Funktionen sind Reaktions- und Wiederherstellungszeiten vertraglich festzulegen. Backup und Recovery sind auf Datenbank- und Applikationsebene nachweisbar zu testen; HANA führt hierfür Backup-Katalog, Recovery-Funktionen und Audit-Trails. Für das Release- und Patch-Management sind Regelzyklen, Wartungsfenster, Regressionstests, Transportkontrollen und dokumentierte Rollback-Szenarien festzuschreiben. SAP benennt Maintenance Planner und SUM als zentrale Werkzeuge der Softwarewartung.

• die endgültige SAP-Zielversion und das Betriebsmodell, einschließlich On-Premise, Private Cloud oder Public Cloud;

• der verbindliche Modulscope mit Entscheidung zu SD sowie zu optionalen Komponenten für Workforce- oder Vertragsmanagement;

• der Umfang vorhandener Lizenzen, Wartungsverträge und Subscriptions;

• die Entscheidung für eine Integrationsplattform und deren Monitoring- und Zertifikatskonzept;

• die tatsächliche Führungslogik je Stammdatenobjekt zwischen ERP, CAFM und GLT;

• die Qualität, Vollständigkeit und Herkunft der zu migrierenden Stammdaten;

• die endgültigen Schnittstellenendpunkte, Authentifizierungsverfahren, Zertifikate und Netzwerkzonen;

• die Zieldefinition für SLA-Werte, Supportzeiten und Eskalationsstufen;

• die gewünschte Reportingplattform einschließlich Embedded Analytics, Data Warehouse oder externem BI-Tool;

• die konkret erforderlichen Freigabeworkflows für Bestellungen, Rechnungen und Maintenance Orders;

• die Anforderungen an Archivierung, Aufbewahrungsfristen und Revisionsfähigkeit;

• die Rollensegmente für technische Benutzer, Dialogbenutzer und externe Dienstleister sowie die finalen RACI-Zuordnungen je Schnittstelle.