Moderne Angriffe folgen oft einem vorhersehbaren Muster, bei dem die Verschlüsselung meist den letzten Schritt darstellt. Angreifende dringen zunächst in Netzwerke ein, verschaffen sich höhere Rechte und stehlen sensible Daten. Erst danach verschlüsseln sie Systeme, um Lösegeldforderungen durchzusetzen. Selbst Unternehmen mit aktuellen Backups sind gefährdet, wenn vertrauliche Informationen entwendet und veröffentlicht werden.

Im Kern ist Ransomware keine rein technische, sondern eine operative und finanzielle Bedrohung. Ein Angriff kann die Produktion lahmlegen, ERP- und Finanzsysteme stören, Kundendaten offenlegen, DSGVO-Meldungen erzwingen, den Ruf schädigen und hohe juristische Folgekosten verursachen.

Wie hoch ist das Risiko eines Angriffs?

Viele Unternehmen glauben, sie seien zu klein, um Ziel eines Angriffes zu werden. Die Realität sieht jedoch anders aus: Laut dem Cybercrime-Report 2024 des Bundeskriminalamtes (BKA) wurden allein in Deutschland 950 Ransomware-Vorfälle gemeldet. Die entscheidende Frage lautet also nicht, ob Ihr Unternehmen angegriffen wird, sondern ob Ihre Sicherheitsmaßnahmen stark genug sind, einen Angriff abzuwehren.

Wie es Ransomware hinein schafft

Ransomware wirkt oft komplex, nutzt aber meist einfache Schwachstellen in Systemen oder Prozessen aus. Die größten Angriffsflächen bieten:

Phishing-E-Mails: Eine der häufigsten Methoden, mit denen Ransomware in ein Netzwerk gelangt, sind betrügerische E-Mails, die scheinbar von Kolleginnen, Kollegen oder Geschäftspartnern stammen und häufig schädliche Links oder Anhänge enthalten. Selbst geschulte Mitarbeitende können durch überzeugende E-Mails getäuscht werden.

Schwache Identitätssicherheit: Kompromittierte oder schwache Zugangsdaten eröffnen Angreifenden den Weg in Cloud-Systeme, VPNs oder interne Netzwerke. Ohne Multi-Faktor-Authentifizierung (MFA) kann ein einziges kompromittiertes Konto das gesamte Umfeld gefährden.

Ungepatchte Systeme: Software und Betriebssysteme weisen regelmäßig Sicherheitslücken auf. Werden Updates herausgezögert, nutzen Angreifende diese aus, um ohne aufwendige Hacking-Methoden ins Netzwerk einzudringen. Eine streng befolgte „Never touch a running system“-Politik kann hier zum echten Risiko werden.

Flache oder schlecht segmentierte Netzwerke: Ist ein System infiziert, breitet sich die Schadsoftware rasant aus. Ohne saubere Netzsegmentierung kann aus einem einzelnen Vorfall schnell eine unternehmensweite Krise entstehen.

Wer diese Schwachstellen kennt, kann gezielt Maßnahmen ergreifen, um die Ursachen zu beseitigen, statt nur auf Symptome zu reagieren.

Weg zu mehr Cyber-Resilienz: So stärken Sie Ihre Verteidigung

Der Schutz vor Ransomware erfordert einen mehrschichtigen Ansatz aus Technologie, Prozessen und Bewusstsein der Mitarbeitenden:

Identitätssicherheit stärken: Die meisten Ransomware-Angriffe beginnen mit gestohlenen Anmeldedaten. Die Durchsetzung von MFA für alle Konten, insbesondere für VPN-, RDP-, M365- und Administratorkonten, ist unerlässlich. Deaktivieren Sie veraltete Authentifizierungsmethoden, trennen Sie Administratorkonten von Benutzerkonten und ziehen Sie phishing-resistente MFA-Lösungen wie FIDO2 oder Smartcards in Betracht. Die Implementierung von Richtlinien für bedingten Zugriff kann das Risiko ebenfalls erheblich verringern.

E-Mail-Sicherheit und Awareness verbessern: Da Phishing das Haupteinfallstor bleibt, sollten Sie leistungsfähige Filterlösungen (z. B. ATP oder Defender for Office 365) einsetzen, DMARC, DKIM und SPF sauber konfigurieren und Makros aus externen Dokumenten blockieren. Regelmäßige Schulungen und Phishing-Simulationen sensibilisieren die Mitarbeitenden zusätzlich.

Systeme aktuell halten: Ungepatchte Systeme bieten einfache Angriffsflächen. Spielen Sie kritische Patches innerhalb weniger Tage und nicht erst nach Wochen ein. Führen Sie regelmäßige Schwachstellenscans durch, entfernen Sie nicht mehr unterstützte Systeme und härten Sie Domain-Controller.

Zuverlässige Backups pflegen: Backups sind die letzte Verteidigungslinie. Lagern Sie sie offline oder unveränderbar („immutable“), testen Sie Wiederherstellungen regelmäßig und verwenden Sie separate Zugangsdaten. Viele Ransomware-Gruppen greifen mittlerweile zuerst Backup-Systeme an, weshalb diese Vorsichtsmaßnahmen unerlässlich sind.

Netzwerk segmentieren: Verhindern Sie die schnelle Ausbreitung von Schadsoftware durch VLANs, Zero-Trust-Prinzipien und eingeschränkten lateralen Zugriff. Administratoren sollten nur von privilegierten Arbeitsstationen arbeiten. So gefährdet ein einzelner infizierter Rechner nicht das gesamte Netzwerk.

Incident-Response-Plan vorbereiten: Eine gute Vorbereitung minimiert Schäden. Dokumentieren Sie klare Abläufe, Kommunikationswege und Ansprechpartner (inklusive rechtlicher Beratung und Versicherung), testen Sie Wiederherstellungen und gewährleisten Sie eine manipulationssichere Protokollierung über ein SIEM-System.

Wichtige Maßnahmen für IT und Management

Auch wenn Sie nicht alle Kontrollmaßnahmen sofort umsetzen können, konzentrieren Sie sich auf diese wirkungsvollen Maßnahmen:

1. MFA überall konsequent durchsetzen.
2. Öffentlichen RDP-Zugriff deaktivieren.
3. Tägliche, getestete und unveränderbare Backups sicherstellen.
4. Endpoint-Detection-&-Response-(EDR)-Lösungen auf allen Geräten ausrollen.
5. Internetseitige Systeme zeitnah patchen.
6. Administrator- und Benutzerkonten strikt trennen.
7. E-Mail-Sicherheit erhöhen und Makros einschränken.

Allein diese Maßnahmen können das Risiko eines Ransomware-Vorfalls erheblich verringern.

Sicherheit als gemeinsame Aufgabe

Ransomware ist eine reale und wachsende Bedrohung. Die entscheidende Frage ist nicht, ob Ihr Unternehmen Ziel wird, sondern wie schnell Sie sich erholen und weiterarbeiten können, wenn Systeme morgen verschlüsselt wären. Diese Antwort zeigt Ihre tatsächliche Resilienz.

Wir unterstützen Sie gerne dabei, Ihre IT-Infrastruktur und Backup-Strategien auf Ransomware-Resistenz zu prüfen. Gemeinsam finden wir das richtige Gleichgewicht zwischen maximaler Sicherheit und effizientem Betrieb. Damit Sicherheit nicht bremst, sondern schützt.

Einfach schreiben an service@inwerken.de. Unser IT-Team meldet sich bei Ihnen! Leistungen darüber hinaus finden Sie in unserem Portfolio.

Was Subaccounts in SAP BTP leisten

SAP Business Technology Platform (SAP BTP) organisiert Cloud-Ressourcen in einer klaren Hierarchie. Das Global Account bildet den vertraglichen Rahmen für alle lizenzierten Services und Kontingente. Darunter befinden sich Subaccounts als logische Einheiten mit eigenen Berechtigungen, Service-Entitlements und Mitgliederzuweisungen. Zusätzlich bieten Directories eine optionale Zwischenebene, um Subaccounts thematisch oder organisatorisch zu gruppieren. Für Architekturverantwortliche ist dieses Hierarchiemodell der Ausgangspunkt jeder BTP-Landschaftsplanung.

