SAP-Oberfläche übersetzen mit der SE63

 SAP, Übersetzung  Kommentare deaktiviert für SAP-Oberfläche übersetzen mit der SE63
Mrz 292016
 

Die Übersetzung der Oberfläche läuft üblicherweise in zwei Schritten:

  • Übersetzung im Entwicklungssystem mit der SE63 durchführen
  • Vorgenommene Übersetzung mit der SLXT in einen Übersetzungsstransport schreiben

Tipp: Die SE63 ist für die schnelle Übersetzung von Objekten gedacht. Wenn Sie in SAP komplette Pakete für die Übersetzung schnüren wollen, nutzen Sie die Transaktion LXE_MASTER zum Einrichten und Verwalten der Übersetzungsumgebung.

Im Folgenden liegt der Fokus auf Kurztexten.

Übersetzungen mit der SE63 durchführen
Mit der Transaktion SE63 können direkt Objekte übersetzt werden. Der große Nachteil der SE63 ist, dass man sehr gut wissen muss, was man übersetzen will. (Hierfür ist die Auswertung mit SNP Dragoman sehr geeignet, wie ich in einem zukünftigen Beitrag beschreibe.)

Schon die Auswahl nur über Kurztexte und dort Oberflächentexte zeigt die große Vielfalt an Übersetzungsobjekten in SAP. Ohne die Kenntnis von Objekttyp und technischem Namen kann die Übersetzung nicht durchgeführt werden.
se63_1

se63_2 se63_3

Die SE63 kann allerdings auch direkt z.B. aus der SE80 über ein Enwicklungspaket angesprungen werden.
Dazu das Entwicklungspaket aufrufen, z.B. einen Dynpro auswählen und Springen > Übersetzung aufrufen.

se63_über_se80

Eine weitere Aufrufsvariante ist, in der SE10 einen Transport aufzurufen, in einzelne Objekte des Transports zu springen und dann wieder über Springen > Übersetzung zu gehen.

Im Folgenden sehen Sie, wie eine zu übersetzende Zeile dargestellt wird. In der Titelzeile steht das aufgerufene Objekt. Es kann direkt in die freie Zeile geschrieben werden. Mit einem Doppelklick können Sie direkt den Text von oben (oder unten, wenn es einen englischen Vorschlag gibt) in die freie Zeile kopieren und dort bearbeiten.
se63_über_se80_2

Danach die Übersetzung speichern.

Übersetzungen mit der Transaktion SLXT transportieren

Nach der Übersetzung muss für die Objekte manuell ein Übersetzungstransport angelegt werden. Dies machen Sie mit der Transaktion SLXT. Geben Sie dort an, welche Übersetzungen transportiert werden sollen, z.B. alle, die Sie am heutigen Tag in Entwicklungspaket X durchgeführt haben. Wählen Sie „Workbenchauftrag“ und beachten Sie bei der Benennung des Transport die bei Ihnen gültigen Transportrichtlinien.

Transaktion SLXT zur SE63

Weiterführende Links:

SAP-Dokumentation zur SE63

SAP-Dokumentation zur SLXT

SAP-Dokumentation zur LXE_Master

SAP-Dokumentation und SAP-Übersetzung

 Dokumentation, SAP, Übersetzung  Kommentare deaktiviert für SAP-Dokumentation und SAP-Übersetzung
Mrz 242016
 

Seit einigen Jahren habe ich in Kundenprojekten viel Erfahrung mit Lösungen rund um SAP-Dokumentation und -Übersetzung gesammelt und biete dieses Thema jetzt explizit an.

Warum ist SAP so ein spezieller Bereich? Hier einige Gründe:

SAP-Dokumentation

  • Hinter dem Kürzel SAP stecken sehr viele unterschiedliche Module, die mehr oder weniger vernetzt sind. Eine SAP-Dokumentation ist damit eigentlich immer eine Modul-Dokumentation.
  • Die Standardfunktionen der Module sind dabei durch kundenspezifische Erweiterungen angereichert. Der übliche Anspruch einer „vollständigen“ Dokumentation ist weder möglich noch erstrebenswert – es geht immer um Dokumentation spezifischer Prozesse. Ohne die SAP-Experten geht dies leider nicht. Ein wildes Testen der Oberfläche wie bei kleineren Software-Paketen ist unmöglich.
  • Durch die Prozessorientierung sind Anwenderdokumentationen oft Klick-Anleitungen, die durch wichtige, kundenspezifische Informationen ergänzt werden müssen.
  • Auf der Entwicklungsseite ist es wichtig, in den Dokumentationen sowohl die betriebswirtschaftliche Seite als auch die betroffenen Transaktionen, Rollen, Tabellen, Programme, Funktionen, User Exits, Prüfungen usw. zu beschreiben. Auch hier muss vorsichtig abgegrenzt werden, was Standard und was Erweiterung ist.

SAP-Übersetzungen

  • SAP hat eine sehr eigene Terminologie, die sich auch in den englischen Übersetzungen auswirkt.
    Dazu kommt oft firmeninterne Terminologie, die sich auch von Modul zu Modul bzw. Bereich zu Bereich unterscheiden kann.
  • Bei der Übersetzung von SAP-Oberflächen gibt es mehrere Möglichkeiten. Die Oberflächen können beispielsweise direkt im System übersetzt werden mit der SE63 oder über Objekte (dies erfordert Systemzugriff für die Übersetzer), oder alternativ können Tools wie SNP Dragoman verwendet werden, um die Inhalte als Excel zu liefern und sie an Übersetzungsdienstleister herauszugeben.
  • In problematischen Fällen muss auch eine Transportanalyse bzw. eine Suche in älteren Transporten über SE10 > „Objekt in Transport“ durchgeführt werden. Andersherum können Transporte von Objekten rein dafür geschnürt werden, dass diese handlicher übersetzt werden können.
  • Bei Erweiterung eines SAP-Systems auf weitere Sprachen ist es wichtig, mittels Scoping etwas einzugrenzen, welche Bereich tatsächlich übersetzt werden müssen. Dabei kann sich allerdings durchaus ergeben, dass das „Auseinanderfieseln“ der relevanten Entwicklungspakete zeitaufwendiger ist, als die kompletten SAP-Oberflächentexte auszuleiten und sie in die Übersetzung zu geben.

Viele dieser Themen werden hier im Blog in den nächsten Monaten ausführlicher diskutiert.

Tipp: Online-Hilfe mit Walk.me

 Dokumentation, Web  Kommentare deaktiviert für Tipp: Online-Hilfe mit Walk.me
Mrz 222016
 

