Übersetzungsplanung bei der Implementierung von SAP S/4HANA

Veröffentlicht am 31 Mar 2020

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.

Stehen Sie vor einer S/4HANA-Implementierung? Sichern Sie sich schon heute unser Whitepaper zur SAP-Übersetzung – denn der nächste internationale Rollout kommt bestimmt…

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 im 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).

SAP GUI und SAP Fiori.

Das gewohnte SAP-Easy-Access-Menü und das neue SAP Fiori Launchpad.

Zwei Varianten von Fiori

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. Wichtig ist zunächst, dass Fiori-Apps vollständig in ABAP, in Ihrem ABAP-Stack-System, erstellt werden können, wobei eine Mischung aus herkömmlichen ABAP-Objekten und aus Gateway-Objekten verwendet wird. Sie können Fiori-Apps aber auch mit anderen Programmiersprachen wie Java, JavaScript oder Python erstellen. In diesem Fall befinden sich große Teile Ihrer Benutzeroberflächentexte in i18n.properties-Dateien, und diese Dateien können Sie nicht mit den Standard-Tools Ihres ABAP-Stack-Systems übersetzen. 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 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 werden.

SAP-Backend-Texte und properties-Dateien.

Texte aus einem Datenelement können Seite an Seite mit Texten aus properties-Dateien stehen.

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, sei es in ABAP oder einer anderen Programmiersprache.

Erfahren Sie mehr über unsere Services im Bereich SAP-Übersetzung