Warum das klassische Dreistufenmodell in der Cloud scheitert

In der SAP-On-Premise-Welt hat sich die Aufteilung in Entwicklung, Qualitätssicherung und Produktion über Jahrzehnte bewährt. Die Versuchung liegt nahe, dieses Prinzip auf SAP BTP zu übertragen und drei Subaccounts anzulegen. In unserem Entwicklungsalltag sehen wir immer wieder, dass diese Übertragung zu Problemen führt.

Das zentrale Risiko liegt in der Entwicklungsebene. Ein einzelner DEV-Subaccount, den sich mehrere Projekte teilen, erzeugt ungewollte Abhängigkeiten bei gemeinsam genutzten Service-Instanzen. Ein konkretes Beispiel: Muss eine PostgreSQL-Instanz im Rahmen eines Projekts neu instanziiert werden, verlieren alle anderen Projekte im selben Subaccount ihre Daten. Solche Seiteneffekte sind in einer Multiprojektlandschaft unvermeidlich, wenn keine Isolation auf Subaccount-Ebene besteht.

Hinzu kommt, dass die Trennung zwischen Entwicklung und Modultest in der Cloud-Welt verschwimmt. Die eigentliche Entwicklung findet häufig lokal oder im SAP Business Application Studio (BAS) statt. Schon das Deployment aus dieser lokalen Umgebung heraus ist ein kontrollierter Transportschritt in eine Testlandschaft. Ein separater Modultest-Subaccount erzeugt in diesem Szenario keinen Mehrwert, sondern zusätzlichen Verwaltungsaufwand.

Projektisolation als Fundament: Ein Subaccount pro Entwicklungsprojekt

Ein tragfähiges Modell setzt nicht auf einen gemeinsamen Entwicklungs-Subaccount, sondern auf dedizierte Subaccounts pro Entwicklungsprojekt. Jedes Projekt erhält seinen eigenen Subaccount mit eigener PostgreSQL-Instanz, eigenen Destinations und eigenen Service-Bindings. So kann ein Team Services neu aufsetzen, Schemata ändern oder Konfigurationen anpassen, ohne andere Projekte zu beeinträchtigen.

In diesen projektspezifischen Subaccounts finden Entwicklung und Modultest als zusammenhängende Aktivität statt. Das Deployment aus BAS oder der lokalen Entwicklungsumgebung in den Projekt-Subaccount ist der erste kontrollierte Transportschritt. Erst wenn die Anwendung dort stabil läuft und die projektinternen Tests bestanden sind, erfolgt der nächste Schritt.

Über Directories lassen sich die Projekt-Subaccounts im Global Account übersichtlich gruppieren. Ein Directory pro Fachbereich oder Programmcluster verhindert, dass die Landschaft bei wachsender Projektanzahl unübersichtlich wird.

Die Konsolidierungsebene: Wo Projekte zusammenwachsen

Nach der projektinternen Stabilisierung folgt eine Ebene, die im klassischen Dreistufenmodell fehlt: die Konsolidierung. In einem eigenen Konsolidierungs-Subaccount werden die Ergebnisse verschiedener Projekte erstmals zusammengeführt.

Die Notwendigkeit dieser Ebene wird am Beispiel der Datenbank deutlich. In der Entwicklung betreibt jedes Projekt seine eigene PostgreSQL-Instanz. Im späteren Produktivbetrieb sollen die Anwendungen jedoch häufig auf einer gemeinsamen Datenbankinstanz laufen. Die Konsolidierungsebene bildet genau dieses Szenario ab. Hier werden Schemakompatibilität, Datenmigrationen und das Zusammenspiel der Services unter realistischen Bedingungen geprüft. Erst wenn das konsolidierte Gesamtsystem stabil funktioniert und alle Integrationstests bestanden sind, wird es in die Produktion überführt.

Hier stellen wir bei Inwerken oft fest, dass diese Konsolidierungsebene den entscheidenden Qualitätssprung bringt. Viele Fehler, die bei einem direkten Transport aus isolierten Entwicklungsumgebungen in die Produktion auftreten würden, werden hier frühzeitig erkannt und behoben. Gleichzeitig zeigt die Praxis, dass Konsolidierung und Produktion bei unterschiedlichen Nutzergruppen nicht immer jeweils nur einmal ausreichen. Wenn interne Mitarbeitende einerseits und externe Nutzerinnen und Nutzer wie Kundinnen und Kunden oder Lieferantinnen und Lieferanten andererseits auf Anwendungen zugreifen, sind oft getrennte Konsolidierungs- und Produktiv-Subaccounts sinnvoll. So lassen sich Sicherheitszonen, Identity and Access Management, Schnittstellenfreigaben und Betriebsprozesse sauber voneinander trennen.

Dedizierte Service-Subaccounts nicht vergessen

Neben den Subaccounts für den Entwicklungszyklus benötigt eine vollständige BTP-Landschaft weitere Subaccounts für zentrale Services, die quer zu den Projektebenen liegen. Ein CI/CD-Service, der Build- und Deployment-Pipelines orchestriert, benötigt einen eigenen Subaccount. Ebenso verhält es sich mit SAP Build Work Zone: Die Testumgebung und die Produktivumgebung des Portals erfordern getrennte Subaccounts, da Work Zone eigene Content-Konfigurationen, Rollenzuweisungen und Integrationen verwaltet, die sich nicht vermischen dürfen.

(Grafik 1)

Auch diese Service-Subaccounts lassen sich über Directories strukturieren. Ein Directory für übergreifende Services hält sie von den projektbezogenen Subaccounts getrennt und erleichtert die Governance.

Ordnung im BTP-System: Empfehlungen zu Rechten und Kontingenten

Mit der höheren Anzahl an Subaccounts steigt die Bedeutung eines strukturierten Entitlement-Managements. SAP BTP verteilt Service-Kontingente vom Global Account auf die einzelnen Subaccounts. Ohne klare Zuordnung besteht das Risiko, dass Entwicklungs-Subaccounts unbemerkt produktive Kontingente aufbrauchen.

Ebenso wichtig ist ein durchdachtes Identity and Access Management (IAM). Idealerweise wird ein einheitlicher Identity Provider für alle Subaccounts konfiguriert, während die Rollenzuweisungen subaccount-spezifisch gesteuert werden. So ist sichergestellt, dass Projektteams nur auf ihren eigenen DEV-Subaccount zugreifen und kein unkontrollierter Zugang zur Konsolidierungs- oder Produktivebene besteht. Regelmäßige Reviews der Entitlements und Berechtigungen gehören dabei zur Governance-Routine, idealerweise synchronisiert mit bestehenden Audit-Zyklen.

Sub-Accounts auf SAP BTP: Von der Architekturentscheidung zur stabilen Landschaft

Eine praxistaugliche Subaccount-Struktur auf SAP BTP geht über das bekannte Dreistufenmodell hinaus. Projektisolation in der Entwicklung, eine dedizierte Konsolidierungsebene und separate Service-Subaccounts bilden zusammen ein Modell, das den realen Anforderungen paralleler Cloud-Entwicklung gerecht wird. Je nach Zugriffsmodell kann dieses Zielbild um eine getrennte Konsolidierungs- und Produktivspur für interne und externe Nutzergruppen erweitert werden.

Inwerken unterstützt beim Ordnung schaffen und Strukturaufbau in der BTP

Wer die eigene BTP-Landschaft von Anfang an strukturiert aufsetzen oder ein bestehendes Modell konsolidieren möchte, findet bei der Inwerken AG erfahrene Ansprechpersonen. Von der initialen Landschaftsarchitektur über die Einrichtung projektspezifischer Subaccounts bis zur Governance laufender Multiprojektlandschaften begleitet Sie das Inwerken-Team den gesamten Prozess.

