Was ist SAP Fiori?

 Sammelsurium  Kommentare deaktiviert für Was ist SAP Fiori?
Mrz 312016
 

SAP Fiori ist eine Möglichkeit, auf SAP aufsetzende Apps zu entwickeln, mit deren Hilfe sich definieret Prozesse in SAP durchführen lassen. Diese Prozesse müssen im SAP-Backend korrekt funktionieren, die Fiori-App setzt auf dem Backend auf. Es wird SAP HANA als Grundlage empfohlen.

In der Ausgabe basiert Fiori auf OpenUI5, einer von SAP mit-unterstützten Open-Source-JavaScript-Bibliothek.

Unter dem Link können Sie eine Fiori-Ausgabe sehen:
https://www.sapfioritrial.com/

Schöner Einführungsartikel zum Thema:
https://www.linkedin.com/pulse/20140608082721-29503826-sap-fiori-implementation-starter-guidlines

Die Dokumentation zu drei Standard-Apps finden Sie hier:
http://scn.sap.com/community/fiori/blog/2015/03/31/fiori-reference-apps-technical-documents

Eine ausführliche Anleitung zur Erweiterung der Standard-App gibt es hier:
https://de.scribd.com/doc/294681429/4/Technical-Background

Wie zu sehen, benötigt SAP Fiori sowohl Kenntnisse in SAP als auch in GUI-Design.
Nach einigen schmerzhaften Erfahrungen in großen Firmen kann ich nur hoffen, dass heutzutage auch fähige UX-Designer für die Apps genutzt werden – und nicht nur Junior-SAP-Berater ;)

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.

Neu im Netz – mein OfficeHours-Profil

 Business  Kommentare deaktiviert für Neu im Netz – mein OfficeHours-Profil
Mrz 232016
 

Jetzt können Sie 10-Minuten-Kurzsitzungen mit mir ganz einfach buchen / see here for 10 min online meetings with me:

https://officehours.io/people/bcgrossmann

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. 

© 2012 Doku-Hotline Suffusion theme by Sayontan Sinha