Neulich bin ich auf ein interessantes online-basiertes Tool namens Walk.me (http://www.walkme.com/) gestoßen. Mit diesem kann man bevorzugt für internetbasierte Seiten, aber auch in einem Intranet eine Online-Hilfe aka „Walk-through“ erstellen, bei dem die Anwender durch eine Schrittfolge geführt werden.

Wer sich für die technischen Details interessiert, hier zwei Links zu Whitepapers:
Walk me Architecture
Walk Me Salesforce Solution Architecture

Für klassisches SAP R/3 ist dieses System leider nicht geeignet, es könnte allerdings mit Netweaver-Ausgaben und SAP Fiori kombiniert werden.

Tipps zu SNP Dragoman für SAP-Übersetzungen

 SAP, Übersetzung  Kommentare deaktiviert für Tipps zu SNP Dragoman für SAP-Übersetzungen
Mrz 122016
 

Seit 2011 arbeite ich mit SNP Dragoman. Mit diesem Tool können SAP-Übersetzungen leichter durchgeführt werden, da über den Export nach Excel ein Austausch mit Übersetzungsbüros, aber auch eine leichtere Inhouse-QM möglich ist.

Dragoman gehört inzwischen zum SNP Transformation Backbone, daher ist es vermutlich in vielen großen Firmen jetzt lizenztechnisch leichter verfügbar als früher.

Meine Beiträge werden sich beschäftigen mit

  • Auswertungen auf Basis von SAP-Entwicklungspaketen.
  • Auswertungen auf Basis von SAP-Transporten
  • Analysen als Hilfsmittel für Übersetzungen mit der SE63/SLXT

Weiterführende Links:

SNP Dragoman Herstellerseite

Webinar von SDL Trados zu SNP Dragoman (Youtube)

 

Empfehlungen für Screencast-Tools

 Sammelsurium  Kommentare deaktiviert für Empfehlungen für Screencast-Tools
Aug 172015
 

In diesem Artikel geht es um kostenlose Tools, um Bildschirmaufnahmen aufzunehmen.

Mein Favorit, mit dem ich selbst am meisten gearbeitet habe, ist immer noch Camstudio (http://camstudio.org/.

Noch ungetestet: Ezvid (Ezvidhttp://www.ezvid.com/).

In letzter Zeit kommen einige webbasierte Tools in Mode, die auch direktes Veröffentlichen im Internet ermöglichen:
Screen-o-matic (http://www.screencast-o-matic.com/)
Screenr  (https://www.screenr.com/)
Apowersoft Screenrecorder http://www.apowersoft.com/free-online-screen-recorder)

Dabei ist ein Upload zu Youtube meist frei, Upload in geschützte Bereiche kostet dagegen. Über die Filmqualität kann ich mangels eigener Tests noch nichts sagen.

In Sachen Preis-Leistungsverhältnis ist mein Favorit immer noch SnagIt (https://www.techsmith.com/snagit.html).

Wer nicht lange nachbearbeiten will und auch für Screenshots ein gutes Tool haben will, fährt damit sehr gut.

OTRS als Support-/Ticketing-System in der technischen Redaktion

 Business, Dokumentation  Kommentare deaktiviert für OTRS als Support-/Ticketing-System in der technischen Redaktion
Jun 232014
 

In meinem Hauptprojekt arbeitet mein Redaktionsteam seit neuestem mit OTRS als Ticket-System.

Warum tun wir das?

  • Wir haben einen großen Arbeitsanteil an Support der Editoren unseres Confluence-Systems, damit ist ein solches Ticket-System sinnvoll.
  • Das Redaktionsteam ist gewachsen und Tasks werden stärker verteilt. Mit OTRS wird klarer, wer was tut bzw. in der Pipeline hat.
  • Unsere User können an ein zentrales Postfach mailen und damit ein Ticket im OTRS erzeugen, das sich dann idealerweise selbst verteilt.
  • OTRS wurde eigentlich primär für eine Hotline eingeführt, soll aber zukünftig als Service auch anderen Gruppen zur Verfügung stehen. Da wir die Inhouse-Dokumentation von OTRS unterstützen, ist es sinnvoll, auch selbst damit zu arbeiten.

(Mögliche) Nachteile der OTRS-Nutzung:

  • Es ist besser sichtbar, wieviele und was für Anfragen ein Team bearbeitet. Das möchte vielleicht nicht jedes Team.
  • Es ist nicht möglich, Tickets auf regelmäßige Wiederholung zu stellen (z.B. „alle vier Wochen Auswertung X“). OTRS ist auf Durchfluß optimiert, nicht auf Dauerpflege und langfristige Aufgaben. Solche Informationen haben wir daher im Confluence belassen.
  • Auch bei Verwendung von OTRS muss man als Redaktionsleitung regelmäßig prüfen, dass keine Tickets durchs Raster fallen und unbeantwortet bleiben.
  • Neue Prozesse müssen definiert und mit dem Team etabliert werden. Dies verursacht etwas organisatorischen Aufwand.
  • Unsere User müssen sich daran gewöhnen, statt direktem persönlichem Kontakt zumindest im Mail-Header mit OTRS die Mails auszutauschen. Manche interpretieren dies dahingehend, dass unserem Team das OTRS „übergestülpt“ wurde – was nicht der Fall ist. Hier hilft nur Aufklären im Gespräch.

Bisher überwiegen die Vorteile für uns – und davon abgesehen ist es für Redakteure im Bereich der Softwaredokumentation gut, auch einmal mit Ticketing-Systemen zu arbeiten, da diese in Support und Entwicklung sehr häufig sind.

Für andere Redaktionsteams würde ich eine Empfehlung von OTRS daran festmachen, wie hoch der Supportanteil in der Arbeit ist. Für Verteilung von Dokumentations-Arbeitspaketen ist es aus meiner Sicht weniger sinnvoll, hier sollten eher klassische Projektmanagement-Werkzeuge eingesetzt werden.

Best Practices und Softwareentwicklung

 Software  Kommentare deaktiviert für Best Practices und Softwareentwicklung
Mrz 182013
 

Neulich las ich einen Artikel, in dem ausgeführt wurde, dass Best Practices oft das Festhalten an veralteten Standards und Ideen bedeutet.

Vielleicht bin ich ja so altmodisch, aber manche Standards, die sich in der Softwareentwicklung durchgesetzt haben, finde ich doch ganz sinnvoll.

Anbei einige Not-To-Dos aus meiner beruflichen Praxis.

  • Bei der Installation „das System ist Unicode-fähig“ zu melden, ohne dies auch nur einmal getestet zu haben.
  • Bei Serverupdates direkt die Änderungen auf den Produktivserver einzuspielen, statt ein sauberes Staging über den Testserver mit Tests und Freigabe durchzuführen.
  • Bei Softwareupdates einen angeblichen Bugfix zu liefern, der sich als umfangreiches Update mit veränderter Oberfläche  herausstellt — und dann noch ohne aktualisierte Dokumentation, womit die neuen Optionen relativ nutzlos werden.

 

Styleguide für LaTeX-Dokumentation

 Sammelsurium  Kommentare deaktiviert für Styleguide für LaTeX-Dokumentation
Mrz 112013
 

Neulich kam eine ungewöhnliche Anfrage rein – ein Styleguide und Dokumentationsberatung für eine in LaTeX geschriebene Systemdokumentation.

Mit LaTeX habe ich nur einmal zuvor gearbeitet, und dann damals mit Lyx, das dafür sorgt, dass man gar nicht erst der echten Syntax begegnet ;) Allerdings habe ich inzwischen zwei Jahre Docbook-Erfahrung, daher kann ich nach dem Lesen einiger Einführungen in LaTeX-Syntax zumindest grundlegend damit arbeiten.

Styleguides erstelle ich eigentlich regelmäßig, aber – das große Aber – normalerweise im Zuge der Dokumentationserstellung, also während ich selbst am Schreiben bin. Das ist mir erst jetzt bewusst geworden, dass ich ein Gefühl für die Materie brauche, bevor ich formale Dokumente zu deren Dokumentationserstellung schreiben kann.

Von dem her habe ich zu Übungszwecken den Styleguide selbst dann auch in LaTeX geschrieben. Und dabei gelernt, dass Tabellen in LaTeX-Syntax noch viel komplexer sind als in Wiki-Markup oder reStructured Text. Es ist halt nie handlich, eigentlich spaltenbasierte informationen in einen Zeilenfluß zu quetschen. Excel ist da definitiv einfacher, aber vom Vorschlag eines Kollegen neulich, man könne die Tabellen ja in Excel schreiben und dann einen Screenshot davon in die Dokumentation einbauen, kann ich nur dringend abraten. Zu schnell geht die Datei mit dem Original der Tabelle verloren, so daß zukünftige Generationen an Bearbeitern dann mühsam die Tabelle neu abtippen müssen.

Meine Installation auf Windows 7 besteht übrigens primär aus TeXMaker und MikTeX. Bei letzterem sollte man einstellen, dass fehlende Pakete auf Nachfrage nachgeladen werden. 

Leseempfehlungen für Heft 3/12 technische kommunikation

 Dokumentation  Kommentare deaktiviert für Leseempfehlungen für Heft 3/12 technische kommunikation
Mai 192012
 

Zwei Lesetipps für das aktuelle Heft 3/12 der technischen kommunikation(*):

  • Praxistipps Word: Regelgerechtes Ersetzen auf S. 37 beschäftigt sich mit Regular Expressions aka Mustervergleich in der Word-Funktion Suchen und Ersetzen, der sich hinter dem Schalter „Platzhalter verwenden“ versteckt.
  • Rechtschreibhilfen im Vergleich auf S. 45 bietet einen guten, wenn auch schmerzhaften Einblick in die Situation der Rechtschreibung in Deutschland, besonders auf die vielen gängigen/nicht gängigen//erlaubten/nicht erlaubten Variationen. Mein Bauchgefühl, dass das mit der Rechtschreibung immer weicher und dadurch definitiv auch schwammiger wird, wird hier voll bestätigt. Der Duden verliert dabei bei mir etwas – die Rechtschreibungsvorschläge von Wahrig und dpa gefallen mir tendenziell besser. Der Verlierer allerortens ist die Konsistenz; es ist schwierig genug, firmenspezifische Terminologie konsistent zu halten – wenn man dies auch noch mit dem „normalem Deutsch“ machen muss, bläht es den hausinterne Redaktionsleitfaden (so vorhanden) reichlich auf.

„technische kommunikation“ ist die Verbandszeitschrift der tekom e.V., dem deutsche Fachverband für Technische Kommunikation und Informationsentwicklung.

Outlook für Kanban nutzen

 Business  Kommentare deaktiviert für Outlook für Kanban nutzen
Mai 182012
 

Neulich habe ich mich im Büro ein wenig mit Eigenorganisation beschäftigt und bin dabei auf Personal Kanban gestoßen.

Besonders zwei Aspekte von Kanban finde ich interessant:

  • den Durchfluß möglichst gleichförmig zu halten und
  • die Zahl der in Arbeit befindlichen Tasks möglichst klein zu halten.

Unpraktisch finde ich bei Kanban (wie auch bei Scrum) die Notation von links nach rechts – sowas ist an einer Pinnwand ja ganz nett, aber in Standardsoftware auf einem Bürorechner schlecht abzubilden.

Da ich im Büro sowieso schon Outlook exzessiv für tägliche ToDos genutzt habe, kam ich auf die Idee, den Kanban-Workflow von oben nach unten im Kalender abzubilden. Der Screenshot zeigt die grundlegende Situation:

  • Zuoberst (Zeitraum 5-7 Uhr) stehen die ToDos, die ich an diesem Tag abarbeiten will.
  • ToDos, die in Arbeit gehen, verschiebe ich in den Zeitslot, in dem ich gerade bin.
  • Erledigte Aufgaben wandern in die Abendschicht.
Outlook-Screenshot mit Kanban-Workflow

Kanban in Outlook

Vorteile:

  • Ich habe immer einen guten Überblick über den Durchfluss und die Verteilung der Aufgaben.
  • Aufgaben in Arbeit blocken den jeweiligen Zeitpunkt im Kalender, so dass Kollegen bei der Terminvergabe eher rückfragen.
  • Am Ende des Tages habe ich eine Übersicht über alles Erledigte (früher habe ich sowas einfach gelöscht, dann zeigt nur der leere Kalender einen erfolgreichen Tag… nicht sehr motivierend).

Nachteil: Da alles über Outlook-Termine läuft, ploppen oft Terminerinnerungen hoch.

Aufgaben, die nicht erledigt werden konnten, verschiebe ich z.B. auf den nächsten Arbeitstag frühmorgens, d.h. in die nächsten ToDos.

Mein Fazit nach zwei Monaten mit Personal Kanban in Outlook – klappt super und ist eine sehr pragmatische Lösung für Kanban innerhalb einer Standard-Officeumgebung, in der man weder Software installieren noch ständig etwas im Internet pflegen will.

© 2012 Doku-Hotline Suffusion theme by Sayontan Sinha