Sie haben Fragen? Melden Sie sich gern an sapentwicklung@inwerken.de oder vereinbaren Sie einen Termin. Wir freuen uns auf Ihre Kontaktaufnahme!

Was SAP BTP ist und warum die Plattform an Bedeutung gewinnt

SAP Business Technology Platform ist die zentrale Cloud-Plattform von SAP für Erweiterungen, Integrationen, Datenanalysen und Anwendungsentwicklung. Sie ergänzt die bestehenden SAP-Kernsysteme um eine Schicht, auf der individuelle Lösungen entstehen können, ohne das Kernsystem selbst zu verändern. In einer Zeit, in der SAP den Clean-Core-Ansatz für S/4HANA konsequent verfolgt, ist SAP BTP der vorgesehene Ort für kundenspezifische Logik und Prozesserweiterungen. Für Unternehmen, die vor der Einführung von Services der BTP stehen, ist ein klares Verständnis der Plattform deshalb die Voraussetzung für fundierte Investitionsentscheidungen.

(Grafik 1)

Die Architektur im Überblick: Global Account, Subaccounts und Runtimes

SAP BTP ist in einer mehrstufigen Hierarchie organisiert. Am Anfang steht das Global Account. Es bildet den vertraglichen Rahmen und enthält alle lizenzierten Services und Kontingente. Innerhalb des Global Accounts lassen sich Subaccounts anlegen. Jeder Subaccount ist einer Cloud-Region zugeordnet und verfügt über eigene Berechtigungen, Service-Instanzen und Konfigurationen. Optional bieten sogenannte Directories eine Zwischenebene, um Subaccounts thematisch oder organisatorisch zu gruppieren.

Auf technischer Ebene stellt SAP BTP zwei zentrale Laufzeitumgebungen bereit:

1. Die Cloud Foundry Runtime eignet sich für die Entwicklung mit dem Cloud Application Programming Model (CAP), Node.js oder Java.
2. Die Kyma Runtime basiert auf Kubernetes und ist die Wahl für containerbasierte Workloads und Microservice-Architekturen.

Zusätzlich existiert mit dem ABAP Environment eine Laufzeitumgebung für ABAP-basierte Cloud-Entwicklung. Welche Runtime zum Einsatz kommt, hängt vom konkreten Anwendungsfall und den vorhandenen Kompetenzen ab.

Vier Säulen in einem Plattformgedanken

SAP strukturiert die Funktionen von BTP in vier Bereiche, die sich in der Praxis ergänzen:

1. Application Development and Automation:

Werkzeuge für die Erstellung eigener Anwendungen, von Low-Code-Lösungen mit SAP Build Apps bis hin zu professioneller Entwicklung mit dem SAP Business Application Studio (BAS) und CAP. Auch Prozessautomatisierung mit SAP Build Process Automation gehört in diesen Bereich.

• Data and Analytics:

Services für Datenmodellierung, Data Warehousing mit SAP Datasphere und analytische Dashboards mit SAP Analytics Cloud (SAC). Hier werden Daten aus verschiedenen Quellen zusammengeführt und auswertbar gemacht.

• Integration:

SAP Integration Suite verbindet SAP-Systeme untereinander sowie mit Drittsystemen. Cloud- Integration, API-Management und Event Mesh (eine technologische Infrastruktur, die Ereignisse in Echtzeit zwischen Apps, Cloud-Diensten und IoT-Geräten vermittelt) ermöglichen den Datenaustausch in Echtzeit.

• Künstliche Intelligenz:

Mit SAP AI Core und SAP AI Launchpad stellt die Plattform Infrastruktur für Machine-Learning-Szenarien bereit. Vortrainierte Modelle und eigene Trainingsumgebungen sind gleichermaßen nutzbar.

Diese vier Säulen bilden kein starres Produktpaket. Unternehmen lizenzieren und aktivieren gezielt die Services, die zum jeweiligen Bedarf passen. Unser Beratungsalltag zeigt, dass eine schrittweise Aktivierung sinnvoller ist als der Versuch, alle Bereiche gleichzeitig einzuführen.

Welchen konkreten Nutzen SAP BTP in der Praxis stiftet

Der zentrale Mehrwert von SAP BTP liegt in der Entkopplung kundenspezifischer Entwicklungen vom SAP-Kernsystem. Im Clean-Core-Konzept bleiben S/4HANA-Systeme upgradefähig, weil individuelle Logik auf BTP ausgelagert wird. Gleichzeitig bietet die Plattform eine einheitliche Umgebung für Integrationsszenarien, die in gewachsenen Landschaften sonst über verschiedenste Middleware-Produkte verteilt wären.

Für IT-Verantwortliche ergibt sich daraus ein klarer Governance-Vorteil. Erweiterungen, Integrationen und Analyseanwendungen laufen in einer verwalteten Plattform mit einheitlichem Identity Management, zentralem Monitoring und transparenter Kostenzuordnung. Die Alternative, nämlich ein Nebeneinander aus verschiedenen Cloud-Diensten und selbst betriebenen Integrationsschichten, ist langfristig aufwändiger zu betreiben und schwerer abzusichern.

Drei typische Einsatzszenarien für den Einstieg

SAP BTP entfaltet seinen Nutzen am schnellsten dort, wo bestehende Prozesse gezielt erweitert werden. Drei Szenarien empfehlen wir aus unserer täglichen Beratungs- und Entwicklungspraxis heraus:

Szenario 1: Side-by-Side-Erweiterung für S/4HANA.

Ein Unternehmen benötigt eine Genehmigungslogik, die über die Standardfunktionen von S/4HANA hinausgeht. Oder häufige Alternative: Eine Möglichkeit Informationen von Kunden oder Lieferanten zu erfragen, mit Anwendern, die nicht zum Unternehmen gehören, aber dennoch authentifiziert arbeiten können.
Statt das Kernsystem zu modifizieren, entwickelt man in der BTP eine CAP-Anwendung, die per API auf S/4HANA-Daten zugreift und die erweiterte Logik abbildet. Das Kernsystem bleibt dadurch clean und die Erweiterung ist unabhängig einsetzbar sowie testbar.

Szenario 2: Integration heterogener Systemlandschaften.

In vielen Unternehmen existieren neben SAP auch Salesforce, ServiceNow oder branchenspezifische Fachsysteme. Mit der SAP Integration Suite lassen sich diese Systeme über vordefinierte Integrationsflows verbinden. Event Mesh ermöglicht dabei eine ereignisgesteuerte Kommunikation, bei der Systeme nicht mehr zyklisch abgefragt werden, sondern in Echtzeit auf Änderungen reagieren. Über CAP basierte Services können Informationen über eine gesicherte und definierte API an Dritte gegeben werden, ohne dass fremde Organisationen Zugriff auf interne Systeme oder Daten erlangen können.

Szenario 3: Self-Service-Reporting jenseits des SAP-Standards.

Fachbereiche benötigen oft Auswertungen, die im SAP-Standard nicht vorgesehen sind oder Daten aus mehreren Quellen kombinieren. Über SAP Datasphere werden die relevanten Datenquellen angebunden. In SAP Analytics Cloud entstehen interaktive Dashboards, die Fachanwenderinnen und Fachanwender eigenständig nutzen und anpassen können.

Typische Beispiele sind ein Vertriebsdashboard, das Auftragsbestand aus SAP S/4HANA mit CRM-Pipeline-Daten zusammenführt, ein Einkaufsreport zur Liefertermintreue je Lieferant auf Basis von MM-Daten und externen Qualitätskennzahlen sowie ein Service-Cockpit, das Ticketvolumen, Reaktionszeiten und Ersatzteilverfügbarkeit in einer Sicht bündelt. Auch bereichsübergreifende Auswertungen zu Deckungsbeiträgen, Lagerreichweiten oder Forecast-Abweichungen lassen sich auf dieser Basis deutlich schneller bereitstellen.

