Die Ausgangslage
Wenn Sie mit der Migration zu S/4HANA beginnen , erhalten Sie bei Ihren ersten Prüfungen eine Liste der Anwendungen, die nicht mit S/4HANA kompatibel sind. Einige von ihnen haben neue Releases, die mit S/4HANA kompatibel sind, andere nicht.
Die Herausforderung
Eines der technischen Probleme ist, dass selbst für SAP-zertifizierte Lösungen von Drittanbietern die Deinstallation einer Fremdlösung war bis vor ca. 3 Jahren nicht mehr möglich niemals eine Anforderung von SAP. In jüngerer Zeit wurde die Deinstallation durch die Verwendung von OSS-Hinweisen wie 1883223 als Vorlage für Partner und 2011192 für von SAP bereitgestellte Add-Ons möglich. Neue Add-Ons sollten als Voraussetzung für die SAP-Zertifizierung deinstallierbar sein.
Je nach Softwarehersteller werden Ihnen im Rahmen der Wartung Deinstallationspakete zur Verfügung gestellt, die ggf. einen gültigen Wartungsvertrag voraussetzen. Eine andere Option könnte sein, die S/4HANA-kompatible Version zu kaufen und diese später zu installieren, und dann haben Sie die Möglichkeit, den alten Code zu entfernen.
Sie können dies auch selbst tun, indem Sie manuell Transporte mit gelöschten Objekten erstellen, aber dies wird nicht empfohlen und funktioniert möglicherweise nicht einmal für alle Objekte. Die Schwierigkeit der Implementierung, die Unsicherheit über die Effizienz und die schlechten Ergebnisse dieser Methode sind einige der Gründe, warum SAP eine Deinstallationsfunktion für Add-Ons von Drittanbietern in SAINT implementiert hat.
Wenn Lösungen von Drittanbietern an Ihre Bedürfnisse angepasst wurden, kann dies komplexer werden, da der Hersteller möglicherweise nicht alle Objekte kennt oder ein eigenes Deinstallationspaket erstellen muss.
Alles in allem werden die Kunden am Ende dafür bezahlen: neues Produkt, verlängerter Vertrag, Deinstallationshilfe oder interne Teamzeit. Die Wahrheit ist, dass zusätzliche Kosten darauf zurückzuführen sind, dass das Entfernen von Code von Drittanbietern nie als notwendig erachtet wurde.
Und dafür gibt es einen guten Grund.
Der Grund ist, dass Software geprüft werden kann . Dies kann aus internen, externen, steuerlichen, rechtlichen oder datenschutzrechtlichen Gründen erfolgen. Um nur eines als Beispiel herauszugreifen: Die Prüfung von Daten, die mit Software generiert wurden, ohne dass der Code zur Erstellung verwendet wurde, ist nicht machbar. Prüfer sind zwar nicht verpflichtet, den Kodex zu prüfen, könnten aber auch verlangen, ihn einzusehen, falls sie es für notwendig erachten, die Daten zu validieren.
Bei TJC generieren wir Steuerdaten : FEC, SAF-T, SII und spezielle Anfragen von Steuerbehörden und Wirtschaftsprüfern. Beim Upgrade verfolgt SAP Codeentwicklungen in ABAP durch die Change- und Transport-Management-Systeme. So lässt sich jederzeit eindeutig und lückenlos festhalten, welcher Code im System vorhanden war.
Erfahren Sie in diesem On-Demand-Webinar, wie Sie die S/4-Migrationszeiten und die Gesamtbetriebskosten Ihrer SAP-Systeme bei der Migration zu S/4HANA reduzieren können. Jetzt ansehen! https://info.tjc-group.com/webinar-data-archiving
Das Risiko
Aber der Umstieg auf S/4HANA ist anders: Der Code geht verloren und ist nur noch in ECC-Versionen verfügbar . Und das war nicht geplant. Wenn das ECC-System aus der Landschaft entfernt wird, ist der Code nicht mehr verfügbar, aber die generierten Steuerdateien sind noch vorhanden. Da der Code nicht mehr verfügbar ist, um zu demonstrieren, wie das ursprüngliche Datensteuerpaket erstellt wurde, werden die Dateien in den meisten Ländern nicht mehr akzeptiert, da sie nicht mehr vertrauenswürdig sind.
Dies kann für Ihr Unternehmen in eine sehr unangenehme Situation enden, es kann in Bezug auf Bußgelder, Strafen und den Ruf der Marke kostspielig werden. Beachten Sie, dass dies auch gilt, wenn Code mit SAP-Standardsoftware generiert wurde. Sobald das System weg ist, ist der Code nicht mehr verfügbar und daher gilt die gleiche Logik.
Die Lösung
Also, ja, die Deinstallation von Software von Drittanbietern hat ihren Preis und kann das Unternehmen gefährden. Dasselbe gilt für benutzerdefinierten Code. Ein sicherer Ansatz besteht darin, die Außerbetriebnahme des Systems in Ihren Wechsel zu S/4 HANA einzubeziehen . Wenn Sie dies nicht geplant haben, ist es aus Sicht des Risikomanagements sinnvoll, sich beim Entfernen von Tools von Drittanbietern Unterstützung zu holen.
Bei Fragen zum Thema nehmen Sie einfach Kontakt mit uns auf .
Weil Ihre Daten wichtig sind .
Thierry JULIEN, CEO und Gründer der TJC Group
Siehe den Artikel der anderen CEO-Ecke .
