Wenn Sie von ECC zu SAP S/4HANA wechseln, aber nicht beabsichtigen, Ihr SAP in einem anderen Land einzusetzen, dann lesen Sie nicht weiter. Allerdings ist es eher wahrscheinlich, dass Ihr erster Rollout schon auf dem Plan steht, was wiederum heißt, dass es an der Zeit ist oder bald sein wird, sich Gedanken über das Thema Übersetzung zu machen. Hier kommen ein paar Tipps, worüber Sie vorher nachdenken sollten.
Dieser Artikel erschien erstmal am 16. September 2019. Er wurde überarbeitet und ist bildet jetzt den aktuellen Stand der SAP S/4 HANA-Übersetzung ab.
Nichts ist so beständig wie die Veränderung
Viele Dinge ändern sich, wenn Sie von ECC zu SAP S/4HANA wechseln. Die gute Nachricht ist aber, dass bei der Übersetzung auch vieles gleich bleibt. Was sich nicht groß geändert hat, sind zum Beispiel die integrierten Übersetzungstools rund um Transaktion SE63 sowie die Möglichkeit, Texte für die Übersetzung in verschiedene Formate zu exportieren. Ebenfalls unverändert sind die verschiedenen Optionen im SAP-Standard zum Einrichten und Konfigurieren und Einrichten einer Übersetzungsumgebung. Das liegt daran, dass die von SAP gelieferten Übersetzungstools an die Komponente SAP_BASIS des Systems gebunden sind, und diese Komponente ist sowohl in Ihren SAP-S/4HANA-Systemen als auch in den SAP-Business-Suite-Systemen vorhanden.
Während sich die meisten der Betrachtungen um die On-Premise-Lösung von S/4HANA drehen, geht der Weg für viele weltweit zumindest teilweise zur Cloud. Deshalb möchte ich nicht versäumen, SAPs S/4HANA-Cloud-Angebote zu erwähnen, also die HANA Enterprise Cloud (HEC), SAP S/4HANA Single Tenant und SAP S/4HANA Cloud Edition. In Sachen Übersetzung spielt dabei lediglich die SAP S/4HANA Cloud Edition ein Sonderrolle, daher soll es im Folgenden nur um die On-Premise-Lösung, um HEC und um Single Tenant gehen.
SAP Fiori oder SAP GUI
In S/4HANA sind immer noch dieselben Programme und ABAP-Dictionary-Objekte vorhanden, die Sie aus SAP ERP kennen. Die Frage ist nur, wie man sie verwendet. Im Customizing hat sich aus Übersetzungssicht nicht viel geändert – es bleibt kompliziert, und ein Tool wie CDTM ist immer noch die beste Option, wenn Sie effizient übersetzen möchten. Aber was die Benutzeroberfläche Ihrer Eigenentwicklungen angeht, gab es doch entscheidende Änderungen. Die Kernfrage hierbei ist, ob Sie SAP Fiori verwenden oder ob Sie am guten alten SAP GUI festhalten (lassen wir mal kurz außer Acht, dass Fiori auch mit ECC verwendet werden kann, und dass es mehr UI-Technologien als nur diese zwei großen gibt).
Fiori-Apps, Frontend und Backend
Wenn Sie nur SAP GUI brauchen, habe ich nicht viel Neues für Sie. Es gibt ein paar zusätzliche Objekttypen, die beim Festlegen des Übersetzungsumfangs berücksichtigt werden müssen, aber das war es dann im Grunde auch schon. SAP Fiori ist jedoch wirklich grundlegend anders. Die meisten Fiori-Apps bestehen aus drei Teilen – einer Frontend-Komponente, die als BSP-Anwendung vorgehalten wird, ABAP-Objekten, die im Backend genutzt werden, und Gateway-Services, die als verbindendes Element fungieren. Sie können Fiori-Apps in Programmiersprachen wie Java, JavaScript oder Python erstellen, aber auch ABAP kann weiterhin verwendet werden.
Wichtig in Sachen Übersetzung ist aber, dass sich große Teile Ihrer Benutzeroberflächentexte in i18n.properties-Dateien befinden, und dass Sie diese Dateien nicht mit den Standard-Tools Ihres ABAP-Stack-Systems übersetzen können. Da die Fiori-Apps aber nach wie vor zumindest ABAP-Dictionary-Objekte wie Datenelemente, Customizing- und Stammdatentabellen aufrufen, deren Texte dann auf der Benutzeroberfläche erscheinen, kommt die herkömmliche SAP-Übersetzung auch weiterhin zur Anwendung. Das heißt, Sie werden es mit einem gemischten Szenario zu tun haben, in dem Sie sowohl Textdateien als auch ABAP-basierte Texte übersetzen.
Dadurch wird Ihr S/4HANA-Übersetzungsprojekt um einiges komplexer, da die i18n.properties-Dateien separat, außerhalb des SAP-Systems übersetzt werden und dann die Übersetzungen von Hand auf die entsprechenden BSP-Seiten kopiert werden müssen (oder in die IDE Ihrer Wahl). Im Backend müssen aber dennoch diverse Dictionary-Objekte, Textelemente etc. übersetzt werden. Und natürlich muss zuvor überhaupt erst einmal ermittelt werden, welche Backend-Texte eigentlich von Ihren Fiori-Apps verwendet werden. Aus diesem Grund entstand unser Add-on i18n Translation Manager for SAP Fiori , das für genau dieses Szenario entwickelt wurde und alle relevanten SAP-Texte in einem Übersetzungsprojekt vereint.
Bestehende Eigenentwicklungen in S/4HANA-Übersetzungsprojekten
Wichtig zur Planung Ihres Übersetzungsaufwands ist auch, was für ein S/4HANA-Projekt Sie planen. Bei einer Migration aus dem ECC werden in Ihrem S/4HANA-System immer noch viele alte Z-Objekte vorhanden sein, selbst wenn Sie zuvor so viel benutzerdefinierten Code wie möglich aussortiert haben. Somit ist es umso wichtiger, den richtigen Übersetzungsumfang festzulegen, damit Sie keine Zeit mit der Übersetzung von Texten aus den alten Z-Objekten verschwenden, die nicht mehr verwendet werden. Wenn Sie hingegen einen Greenfield-Ansatz verfolgen, wird das Übersetzen Ihrer Eigenentwicklungen viel einfacher. Denn unabhängig von der UI-Technologie, die Sie verwenden, wird der Fußabdruck Ihres benutzerdefinierten Codes viel geringer sein, und damit auch Ihre Übersetzungskosten.
Los geht’s mit dem Übersetzen
Während sich dieser Artikel nur oberflächlich damit beschäftigt, was Sie bei der Übersetzung von Texten aus Ihren S/4HANA-Systemen bedenken müssen, so ist eines absolut klar: Die SAP-Übersetzung bleibt in gleichem Maße komplex. Wenn es um die Übersetzung von Formularen, Customizing-Texten und Stammdatentexten geht, hat sich nicht viel geändert. Aber bei eigenentwickelten Benutzeroberflächen gibt es noch keinen klaren Sieger: Während einige Unternehmen weiterhin SAP-GUI-Transaktionen bauen, setzen andere ganz auf SAP Fiori .
Erfahren Sie mehr über unsere Services im Bereich SAP-Übersetzung…