Von der Orientierung zur strukturierten Einführung

SAP BTP ist keine einzelne Anwendung, sondern ein Plattformökosystem!

Die Architektur mit Global Account, Subaccounts und verschiedenen Laufzeitumgebungen bietet viel Gestaltungsspielraum. Gleichzeitig erfordert genau dieser Spielraum eine klare Strategie, damit die Einführung nicht in einer fragmentierten Landschaft oder chaotischen Service-Bindings mündet. Ein typisches Beispiel ist der parallele Aufbau mehrerer Subaccounts ohne einheitliches Berechtigungsmodell, wodurch Integrationen später doppelt aufgebaut und Governance-Prozesse unnötig komplex werden.

Inwerken unterstützt beim strukturierten BTP-Aufbau

Wer die ersten Schritte auf SAP BTP strukturiert angehen möchte, findet bei der Inwerken AG erfahrene Ansprechpersonen. Von der Architekturberatung über die Auswahl passender Services bis zur Umsetzung erster Pilotszenarien begleitet Sie das Team über den gesamten Einführungsprozess. Das Ziel ist dabei stets, den Arbeitsalltag der beteiligten Fachbereiche und IT-Teams durch passende Lösungen zu vereinfachen.

Sie haben Fragen? Melden Sie sich gern an sapentwicklung@inwerken.de oder vereinbaren Sie einen Termin. Wir freuen uns auf Ihre Kontaktaufnahme!

Warum Alt-Datenbereinigung vor der S/4HANA-Migration strategisch relevant ist

In vielen Transformationsprojekten liegt der Fokus zunächst auf Architekturentscheidungen, Systemlandschaften und der Auswahl des Migrationsansatzes. Datenqualität wird dagegen häufig erst dann sichtbar, wenn Migrationstools Fehlermeldungen produzieren oder Tests unerwartete Inkonsistenzen zeigen.

Dabei ist die Datenbasis ein zentraler Erfolgsfaktor jeder SAP-Transformation. Historisch gewachsene ERP-Systeme enthalten oftmals Datenstrukturen, die über Jahre hinweg erweitert wurden. Stammdaten wurden mehrfach angelegt, Geschäftspartnerstrukturen sind nicht harmonisiert und alte Customizing-Logiken wirken noch in Transaktionen nach.

Eine S/4HANA-Migration überführt nicht nur Programme und Tabellenstrukturen in eine neue Systemgeneration. Sie überträgt auch sämtliche strukturellen Altlasten, sofern diese nicht vorher gezielt bereinigt werden. In der Praxis entstehen daraus mehrere Herausforderungen:

• verlängerte Laufzeiten bei Datenmigrationen
• unnötige Datenvolumen im Zielsystem
• komplexere Testphasen
• höhere Fehleranfälligkeit in Geschäftsprozessen

In unserer täglichen Beratungspraxis zeigt sich immer wieder, dass Projekte mit frühzeitiger Datenbereinigung deutlich stabiler verlaufen. Migrationstools wie der SAP Readiness Check oder das Migration Object Modeler Framework identifizieren zwar technische Probleme. Die fachliche Qualität der Daten kann jedoch nur durch gezielte Vorbereitung verbessert werden.

Vor diesem Hintergrund lohnt sich ein strukturierter Blick auf die wichtigsten Bereinigungsschritte vor der technischen Migration.

Die 7 wichtigsten Alt-Datenprobleme vor der technischen S/4HANA-Migration

Ein systematischer Bereinigungsansatz beginnt nicht mit Tabellen, sondern mit klar definierten Datenkategorien. Die folgenden sieben Themenfelder gehören in nahezu jedem Transformationsprojekt zu den zentralen Aufgaben.

1. Dateninventur durchführen

Ein erfolgreicher Übergang zu SAP S/4HANA beginnt mit einer Bestandsaufnahme der bestehenden Datenlandschaft. Eine strukturierte Inventur beantwortet dabei zentrale Fragen, wie: Welche Daten werden tatsächlich noch genutzt? Welche Tabellen enthalten historisch gewachsene Altlasten?

Aus Basis-Sicht kann hierbei eine schematische Annäherung über eine technische Volumenanalyse (etwa über die Transaktionen DB02 oder HANA-Estimation-Reports) der erste sinnvolle Schritt sein. Ziel ist hierbei die Identifikation von Wachstumstreibern, um herauszufinden wo sich Datenmengen akkumulieren und welche Business-Logik diesen zu Grunde liegt.

Entsprechende Datenfunde lassen sich kategorisieren, bspw. mit den nachfolgenden Fragestellungen:   Sind es prozessrelevante Stamm- und Bewegungsdaten, technisch bedingte Protokolle (IDocs, Workflows) oder reine Archiv-Indizes?

Diese Transparenz ermöglicht dann eine fundierte Entscheidung darüber, was migriert, was archiviert und was schlicht gelöscht werden kann, um die Zieldatenbank schlank zu halten.

2. Businesspartnerumstellung: Dubletten in Geschäfts- und Stammdaten identifizieren

Mehrfach angelegte Debitorinnen und Debitoren, Kreditorinnen und Kreditoren oder Materialstammsätze gehören zu den häufigsten Datenproblemen historischer ERP-Systeme. Dubletten entstehen meist durch unterschiedliche Organisationseinheiten oder fehlende Stammdatenrichtlinien.

Gerade mit der Einführung des Business Partner Konzepts in S/4HANA gewinnt diese Bereinigung an Bedeutung, da Debitoren und Kreditoren in einer zentralen Struktur zusammengeführt werden.

Eine systematische Dubletten-Analyse reduziert nicht nur Datenvolumen, sondern verbessert auch Prozessstabilität in Vertrieb, Einkauf und Finance.

3. Veraltete und nicht mehr benötigte Stammdaten archivieren

Viele ERP-Systeme enthalten Materialien, Kunden oder Lieferanten, die seit Jahren nicht mehr aktiv genutzt werden. Dennoch werden diese Datensätze häufig in Migrationen übernommen. Das erhöht unnötig Datenvolumen.

Eine klare Archivierungsstrategie sorgt dafür, dass nur tatsächlich relevante Stammdaten in das neue System übertragen werden. Das reduziert Datenmengen und beschleunigt Migrationsläufe.

• Welche Daten werden operativ noch benötigt?
• Welche gesetzlichen Aufbewahrungsfristen gelten?
• Wie groß ist das aktuelle Datenvolumen und wo entsteht es?
• Welche Daten müssen wie zugänglich bleiben?
• Welche Auswirkungen hat die Archivierung auf Geschäftsprozesse? (Greifen bspw. Reports darauf zu?)
• Welche Archivierungsobjekte sind relevant?

Die Fragen zeigen: Eine Archivierungsstrategie ist weniger ein technisches Projekt als eine Kombination aus Fachbereichsentscheidung, Datenstrategie und Systemarchitektur.

4. Inkonsistente Organisationsstrukturen bereinigen

Unternehmensstrukturen verändern sich über Jahre hinweg. Werke werden zusammengelegt, Verkaufsorganisationen neu definiert oder Buchungskreise umstrukturiert.

Solche Änderungen hinterlassen häufig widersprüchliche Zuordnungen in Stammdaten. Vor der Migration sollten Organisationsstrukturen daher systematisch geprüft werden, um spätere Fehler in Prozessen oder Auswertungen zu vermeiden.

5. Ungültige oder obsolete Customizing-Abhängigkeiten entfernen

Historische Systemanpassungen wirken oft noch in Tabellen und Bewegungsdaten nach. Nicht mehr genutzte Kontenfindungen, alte Bewegungsarten oder obsolete Steuerlogiken führen bei Migrationstools häufig zu Fehlermeldungen.

Eine gezielte Analyse der Customizing-Abhängigkeiten stellt sicher, dass nur relevante Konfigurationen in das Zielsystem übernommen werden.

