September 2017

2 einfache Tipps, um beeindruckende E-Mails zu schreiben.

Kommunikation, Kommunikation, Kommunikation … man kann es nicht oft genug wiederholen – Kommunikation ist das wichtigste Thema im Berufsleben eines SAP-Beraters. Egal ob man sich mit dem Kunden oder einem Kollegen über eine Fehlersituation unterhält, ein hunderte Seiten langes Konzept zur Preisfindung verfasst oder einen neuen Prozess vor der GF vorstellt, auf jeder erdenklichen Ebene findet Kommunikation statt. Und wenn man die Grundzüge der unterschiedlichen Kommunikationskanäle nicht beherrscht, wird man es … um es auf den Punkt zu bringen … als SAP-Berater nicht weit bringen .

Im Rahmen der schriftlichen Kommunikation ist für SAP-Berater das E-Mail das wichtigste Kommunikationsmedium. Es nimmt in der täglichen Arbeit einen nicht unerheblichen Stellenwert ein, und dem entsprechend sollte man sich als SAP-Berater über die Grundzüge des effektiven E-Mail-Schreibens klar sein.

Seit dem vor ca. 30 Jahren das E-Mail seinen Siegeszug im Berufsleben angetreten hat, sind schon Unmengen an guten oder weniger guten Tipps, Ratgebern und Büchern zu diesem Thema erschienen – wenn man in Google nach „Tipps zum Mail schreiben“ sucht, bekommt man über 8 Mio. Treffer, und eine Suche in Amazon-Bücher bringt immerhin über 120 Treffer.

Neben Grundlagen des E-Mail-Schreibens, wie kurze Sätze, Rechtschreibung, wenig Fremdwörter, etc. sind aus meiner Erfahrung zwei Punkte sehr wichtig, um effektive E-Mails zu schreiben:

# Gliederung / Formatierung
# Betreffzeile mit Aktionshinweis

Gliederung und Formatierung beim E-Mail schreiben

Vielfach bekommt man Mails, die aus monolithischen Textblöcken bestehen, wenig strukturiert sind und optisch wie dahin geknallt aussehen – und man denkt sich „… um was geht es hier?“ Hier wäre ein strukturierter Text optisch ansprechender und damit für den Empfänger viel besser zu lesen. Im Folgenden will ich das Thema mal anhand eines konkreten Beispiels darstellen.

Der monolithische Text

Immer wieder erhalte ich solche Mails, wo Unmengen Text zusammenhängend in einem Schwall zusammen geschrieben wurde. Der Text an sich mag gut formuliert und leicht zu lesen sein, doch der erste Eindruck schreckt meistens sofort ab. So viel Text und man weiß nicht, wo es beginnt und wo es enden will – bitte nicht solche Mails schreiben.

Der Text mit Absätzen

Dieser Text ist schon viel besser; es sind mehrere Absätze enthalten, die den Text in logische Blöcke teilen und den User führen – bitte wenigstens Absätze nutzen.

Der gegliederte Text

In dieser Mail sind nun die einzelnen Absätze nochmal in einzelne kleine Blöcke unterteilt, so dass der Leser sofort sieht, welche einzelnen Punkte angesprochen sind – aber das ist noch nicht die optimale Mail.

Der strukturierte Text

So … diese Mail unterscheidet sich im Text nicht wesentlich von der vorherigen bzw. der ersten Version, aber durch die Verwendung von Formatierungsfunktionen, wie Aufzählungspunkte, Einschübe, Fette und unterstrichene Überschriften, ist die Mail optimal gegliedert und strukturiert. Im Vergleich zur ersten Version der Mail gibt es himmelweite Unterschiede und vor allem wird der Leser die Informationen, die man vermitteln will, sehr einfach aufnehmen.

Betreffzeile mit Aktionshinweis

