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.

Share

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.

Share

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.

Share

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.

Share
 

Es gibt sicherlich sehr viele bessere Lösungen, aber manchmal sitzt man mit einem IE und einem Office-Paket da und braucht gaaanz schnell die Farbe eines Textes… und da habe ich heute dazugelernt, wie das auch gehen kann.

  1. Den zu analysierenden Text der Webseite nach Word kopieren (sowohl in Version 2003 als auch 2010 getestet).
  2. Auf ein Wort darin klicken, z.B. den blauen Link.
  3. Neben dem Button „Schriftfarbe“ auf den Pfeil klicken und die Option „Weitere Farben“ wählen. Farbwerte von Webtexten auslesen mit Word 1
  4. Im Farben-Fenster auf die Registerkarte „Benutzerdefiniert“ klicken. Dort finden sich dann die RGB-Farben des Textes.
    Farbwerte für Webtexte mit Word auslesen
  5. Dies kann man dann in eine webtaugliche Farbe übersetzen, beispielsweise auf http://html-color-codes.info/.

Wie gesagt – keine schöne Methode, aber sie funktioniert schnell und mit typischen Großfirmenbordmitteln :)

Share

Word-Tipp – Formatierungen in HTML übersetzen

 Dokumentation  Kommentare deaktiviert für Word-Tipp – Formatierungen in HTML übersetzen
Aug 162010
 

Ein häufiges Problem, wenn man manuell Word-Texte in ein taugliches HTML bringen will: Wie bekommt man am schnellsten z.B. kursive Formatierungen umgesetzt?

Der Trick heißt Ersetzen mit Wildcard.

  1. In Word über Bearbeiten > Ersetzen (STRG+H) den entsprechenden Dialog öffnen.
  2. Mit dem Cursor im Feld „Suchen nach“ auf „Erweitern“ klicken und über „Format“ das Zeichenformat „kursiv“ wählen.
  3. Dann im Feld „Ersetzen durch“ <i>^&</i> eingeben.
  4. Auf „Alle ersetzen“ klicken. Alle kursiv formatierten Texten werden als italic getaggt.

Dies geht natürlich auch für bold oder underlined.

Share

Doku-Slogan des Tages

 Dokumentation  Kommentare deaktiviert für Doku-Slogan des Tages
Jul 202009
 

„Two hours of trial and error can save ten minutes of manual reading.“

Share
 

Betrifft mich aktuell nicht, aber auch ich habe schon „fictitious documentation“ verfasst:

Fictitious documentation refers to documentation that fails a lie detector test but which passes the project manager’s approval. (zum Artikel)

Idealerweise entspricht die Dokumentation dem Ist-Stand; realistischerweise ist regelmäßig ein Soll-Stand abgebildet, da z.B. nur eine unvollständige Software-Vorversion verfügbar ist. Auch das Verschweigen bestimmter Eigenschaften (besonders solcher, die potentiell Benutzer verärgern) ist nicht selten.

Der zitierte Artikel bezieht sich primär auf echte Bugs und die Frage, ob diese beschrieben werden sollen. Hier findet sich eine Stärke von Open-Source-Systemen – da für diese niemand Geld zahlt, ist es üblich, z.B. bei Modulen ausführlich zu warnen, wenn bestimmte Einschränkungen vorhanden sind. Bei Kaufsoftware dagegen, die zumindest scheinbar einen stabilen, geprüften, fehlerfreien Stand liefern soll, werden Bugs lieber nicht erwähnt, wenn es sich vermeiden lässt…

Share

Nur technische Redakteure…

 Dokumentation  Kommentare deaktiviert für Nur technische Redakteure…
Apr 052009
 

…können sich ausgiebig Gedanken darüber machen, wie man am besten Smilies in Klammern schreibt:
Emoticons and Parentheses.

Share

Der perfekte Doku-Dilbert

 Dokumentation  Kommentare deaktiviert für Der perfekte Doku-Dilbert
Mrz 162009
 

Dilbert.com

Share
© 2012 Doku-Hotline Suffusion theme by Sayontan Sinha