6. Bewegungsdaten mit geringer Relevanz reduzieren

ERP-Systeme speichern oft Bewegungsdaten über viele Jahre hinweg. Für operative Prozesse sind jedoch meist nur die letzten Jahre relevant.

Eine gezielte Reduktion historischer Bewegungsdaten reduziert Datenvolumen erheblich und beschleunigt Migrationsläufe.

7. Inkonsistente Finanzdaten korrigieren

Gerade im Finanzbereich können sich über lange Systemlaufzeiten kleinere Inkonsistenzen ansammeln. Beispiele sind:

• Differenzen zwischen Nebenbüchern und Hauptbuch
• unvollständig ausgeglichene Belege
• Inkonsistenzen in Kontenzuordnungen

Solche Probleme sollten vor der Migration vom Fachbereich bereinigt werden, da sie sich im S/4HANA-Datenmodell häufig stärker auswirken. Für detailliertere Prüfungen stellt SAP auch spezielle Finanzdaten Konsistenzchecks bereit. Diese Programme überprüfen systematisch, ob die Daten in verschiedenen Finanzmodulen miteinander übereinstimmen. Dies entbehrt aber der Business-Kontrolle nicht!

Unser Bonustipp: Gelegenheit nutzen – Datenverantwortlichkeiten und Governance nachhaltig definieren

Technische Bereinigung allein reicht nicht aus. Nachhaltige Datenqualität entsteht nur durch klare Verantwortlichkeiten für Stammdatenpflege und Datenrichtlinien.

Nutzen Sie die Gelegenheit und etablieren Sie im Zuge der Transformation erstmals ein strukturiertes Data Governance Modell. Dieses verhindert, dass sich Datenprobleme nach der Migration erneut aufbauen.

(Grafik 1)

Fazit: Datenqualität ist ein zentraler Erfolgsfaktor der S/4HANA-Transformation

Die technische Migration nach S/4HANA wird häufig als Infrastrukturprojekt betrachtet. Tatsächlich entscheidet jedoch die Qualität der vorhandenen Daten darüber, wie stabil und effizient das zukünftige System arbeitet.

Eine strukturierte Alt-Datenbereinigung reduziert nicht nur technische Risiken. Sie schafft auch die Grundlage für konsistente Geschäftsprozesse, bessere Auswertungen und langfristig stabilere Systemlandschaften.

Weitere Informationen zu Transformationsstrategien und Beratungsansätzen rund um SAP S/4HANA finden sich im Leistungsportfolio der Inwerken AG.

Der Beratungsalltag zeigt, dass eine frühzeitige Auseinandersetzung mit Datenqualität Projekte deutlich planbarer macht. Ein fachlicher Austausch zu konkreten Herausforderungen kann helfen, Risiken frühzeitig sichtbar zu machen und geeignete Lösungswege zu entwickeln. Fragen? … einfach melden.

Was SAP S/4HANA im Service leistet und was nicht

SAP S/4HANA stellt in vielen Unternehmen das führende System für Serviceprozesse dar. Lösungen wie Servicemanagement oder Enterprise Asset Management ermöglichen die Anlage von Serviceaufträgen, die Verwaltung technischer Objekte sowie die Abrechnung von Leistungen. Stammdaten, Konditionen und kaufmännische Belege sind hier konsistent integriert.

Im Kern ist SAP S/4HANA darauf ausgelegt, Geschäftsprozesse zentral zu steuern und abzurechnen. Die operative Arbeit im Außendienst, insbesondere unter mobilen Bedingungen, ist nicht primär der Fokus dieser Architektur.

Servicetechnikerinnen und Servicetechniker arbeiten vor Ort beim Kunden. Sie benötigen schnellen Zugriff auf Auftragsinformationen, eine einfache Erfassung von Zeiten, Material und Fotos sowie die Möglichkeit zur digitalen Unterschrift. Wird dies nicht direkt im System unterstützt, entstehen zwangsläufig Medienbrüche.

Wo klassische ERP-Serviceabwicklung an mobile Grenzen stößt

Die Herausforderungen beginnen bereits bei der Informationsbereitstellung. Serviceaufträge werden in SAP S/4HANA erfasst und disponiert. Außendienstmitarbeiterinnen und Außendienstmitarbeiter erhalten die Informationen jedoch als Papierausdruck, E-Mail oder über indirekte Zugänge.

Vor Ort beim Kunden passiert dann Folgendes:

• Arbeitszeiten werden auf manuellem Zettel notiert
• Materialverbräuche auf Papier festgehalten
• Fotos separat auf einem nicht ans System angebundenen Endgerät gespeichert
• Kundensignaturen erfolgen auf Papier

Die strukturierte Rückmeldung im ERP-System erfolgt später im Büro. Zwischen tatsächlicher Leistungserbringung und systemischer Verbuchung liegt eine zeitliche Lücke und weitere manuelle Schritte wie bspw. abtippen oder scannen. Das birgt viel Fehlerpotenzial.

Besonders kritisch ist dies in folgenden Bereichen:

1. Fakturierung
   Ohne zeitnahe Rückmeldung kann keine vollständige Abrechnung erfolgen. Rechnungen verzögern sich, Liquiditätspotenziale bleiben ungenutzt.
2. Controlling
   Aufwände und Materialverbräuche sind erst verspätet im System sichtbar. Kennzahlen zur Auslastung oder First Time Fix Rate verlieren an Aussagekraft.
3. Disposition
   Statusänderungen werden nicht in Echtzeit zurückgemeldet. Disponentinnen und Disponenten arbeiten mit unvollständigen Informationen.

Kurz zusammengefasst: Das ERP-System erfüllt seine Rolle als führendes System. Es ist jedoch nicht für eine mobile, appbasierte Echtzeiterfassung konzipiert und wird entsprechend dafür auch nicht genutzt.

Informationsverluste zwischen Innendienst und Außendienst durch Medienbrüche

Medienbrüche passieren, wenn Informationen während eines Ablaufs das Format oder Medium wechseln (z. Bsp. von digital zu Papier), damit eine Weiterverarbeitung stattfinden kann. Sie sind nicht nur technisch, sondern auch prozessual. Zwischen Innendienst und Außendienst existieren häufig mehrere Übergabepunkte. Jeder dieser Punkte birgt ein Risiko von Informationsverlusten.

(Grafik 1)

Abbildung: Typischer Medienbruch zwischen ERP und Außendienst

Typische Schwachstellen sind:

• Unklare oder unvollständige Arbeitsanweisungen
• Fehlende Rückmeldung zu Zusatzleistungen
• Nicht dokumentierte Materialverbräuche
• Verlust von Bilddokumentationen

Gerade bei komplexeren Serviceeinsätzen entsteht eine Differenz zwischen dem, was vor Ort tatsächlich geleistet wurde und dem, was im System dokumentiert ist. Diese Differenz wirkt sich unmittelbar auf Transparenz und Wirtschaftlichkeit aus.

In unserer täglichen Beratungs- und Entwicklungspraxis sehen wir, dass viele Organisationen mit funktionierenden ERP-Prozessen arbeiten, jedoch keinen durchgängigen digitalen Serviceprozess etabliert haben. Die Folge ist eine Mischlandschaft aus System und Papier, die zusätzliche manuelle Schritte erfordert und sowohl Fehleranfälligkeit als auch Abstimmungsaufwand erhöht.

(Grafik 2)

SAP FSM als mobile Erweiterung von SAP S/4HANA

SAP Field Service Management, kurz SAP FSM, ist eine cloudbasierte Lösung, die speziell für operative Serviceprozesse entwickelt wurde. Sie ergänzt das ERP-System um mobile Funktionen für Planung und Rückmeldung.

Zentrale Merkmale sind:

• Mobile App für Servicetechnikerinnen und Servicetechniker
• Digitale Erfassung von Zeiten, Material und Fotos
• Direkte Dokumentation im Servicekontext
• Möglichkeit zur digitalen Kundensignatur