Die Betreffzeile ist meistens das wichtigste Element einer Mail. Sie ist der erste Eindruck, den der Leser bekommt. Wie sonst im Leben ist, ist auch bei einer Mail der erste Eindruck nun mal sehr wichtig. Aber ich will an dieser Stelle nicht darauf eingehen, wie man beeindruckende Betreffzeilen schreibt, sondern nur auf folgenden Umstand hinweisen: Schreibt in die Betreffzeile immer auch einen Aktionshinweis; das wird dir helfen, schneller Feedback auf deine Mails zu bekommen. D.h. wenn du direkt reinschreibst, dass du eine Antwort brauchst, oder dass du eine Bestätigung erwartest, dann wirst du die Antwort um den Faktor 2-3 schneller bekommen – im Folgenden einige Beispiele:

#Statt: „Protokoll der Logistik-Sitzung von KW34“

#Besser: „Protokoll der Logistik-Sitzung von KW34 – bitte Kommentare und Korrekturen bis 01. Sep. 2017 melden“

#Statt: „Hier der neue Support-Plan für den Standort Lüdenscheid“

#Besser: „Zur Info: Hier der neue Support-Plan für den Standort Lüdenscheid“

#Statt: „Die aktualisierte To-Do-Liste liegt auf dem Projektserver“

#Besser: „Die aktualisierte To-Do-Liste liegt auf dem Projektserver – neue offene Punkte direkt in diese Liste erfassen“

#Statt: „Bestellung 4500023231 vom 23.09.2017“

#Besser: „Bestellung 4500023231 vom 23.09.2017 – bitte Nachrichtenfindung im Beleg kontrollieren.“

#Statt: „Fehlerhafte Aufträge von Kunden Wortmann“

#Besser: „Fehler in den Wortmann-Aufträgen analysieren und Ursache an den Vertrieb melden“

Wie immer wäre es super, wenn ihr ein kleines Feedback hinterlassen könntet, Isa.

SAP HANA Wissen, das deine Kunden in den Bann zieht.

Leider hatte ich bis jetzt nicht die Gelegenheit in einem Projekt mitzuwirken, in dem die neue SAP HANA Datenbank zum Einsatz kam – was noch nicht ist, kann ja noch werden. Aber durch Fachbeiträge und eine Vertriebspräsentation der SAP konnte ich einiges zum Thema erfahren. Vor allem während der Präsentation sind mir 2 Punkte hängen geblieben, die kennzeichnend für die SAP HANA DB sind:

#1 SAP HANA basiert auf In-Memory-Technologie
#2 HANA verwaltet / speichert die Daten spaltenbasiert

Der Vorteil des ersten Punktes ist schnell erklärt: Seit dem ich meinen ersten Computer mit 12 Jahren bekommen hatte (Commodore 64) konnte ich am eigenen Leib erfahren, dass der Arbeitsspeicher eines Rechners viel schneller arbeitet, als die Festplatte – damals die ratternde Datasette. Und genau diesen Geschwindigkeitsvorteil nutzt die SAP HANA DB und hält die Daten nicht mehr auf der Festplatte, sondern alle Daten liegen direkt im Arbeitsspeicher – BIG SPEEDY BRAIN! Damit ist HANA in Bezug auf Geschwindigkeit unschlagbar verglichen mit konventionellen DBs, die die Daten auf der Festplatte speichern. Aber dieser Vorteil wird mit höheren Kosten erkauft, denn auch dies ist Allgemeinwissen: Arbeitsspeicher ist teuer als Festplattenspeicher.

Das zweite Charakteristikum der SAP HANA DB ist, dass die Daten spaltenorientiert verwaltet bzw. gespeichert werden. „… Und was bedeutet das?“ Während des Vertriebsvortrags durch die SAP-Mitarbeiter stellte ich genau diese Frage, doch ich bekam damals keine zufriedenstellende Antwort. Also habe ich zu diesem Thema etwas recherchiert und die Antworten, die ich fand und im Folgenden mit euch teilen will, waren wirklich interessant.

# Was bedeutet spaltenorientiert Datenverwaltung / -speicherung?

Im oberen Bild ist eine kleine Tabelle mit 5 Autos dargestellt, die anhand 6 unterschiedlicher Kriterien beschrieben sind:

# Nr.
# Hersteller
# Modell
# Leistung in PS
# Verbrauch
# Einheit Verbrauch

Normalerweise, also bei der zeilenorientierten DB, wird die Tabelle wie folgt gespeichert:

1,Audi,A3, 140,6.7,l/100km;
2,Audi,A4, 140,6.9,l/100km;
3,VW,Polo,90,5.5,l/100km;
4,VW,Golf,110,5.7,l/100km;
5,Mazda,CX-3,110,7.2,l/100km;

Wenn man sich vorstellt, wie die Daten tatsächlich physisch gespeichert werden, sieht es ungefähr so aus:

1,Audi,A3,140,6.7,l/100km;2,Audi,A4,140,6.9,l/100km;3,VW,Polo,90,5.5,l/100km;4,VW,Golf,110,5.7,l/100km;5,Mazda,CX-3,110,7.2,l/100km;

Wenn die Daten aber – wie bei der SAP HANA DB – spaltenorientiert gespeichert werden, sieht das so aus, d.h. jeder Satz ist ein Spalte, Spalte-Nr., Spalte-Hersteller, …:

1,2,3,4,5;
Audi,Audi,VW,VW,Mazda;
A3,A4,Polo,Golf,CX-3;
140,140,90,110,110
6.7,6.9,5.4,5.7,7.2;
l/100km, l/100km, l/100km, l/100km, l/100km;

Vor- und Nachteile einer Spaltenorientierten DB

Das spaltenorientierte Speichern und Verwalten von Daten sieht zunächst gewöhnungsbedürftig aus, hat aber auch seine Vorteile. Im Folgenden will ich anhand von drei Fragenstellungen die Vorzüge der SAP HANA DB darstellen:

Wie viel VW-Fahrzeuge sind in der Liste?
Bei der zeilenorientierten DB müsste mal alle Zeilen auslesen und hieraus selektieren, welche Sätze Hersteller = VW sind; d.h. man muss zwingend alle Sätze durchgehen. Im Gegensatz dazu würde HANA „nur“ in den einen Satz für die Hersteller-Spalte schauen und die VW-Fahrzeuge aus diesem einen Satz ermitteln, d.h. statt 5 Zugriffe ein einziger Zugriff.

Wie viele Autos gibt es mit über 120 PS?
Auch hier müsste man nur in den Satz für „Leistung in PS“ schauen, und die Anzahl der Werte mit größer 120 ermitteln.

Wie viel verbrauchen die Fahrzeuge im Schnitt?
Wieder müsste man nur den Satz für die Spalte „Verbrauch“ lesen und den Mittelwert ermitteln. Im Gegensatz dazu müssten bei einer konventionellen DB alle Sätze gelesen werden.

Also wenn es um Analyse von Daten geht, ist HANA durch das Design unschlagbar gegenüber konventioneller DBs. Natürlich hat das HANA-Design nicht nur Vorteile. Stell dir vor, du willst in die Tabelle ein neues Fahrzeug aufnehmen. Dann muss jeder Satz aktualisiert werden, d.h. der Satz für die erste Spalte, die zweite Spalte, die dritte Spalte … muss aktualisiert werden. Auch bei Änderung oder Anzeige eines Fahrzeugs müssten, statt eines Satz, viele sogar alle Sätze gelesen werden.

So bis jetzt kann man also fest halten:

# Wenn Daten analysiert werden sollen, dann ist HANA durch das zusammenhängende Speichern von Kennzahlen (Spalten) in einem Satz unschlagbar schnell.

# Doch wenn Daten erfasst, geändert und angezeigt werden sollen, ist HANA nicht die optimale Lösung, da hier unter Umständen auf unterschiedliche Sätze zugegriffen werden muss.

Doch das spaltenbasierte Design der SAP HANA DB bietet einen zusätzlichen Vorteil, der Im-Memory-Technologie in die Hände spielt. Wenn man sich die Fahrzeugdaten in der HANA-Version nochmal genauer anschaut, fällt vor allem in der letzten Zeile, die Spalte, die „Einheit Verbrauch“ darstellt, etwas Wichtiges auf:

1,2,3,4,5;
Audi,Audi,VW,VW,Mazda;
A3,A4,Polo,Golf,CX-3;
140,140,90,110,110
6.7,6.9,5.4,5.7,7.2;
l/100km, l/100km, l/100km, l/100km, l/100km;

Habt ihr erkannt, was auffällig ist? Ja genau, die Werte wiederholen sich. Diesen Umstand nutzt HANA, um die Daten zu komprimieren, d.h. sich wiederholende Werte innerhalb eines Satzes werden einfach zusammengefasst. Das sieht dann etwa so aus:

1,2,3,4,5;
2:Audi,2:VW,Mazda;
A3,A4,Polo,Golf,CX-3;
2:140,90,2:110
6.7,6.9,5.4,5.7,7.2;
5:l/100km;

Die Komprimierung ist in Grunde sehr einfach: Wenn sich innerhalb einer Zeile ein Wert wiederholt, wird die Anzahl der Wiederholungen mit einem Doppelpunkt vor dem Wert dargestellt. Damit sind alle Daten immer noch verfügbar, aber der Speicherbedarf der DB ist viel kleiner. Hier habe ich mal von einem Faktor von 4-10 gelesen, den die Komprimierung einspart. D.h. für die In-Memory-Technologie von SAP HANA werden bspw. statt 10 TB nur 1 – 2,5 TB benötigt. Und das ist ein zusätzlicher Boost für die In-Memory-Technologie bezogen auf den Preis und die Geschwindigkeit.

Hoffe, ich konnte euch essentielle Aspekte der SAP HANA DB nahe bringen … wie immer wäre es toll, wenn du ein kleines Feedback hinterlassen könntest, Isa.

SD-Auftragsart: Diese 12 Aspekte solltest du kennen.

Der SD-Auftragsart ist für User wesentlich, wenn ein Auftrag im SAP ERP System angelegt werden soll. Normalerweise wird eine SD-Auftrag mit dem Transaktionscode VA01 angelegt, und das erste was das System innerhalb dieser Transaktion erwartet ist die Auftragsart. Hier muss der User entscheiden, ob ein normaler Terminauftrag (TA), ein Retourenauftrag (RE), eine Gutschrift (G2) oder eine Lastschrift (L2) angelegt werden soll. Mit Eingabe der Auftragsart wird bei der Auftragserfassung eine Reihe von Funktionen gesteuert, die je Auftragsart unterschiedlich sein können.

Im Folgenden habe ich 12 Punkte aufgeführt, die von der Auftragsart gesteuert werden. Natürlich sind das nicht alle Aspekte, die die Auftragsart beinhaltet, aber nach meiner Erfahrung sind diese Punkte, die Features der Auftragsart, die am meisten zum Einsatz kommen.

#1 Nummernkreis

Jeder Auftrag hat eine konkrete Nummer – bspw. 20003090. Diese Nummer wird beim Anlegen des Auftrags generiert und kann aus bis zu 10 alphanumerischen Zeichen besteht. Pro Auftragsart wird festgelegt, in welchem Nummernkreis die zu vergebende Nummer liegen soll. Bspw. können Terminaufträge im Nummernkreis 20000000 – 29999999 liegen und Retouren Aufträge im Nummernkreis 600000 – 699999.

#2 Sofortbelieferung

80% der Aufträge innerhalb des Vertriebsmoduls werden als Terminaufträge (TA) angelegt. Ein Terminauftrag zeichnet sich dadurch aus, dass basierend auf der Verfügbarkeit der Ware oder dem Wunsch des Kunden, der Liefertermin in der Zukunft liegt. Damit wird die Lieferung zum Auftrag erst dann angelegt, wenn das Liefererstellungsdatum erreicht wurde. Es gibt aber auch Prozesse (bspw. Tresengeschäfte), bei denen die Terminierung keine Rolle spielt und der Kunde die Ware sofort mitnehmen will. Hier ist es sinnvoll, dass die Lieferung zum Auftrag direkt erzeugt wird, damit die Ware sofort kommissioniert und an den Kunden übergeben werden kann. Für diese Arten von Aufträgen kann eingestellt werden, dass eine Sofortbelieferung erfolgen soll, d.h. mit dem Sichern des Auftrags wird sofort die Lieferung generiert.

#3 Bildaufbau / -folge

Prinzipiell sehen SD-Aufträge in ihrem Aufbau und der Struktur relativ identisch aus; doch im Detail kann pro Auftragsart ein unterschiedlicher Bildaufbau ausgesteuert werden. Bspw. haben Terminaufträge (TA) pro Position den Reiter „Einteilungen“, in dem die Terminierungsdaten dargestellt sind. Dieser Reiter ist für Lastschriftaufträge (L2) nicht vorgesehen, da bei diesen Aufträgen keine Warenbewegung und damit Terminierung vorgesehen ist.

#4 Unvollständigkeit

Auch das Thema Unvollständigkeitsprüfung für Kopfdaten wird pro Auftragsart ausgesteuert. Hier kann pro Auftragsart eingestellt werden, welche Felder im Unvollständigkeitsschema zu prüfen sind.

#5 Versandbedingung

Die Versandbedingung steuert im Auftrag unter anderem die Versandstellenfindung und Routenfindung. Pro Auftragsart kann eine Versandbedingung zugeordnet werden, die bei der Auftragsanlage als Vorschlagswert im Auftragskopf steht. Dieser Vorschlagswert kann durch den User überschrieben werden.

#6 Kalkulationsschema

Die Auftragsart steuert auch maßgeblich die Preisfindung des Auftrags. Konkret wird über die Auftragsart das Kalkulationsschema ermittelt, die die Details der Preisfindung vorgibt.

#7 Terminierung

Im Customizing kann pro Auftragsart eingestellt werden, ob für eine bestimmte Auftragsart die Versandterminierung aktiviert ist oder nicht. Weiterhin kann an dieser Stelle auch separat ausgesteuert werden, ob eine Transportterminierung durchgeführt werden soll.

#8 Nachrichtenschema

Über die Auftragsart wird auch die Ermittlung des Nachrichtenschemas gesteuert. Somit können unterschiedlichen Aufträgen verschiedene mögliche Nachrichten zugeordnet werden.

#9 Materialsubstitution

Die Materialsubstitution kann genutzt werden, wenn Material, die bei der Auftragserfassung eingegeben werden, durch ein anderes Material ersetzt werden sollen. Sinnvoll ist diese Funktion bspw. beim Abverkauf von Saisonware. Die Materialersetzung wird auch pro Auftragsart eingestellt.

#10 Produktvorschlag

Mit der Funktion Produktvorschlag erhält der User bei der Auftragserfassung eine Liste von Materialien vorgeschlagen, die für diesen Auftrag relevant sein könnten – nach dem Motto: „Auch diese Produkte könnten Sie interessieren.“ Diese Funktion wird unter anderem auch pro Auftragsart aktiviert.

#11 Kreditlimitprüfung

Per Kreditlimit kann bei der Auftragserfassung gesteuert werden, ob ein Auftrag wegen Kreditlimitprüfung (hat der Kunde schon wieder die letzte Rechnung nicht gezahlt?) gesperrt wird oder nicht. Auch diese Prüfung kann pro Auftragsart eingestellt werden.

#12 Kopiersteuerung

Last but not least, wird über die Auftragsart die komplette Kopiersteuerung der SAP-SD-Belegkette (Auftrag-Lieferung-Faktura) gesteuert. Die Kopiersteuerung legt fest, aus welchen Auftragsarten welche Lieferarten generiert werden können, oder ob basierend auf einem Auftrag eine Faktura erstellt werden kann.

Wäre super, wenn du ein kleines Feedback hinterlassen würdest, Isa.

# Gliederung / Formatierung # Betreffzeile mit Aktionshinweis