Der wesentliche Vorteil liegt in der unmittelbaren Systemanbindung. Rückmeldungen aus dem Außendienst (z. Bsp. Fotos zur Dokumentation, Messwerte, Arbeitszeiten oder verbrauchtes Material, die mit einem mobilen Endgerät wie Tablet oder Smartphone erfasst werden) werden über eine technische Integration direkt in das S/4HANA-System übertragen. Somit entfallen manuelle Nacherfassungen.

(Grafik 3)

Abbildung: Durchgängiger Prozess zwischen ERP und Außendienst

Auch Materialverbräuche, Bilddokumentationen oder ergänzende Leistungen werden strukturiert erfasst. Damit entsteht eine konsistente Datenbasis ohne Medienbrüche. Voraussetzung ist eine saubere End-to-End-Integration über die SAP Business Technology Platform. Die Plattform ermöglicht es, Anwendungen, Daten und Prozesse aus verschiedenen Systemen zu integrieren und zu erweitern. Auf dieser Basis können mobile Service-Apps, Middleware und das SAP-Kernsystem zuverlässig miteinander kommunizieren.

Herausforderungen bei der FSM-Implementierung und wie man sie löst

In unserer Beratungspraxis steht immer der gesamte Prozess im Mittelpunkt. Unser Ziel ist Serviceprozesse so zu gestalten, dass Informationen ohne Medienbruch vom Auftragseingang bis zur Rückmeldung im System verfügbar sind. Technisch lässt sich eine stabile Anbindung zwischen SAP S/4HANA On-Premise und SAP FSM über die SAP Business Technology Platform und die SAP Integration Suite einfach realisieren.

Aus architektonischer Sicht bedeutet dies, dass Serviceaufträge aus SAP S/4HANA an SAP FSM übertragen werden. Rückmeldungen aus der mobilen App fließen automatisiert zurück. Die Integrationsschicht, beispielsweise realisiert über die Services der SAP BTP, übernimmt dabei Datenmapping, Routing und Sicherheitsmechanismen.

Inwerken unterstützt bei der eigentlichen Herausforderung in der Umsetzung: Dem sauberen Zusammenspiel der Datenmodelle. Obwohl beide Lösungen (SAP S/4HANA und SAP FSM) aus dem SAP-Portfolio stammen, unterscheiden sich Objektstrukturen und Felddefinitionen. Für einen konsistenten End-to-End-Serviceprozess ist daher ein präzises Mapping der relevanten Datenobjekte entscheidend.

Fazit: Durchgängige Serviceprozesse als strategischer Erfolgsfaktor

SAP S/4HANA bildet eine stabile Basis für Serviceprozesse. Für mobile Außendiensteinsätze reicht das ERP-System allein jedoch häufig nicht aus. Medienbrüche zwischen System und operativer Durchführung führen zu Informationsverlusten, Verzögerungen und administrativem Mehraufwand.

Eine Erweiterung durch SAP FSM in Verbindung mit einer technischen End-to-End-Integration über die SAP Business Technology Platform ermöglicht eine durchgängige Prozesskette. Serviceaufträge, Materialverbräuche, Fotos und Rechnungsinformationen werden ohne manuelle Zwischenschritte verarbeitet.

Durch eine einmalig umgesetzte Integration entfallen manuelle Nacherfassungen. Rückmeldungen aus der App fließen direkt ins SAP S/4HANA-System, wodurch Serviceaufträge schneller abgeschlossen und Servicefachkräfte im Außendienst entlastet werden.

Sie haben Fragen zum Thema „SAP FSM“? Einfach schreiben an sapberatung@inwerken.de. Unser SAP-Beratungs-Team meldet sich bei Ihnen! Weitere Informationen zu Integrationsszenarien im technischen Service finden Sie in unserem Portfolio.

Was digitale Prozessoptimierung im Außendienst bedeutet

Digitale Prozessoptimierung bedeutet für den technischen Außendienst, dass eine durchgängige Unterstützung aller servicebezogenen Abläufe mithilfe von IT angestrebt wird. Dazu zählen unter anderem die Einsatzplanung, eine mobile Unterstützung der Servicetechnikerinnen und Servicetechniker, die strukturierte Rückmeldung von Leistungen sowie die Auswertung von Kennzahlen. Ziel ist es Informationen dort verfügbar zu machen, wo sie benötigt werden und manuelle Zwischenschritte zu reduzieren.

In unserer täglichen Beratungs- und Entwicklungspraxis bei Inwerken zeigt sich, dass die Integration in bestehende SAP-Landschaften eine zentrale Rolle spielt. Die KI-gestützte Cloud Software SAP Field Service Management fungiert als Bindeglied zwischen operativem Service und kaufmännischen Prozessen und schafft die Grundlage für durchgängige Serviceprozesse.

Erkenntnisse aus dem Servicealltag und ihre Einordnung mit SAP Field Service Management

Inwerken führte 2026 eine anonyme Befragung unter Servicetechnikerinnen und Servicetechnikern durch. Ziel war es, die aktuellen Herausforderungen bei den Außendiensteinsätzen noch besser zu verstehen. Folgende wiederkehrende Problematiken stellten sich heraus, die den Arbeitsalltag spürbar erschweren:

• mangelnde Vorabinformationen zu Einsätzen
• unübersichtliche oder umständliche App-Gestaltung und Dokumentationsprozesse
• Defizite in Planung & Kommunikation
• hohe bürokratische Lasten
• unvollständige Verlaufshistorien
• technische Hindernisse bei Endgeräten

Diese Punkte wirken sich unmittelbar auf die Effizienz der Serviceprozesse aus und prägen zugleich die Erwartungen an zeitgemäße Field-Service-Lösungen.

Ein Abgleich mit den Standardfunktionen von SAP FSM zeigt: Viele dieser Schmerzpunkte werden durch vordefinierte Features adressiert, ohne dass umfangreiche kundenspezifische Entwicklungen nötig wären.

SAP FSM: Vorabinformation und mobile Einsatzdaten

SAP FSM stellt eine digitale Plattform zur Außendienststeuerung bereit, über die Servicetechnikerinnen und Servicetechniker bereits vor Fahrtbeginn alle relevanten Auftragsinformationen erhalten. Dazu gehören relevante Einsatzdetails, Kundendaten, Anlageninformationen und Servicehistorien, die in der mobilen App dargestellt werden. Dies reduziert Unsicherheiten vor Ort und ermöglicht eine gezielte Vorbereitung.

SAP FSM: App & Dokumentation

Die Standard-Mobile-App von SAP FSM unterstützt Servicetechnikerinnen und Servicetechniker auf iOS-, Microsoft- und Android-Geräten (offline-fähig) beim strukturierten Erfassen ihrer Tätigkeiten, Arbeitszeiten, Materialentnahmen und Serviceberichten. Funktionen wie das Aufnehmen von Fotos, Scannen von Barcodes/QR-Codes und digitale Unterschriften vereinfachen die Dokumentation erheblich. Es wird kein Papier mehr benötigt. Eine nachträgliche Eingabe und Erfassung im Büro entfällt entsprechend auch.

Planung & Kommunikation mit SAP FSM

In SAP FSM ist eine Echtzeit-Einsatzplanung enthalten, die Disponentinnen und Disponenten eine grafische Plantafel (Dispatcher Board) zur Verfügung stellt, um Aufträge nach Verfügbarkeit, Qualifikation und geografischen Kriterien zuzuweisen. Zusätzlich ermöglichen automatisierte Kundenbenachrichtigungen den Kundinnen und Kunden Status-Updates zu Terminen und Ankunftszeiten. Diese Funktionen verbessern die Abstimmung zwischen Back-Office, Disposition und Außendienst sowie die Kommunikation entlang des Einsatzprozesses. Für den Außendienst bedeutet das konkret:

• weniger unnötige Fahrten
• kürzere Wegezeiten
• realistisch geplante Arbeitstage

Prozess & Bürokratieabbau mit SAP FSM

Standardisierte Workflows und geführte Smart Forms (Formulare) in der mobilen App helfen dabei, Prozesse zu vereinheitlichen und unnötige administrative Tätigkeiten zu reduzieren. Durch strukturierte Eingabemasken und obligatorische Felder wird sichergestellt, dass notwendige Daten schon vor Ort konsistent erhoben werden. Dies reduziert Doppelarbeit und erleichtert die nachgelagerte Verarbeitung im Back-Office.

Service-Historie und Datenverfügbarkeit in SAP FSM

SAP FSM zentralisiert servicebezogene Daten und verknüpft diese mit Stammdaten aus dem Backend-System (z. B. SAP S/4HANA). Dadurch sind Verlaufshistorien zu Kunden, Anlagen und erledigten Servicefällen für alle berechtigten Nutzerinnen und Nutzer jederzeit einsehbar. Das schafft Transparenz über vergangene Einsätze und ermöglicht datenbasierte Entscheidungen im operativen Geschäft.

Endgeräte und technische Unterstützung:

Die mobile App von SAP FSM ist als „offline-first“-Lösung ausgelegt, die auch bei schwacher oder fehlender Netzabdeckung funktioniert. Synchronisationen erfolgen automatisch, sobald eine Verbindung wieder verfügbar ist. Dies stellt sicher, dass Servicetechnikerinnen und Servicetechniker unabhängig vom Netzempfang arbeiten können und unterstützt den Einsatz in unterschiedlichen Umgebungen.

Durch diese standardisierten Funktionsbausteine adressiert SAP FSM viele der von Serviceteams identifizierten Pain Points direkt in der Standard-Auslieferung. In Kombination mit einer passgenauen Prozesseinbettung und sinnvollen Integrationen in die bestehende IT-Landschaft entstehen so spürbare Verbesserungen im Servicealltag.

Transparenz schaffen: Von operativen Daten zu belastbaren Kennzahlen

Ein häufig unterschätzter Aspekt digitaler Field-Service-Lösungen ist die Möglichkeit zur systematischen Auswertung von Serviceinformationen. Durch strukturierte Rückmeldungen entstehen valide Auskünfte zu Einsatzzeiten, Erstlösungsquoten oder Nacharbeiten. Diese Kennzahlen bilden die Grundlage für eine kontinuierliche Optimierung der Serviceprozesse.

Nachfolgende Tabelle zeigt beispielhaft, welche Informationen durch SAP Field Service Management konsistent verfügbar gemacht werden können und welchen Mehrwert sie bieten:

(Grafik 1)

Die Erfahrung aus Projekten zeigt, dass diese Transparenz nicht nur operative Entscheidungen verbessert, sondern auch die Argumentationsbasis gegenüber der Geschäftsführung stärkt.

Visuelle Einordnung der Prozesszusammenhänge

(Grafik 2)

Die Darstellung verdeutlicht, dass Effizienzpotenziale vor allem aus dem durchgängigen Zusammenspiel der Prozessschritte entstehen.

Fazit und Ausblick auf den nächsten Schritt

SAP Field Management bietet eins solides Fundament für die digitale Prozessoptimierung im technischen Außendienst. Bestehende Ineffizienzen können hiermit systematisch angegangen werden. Entscheidend ist dabei weniger die reine Einführung eines Tools als vielmehr die individuelle und passende Einbettung in die Serviceorganisation.

In der Beratungspraxis zeigt sich, dass individuell gestaltete Lösungen den Arbeitsalltag messbar vereinfachen und gleichzeitig die Steuerungsfähigkeit erhöhen. Ein weiterführendes Gespräch oder der Blick in unser Leistungsportfolio hilft Ihnen, den eigenen Reifegrad einzuordnen und nächste sinnvolle Schritte abzuleiten. Stets mit dem Fokus auf pragmatische Umsetzbarkeit und Passgenauigkeit für Ihren Betrieb.

Revolutionäre Software-Entwicklungsgeschwindigkeit dank KI

KI-basierte Coding-Assistenten wie Claude, Devin, Cursor oder ähnliche Werkzeuge verändern aktuell grundlegend, wie Software entsteht. Anforderungen wie „Bau mir eine App mit moderner UI“ werden innerhalb weniger Minuten in lauffähigen Code übersetzt. Entwicklungszeiten verkürzen sich spürbar, Prototypen entstehen in Rekordtempo und neue Ideen lassen sich deutlich schneller validieren.

Doch mit dieser Geschwindigkeit wächst auch der Druck auf Betrieb, Sicherheit und Compliance. Je schneller Code entsteht, desto wichtiger wird die Frage, wie nachhaltig und sicher diese Anwendungen tatsächlich betrieben werden können.

Warum KI-Speed-Coding so attraktiv ist

Der Reiz von KI-gestützter Entwicklung liegt klar in der Produktivität. Entwicklerinnen und Entwickler können sich stärker auf fachliche Anforderungen und Konzepte konzentrieren, während wiederkehrende Aufgaben automatisiert abgearbeitet werden. Besonders in frühen Projektphasen oder bei internen Tools verkürzt sich die Zeitspanne bis zur produktiven Nutzung erheblich. Der Geschwindigkeitsvorteil ist real und für viele Unternehmen inzwischen ein entscheidender Wettbewerbsfaktor.

Wo Geschwindigkeit ohne Kontrolle problematisch wird

In der Praxis zeigt sich jedoch schnell, dass funktionierender Code nicht automatisch sicher oder wartbar ist. KI-generierte Anwendungen enthalten häufig typische Schwachstellen, etwa unsaubere Authentifizierungsmechanismen, fehlende Eingabevalidierung oder den Einsatz veralteter Bibliotheken. Diese Risiken können lange unentdeckt bleiben, da der Code auf den ersten Blick korrekt funktioniert und die Sicherheit (oft) nicht die höchste Priorität hat.

Spätestens bei Sicherheitsprüfungen, Audits oder im laufenden Betrieb wird sichtbar, dass fehlende Transparenz und manuelle Nacharbeiten den ursprünglichen Geschwindigkeitsvorteil wieder relativieren. Wartbarkeit leidet, technische Schulden wachsen und Compliance-Anforderungen lassen sich nur mit hohem Aufwand erfüllen.

Was tun? Warum KI-Coding immer auch eine Betriebsperspektive braucht

Anwendungen enden nicht beim Commit. Sie laufen in einer Infrastruktur, erzeugen Logs, greifen auf Abhängigkeiten zurück und müssen dauerhaft überwacht werden. Genau hier entscheidet sich, ob KI-Coding langfristig ein Gewinn bleibt oder zum Risiko wird.

Ein zentraler Baustein ist dabei ein erweitertes technisches Monitoring. Systeme wie Zabbix lassen sich so einsetzen, dass sie weit über klassische Verfügbarkeitsprüfungen hinausgehen. So kann beispielsweise sichtbar gemacht werden, welche Bibliotheken im Einsatz sind, ob bekannte CVEs existieren oder ob sicherheitsrelevante Zustände auftreten. Auch Zugriffs- und Authentifizierungslogs lassen sich auswerten, um Auffälligkeiten frühzeitig zu erkennen. Hierdurch entsteht ein kontinuierliches Lagebild über den tatsächlichen Sicherheits- und Betriebszustand einer Anwendung, unabhängig davon, ob der Code manuell oder durch KI erzeugt wurde.

Automatisierung als Schlüssel zu Sicherheit und Compliance

Neben dem Monitoring spielt Automatisierung eine entscheidende Rolle. Viele sicherheitsrelevante Prüfungen werden in der Praxis noch manuell durchgeführt oder nur unregelmäßig kontrolliert. Automatisierte Abläufe sorgen dafür, dass diese Prüfungen zuverlässig und reproduzierbar erfolgen.

Dazu zählen unter anderem die regelmäßige Auswertung von Zugriffslogs, die Überwachung ablaufender Zertifikate oder Benutzerkonten sowie die strukturierte Dokumentation sicherheitsrelevanter Ereignisse. Die Ergebnisse werden automatisch in Reports überführt, die sowohl für den operativen Betrieb als auch für Audits genutzt werden können. Sicherheit und Compliance hängen damit nicht mehr vom jeweiligen Bearbeitenden ab, sondern sind fest im Betrieb verankert.

Der entscheidende Vorteil dieses Ansatzes liegt darin, dass die Geschwindigkeit der KI-gestützten Entwicklung erhalten bleibt. Gleichzeitig werden Risiken frühzeitig erkannt und systematisch kontrolliert. Sicherheit wird nicht zum nachgelagerten Korrekturprozess, sondern zum festen Bestandteil des gesamten Lebenszyklus einer Anwendung.

Fazit: KI-Coding und Sicherheit sinnvoll miteinander verbinden

KI-Coding ist ein mächtiges Werkzeug, das Entwicklungsprozesse nachhaltig beschleunigt. Damit dieser Vorteil nicht durch Sicherheits- oder Compliance-Probleme verloren geht, müssen Betrieb, Monitoring und Automatisierung von Anfang an mitgedacht werden. Geschwindigkeit und Sicherheit schließen sich nicht aus – sie lassen sich technisch sinnvoll miteinander verbinden.

Setzen Sie bereits KI-gestütztes Coding ein oder planen Sie den Einstieg?

Wir schauen uns gerne Ihre Entwicklungs- und Betriebsprozesse an und prüfen, wie sich Monitoring, Security-Checks und Automatisierung sinnvoll integrieren lassen, sodass die Geschwindigkeit-Benefits nicht zum Sicherheitsrisiko werden.

Einfach schreiben an service@inwerken.de. Unser IT-Team meldet sich bei Ihnen! Leistungen darüber hinaus finden Sie in unserem Portfolio.

• Erkennen von Jobabbrüchen
• Feststellen festhängender oder überlanger SAP-Jobs
• Analyse von Spool-Aufträgen
• Prüfen auf Anomalien in Logs
• Dokumentation für Audits und Qualitätssicherung

Diese Aufgaben sind wichtig, aber in der Praxis oft zeitintensiv, fehleranfällig und abhängig davon, wer sie ausführt. Genau hier setzen wir an, um den menschlichen Faktor und sich daraus ergebende Fehlerquellen zu reduzieren.

Unsere Lösung: Vollautomatisierte tägliche SAP-Health-Checks

Wir haben ein Framework entwickelt, das die täglichen SAP-Systemchecks vollständig automatisiert – reproduzierbar, sicher und mit voller Transparenz für den Prüfenden.

Per SAP GUI Scripting führt das System alle relevanten Transaktionen automatisch aus, setzt Variablen, Filter und Varianten korrekt und liest die benötigten Werte aus – ohne dass Anwenderinnen und Anwender etwas vorbereiten oder auswählen müssen.

Beispielhafte Steuerung der SM37:

self.find_by_id(‚/wnd[0]/usr/txtBTCH2170-JOBNAME‘).Text="*"
self.find_by_id(‚/wnd[0]/usr/txtBTCH2170-USERNAME‘).Text="*"
self.find_by_id(‚/wnd[0]/usr/chkBTCH2170-PRELIM‘).Selected=False
self.find_by_id(‚/wnd[0]/usr/chkBTCH2170-SCHEDUL‘).Selected=False
self.find_by_id(‚/wnd[0]/usr/chkBTCH2170-READY‘).Selected=False
self.find_by_id(‚/wnd[0]/usr/chkBTCH2170-RUNNING‘).Selected=False
self.find_by_id(‚/wnd[0]/usr/chkBTCH2170-FINISHED‘).Selected=False
self.find_by_id(‚/wnd[0]/usr/chkBTCH2170-ABORTED‘).Selected=True
self.send_key(8)

Kontextabhängige Checks

Das Skript erkennt automatisch, auf welchem SAP-System es ausgeführt wird und welche vordefinierten Prüfungen dort notwendig sind. Zum Beispiel werden bei Systemen, mit wenig wiederholten Jobs keine tiefgehenden Job-Analysen betrieben sowie bei Systemen ohne Spool-Prozesse die Spool-Prüfungen ausgelassen.

So sehen Anwenderinnen und Anwender zu jedem Zeitpunkt, welches System erkannt wurde und welche Checks aktiv bzw. noch auszuführen sind.

Intelligente Bewertung & Alerts

Wenn ausgelesene Werte des Systems definierte Grenzwerte überschreiten, gibt das Tool sofort Warnungen aus, sodass einfach geprüft werden kann, was die Ursache ist.
Beispiel anhand der Transaktion SWEQADM:

events_to_be_done = self.find_by_id("/wnd[0]/usr/tabsTAB_STRIP/tabpMONITOR/ssubSUB_CONTAINER:SAPLSWEQADM:1040/txtG_2_DELIVER_EVENTS_TEXT").Text
events_to_be_done_val = re.search(r"d+", events_to_be_done).group(0)
  if int(events_to_be_done_val)>1:
    alert("Val over 1, please handle this")

So werden Fehler früh erkannt, bevor sie den Betrieb beeinträchtigen.

Vollständige Dokumentation: PDF-Report & Excel-Zeitreihen

Alle Ergebnisse werden automatisch dokumentiert:

• PDF-Report pro Tag, perfekt für Audits, Übergaben an Kunden oder zur Betriebsdokumentation – auch mit automatisiertem Upload
• Excel/CSV-Tabellen, die täglich gefüllt werden und Trends sichtbar machen

So lassen sich langfristige Entwicklungen erkennen, z. B.:

• Wachstum in Tabellen
• Zunahme von Jobabbrüchen/Dumps
• Entwicklung bestimmter Queue- oder Prozesswerte

Der menschliche Blick bleibt wichtig, sieht aber mittels dieser Hilfestellung nur die relevanten Informationen, kompakt und sauber vorbereitet.

Dies gilt ebenso für die Abläufe in den Checks. Wenn eine Tätigkeit jeden Tag durchgeführt wird, geht diese in Fleisch und Blut über. Fehler sind dennoch menschlich und passieren. Beispielhafte Fehlerquellen sind:

• falsche Variante ausgewählt
• im falschen Mandanten eingeloggt
• Transaktionen verwechselt oder vergessen
• Werte nicht dokumentiert; nachträglich schwierig rekonstruierbar

Unsere Automatisierung eliminiert genau diese Risiken. Doch durch den Einsatz von Skripten wird ein korrekter Ablauf für den Betrieb erzeugt. Jede Prüfung läuft täglich identisch, unabhängig davon, wer sie ausführt. Das sorgt für Verlässlichkeit, Konsistenz und messbare Qualität sowie niedrigere Schulungsnotwendigkeit/Wissenstransfer bezüglich der Aktionen.

Zukunftssichere Erweiterbarkeit

Täglich stellt die SAP-Checklösung ihre Stabilität, Geschwindigkeit und Zuverlässigkeit unter Beweis.

Das verwendete Inwerken-Framework ist maßgeschneidert aufgebaut. Sobald es neue Anforderungen gibt, kann die Version leicht angepasst werden. Hierdurch ist das zusätzliche Einbauen von weiteren Checks/Transaktionsaufrufen einfach gestaltbar und kann für Audits auch versioniert abgelegt bzw. dokumentiert werden. Zusätzliche Checks lassen sich jederzeit einbinden, ohne den Gesamtprozess anzupassen. Dadurch wächst die Lösung gemeinsam mit der SAP-Landschaft.

Fragen und Kontakt

Sie benötigen Unterstützung bei der Automatisierung Ihrer SAP-Vorgänge und -Checklisten? Einfach schreiben an service@inwerken.de. Unser IT-Infrastruktur-Team meldet sich bei Ihnen! Leistungen darüber hinaus finden Sie in unserem Portfolio.