Autor: Isa

Um es vorabzusagen: Nein, VMI kann man nicht essen, aber VMI kann viel mit Essen zu tun haben – hierzu aber später mehr. Sagen euch die Begriffe ECR oder VMI etwas? Nein? Diese Abkürzungen haben zunächst nichts direkt mit SAP zu tun, aber viel Logistik. VMI steht für Vendor-Managed-Inventory und die Abkürzung ECR bedeutet Efficient-Customer-Response. Beide Konzepte haben zum Ziel Logitikkosten in Rahmen des SCM zu optimieren und den Servicegrad der Logitik zu steigern. Wikipedia definiert die Begriffe wie folgt:

ECR aus Wikipedia: Der Begriff Efficient Consumer-Response (auch ECR-Konzept oder Effiziente Konsumentenresonanz) bezeichnet eine Initiative zur Zusammenarbeit zwischen Herstellern und Händlern, die auf Kostenreduktion und bessere Befriedigung von Konsumentenbedürfnissen abzielt. Dabei wird die Wertschöpfungskette, von der Produktion bis hin zur Kaufentscheidung der Verbraucher, auf Optimierungspotenziale untersucht.

VMI aus Wikipedia: Beim VMI übernimmt der Lieferant die Verantwortung für die Bestände seiner Produkte beim Kunden. Der Bestand beim Kunden wird vollständig vom Lieferanten veranlasst. Häufig wird dem Kunden im Gegenzug das volle Retourenrecht eingeräumt. Grundlage für die Berechnung der Lieferungen sind z. B. Verbrauchs- oder Abverkaufszahlen, die entweder bei der regelmäßigen Aufstockung durch den Lieferanten erfasst, oder auch elektronisch übermittelt werden können.

Das Konzept VMI in Verbindung mit ECR habe ich im Rahmen eines Projektes kennengelernt. Dabei war das Prinzip recht simpel und sah wie folgt aus:

# Einmal am Tag übermittelte der Kunden dem Lieferanten einen Datensatz. Diese Daten waren in Grunde eine Liste der Materialien, die am VMI teilnahmen und hatten folgende Informationen:

## Materialnummer
## Aktueller Bestand
## Mindestbestand

# Beim Lieferanten wurde die Liste analysiert und basierend auf den Analyseergebnissen entweder automatisch ein Kundenauftrag angelegt und die Ware beliefert oder es erfolgte keine Reaktion.

Leider muss ich an dieser Stelle sagen, dass dieser Prozess nicht mit den Standard Möglichkeiten in SAP umsetzbar ist. Das Unternehmen, für das ich gearbeitet hatte, nutzte zur Umsetzung dieses Szenarios ein AddOn.

Ultra-VMI in Istanbul

Während eines Istanbul-Besuchs kam ich erneut mit dem VMI Konzept in Kontakt, wobei es dieses Mal komplett anders umgesetzt war. Ich saß mit meiner Frau in einem Restaurant am Bosporus und wie in der Türkei üblich, wurde uns ein junges Paar an den Tisch gesetzt, da die übrigen Tische besetzt waren. Nach kurzer Zeit – wir waren dabei die Vorspeisen zu schlemmen – kamen wir mit dem Paar ins Gespräch; sie stellten sich als Merve und Rokan vor. Meine Frau und Merve hatten sich schon in die Details der türkischen Küche vertieft und Rokan und ich redeten über das Berufsleben.
Ich fragte Rokan, was er beruflich machte. Er sagte mir, dass er Bäcker sei. Als ich Bäcker hörte, kamen vor meinem geistigen Auge die tollsten Assoziationen hoch. Ich stellte mir vor, wie er am Tresen in einem der vielen Istanbuler Traditionsbäckerei seine Leckereien feilbot; doch so war es nicht. Er hatte eine kleine Industriebäckerei von seinem Vater übernommen und bediente im Grunde nur einen Kunden: Die historischen Fischerboote am Eminönü-Platz. An diesen Fischerbooten, die zu jeder Tageszeit mit Kundschaft überlaufen sind, bekommt man frischgegrillten Fisch als Sandwich serviert; und Rokans Bäckerei belieferte diese Fischerboote mit den Sandwich-Broten.
Rokan war ein zurückhaltender junger Mann von ungefähr 25 Jahren und ich fragte ihn, ob der Bäckerberuf schwierig war. Der verneinte meine Frage und sagte mir, die Schwierigkeit an seinem Job sei es, die Bestellungen der Fischer zu erfüllen. Ich stutzte zunächst und sagte nur, brauchst du mehr Mitarbeiter oder eine größere Bäckerei. Er sagte mir, nein das sei nicht das Problem. Die Herausforderung für ihn war, immer die exakte Menge an Brot zu beliefern, die Fischerboote an diesem Tag benötigten. Doch ich verstand immer noch nicht und fragte nach: „Die Fischerboote bestellen 10.000 Brote. Du backst sie und lieferst die aus. Was war so schwer daran, wenn du keine Kapazitätsprobleme hast?“ Rokan merkte, dass ich ihn immer noch nicht verstand und löste das Thema wie folgt auf: „Die Fischerboote wollen täglich von mir beliefert werden und wollen keinerlei Engpässe in der Brotbelieferung haben. Aber sie sagen mir nicht, wie viele Brote sie heute brauchen werden. Das ist meine Aufgabe. Gemäß meinen Erfahrungen, dem Wetterbericht, der Veranstaltungssituation in der Stadt und vieler weiterer Faktoren muss ich einschätzen, welche Menge Brot morgen benötigt wird und muss sie bereitstellen.“

Als ich es endlich verstanden hatte, dachte ich mir nur: Wow, das ist Ultra-VMI in Istanbul. Der Lieferant – hier Rokans Bäckerei – war völlig in der Verantwortung für die Bedarfserfüllung des Kunden.

 

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

Tom hielt in geübter Haltung das 1er Holz in den Händen und spürte auf seinen Unterarmen die leichte Brise, die aus südwestlicher Richtung über den hügeligen Platz wehte. Er konzentrierte sich auf den bevorstehenden Schlag, den er schon tausende Male ausgeführt hatte. Er musste an diesem Loch 3 unter Par liegen, wenn er gegen Jacques noch eine Chance haben wollte. In einer harmonischen Bewegung schwang er den Driver zunächst zurück und traf dann im Vorwärtsschwung den Golfball satt in Richtung des 18. Lochs. Als Tom der Flugbahn seines Balls nachschaute, dachte er sich nur: „Nein, die Partie ist verloren.“ Der Schlag war vollkommen verzogen und der Ball landete weit weg vom Grün.

Tom und Jacques trafen sich seit einem Jahrzehnt regelmäßig auf dem „The Royal Golf Club of Belgium“ südlich von Brüssel. Was zunächst als informelles Geschäftsmeeting begann, hatte sich über die Jahre zu einem regelmäßigen Ritual zwischen den beiden Männern etabliert. Hier konnten beide einmal im Jahr einige Tage Auszeit vom hektischen Tagesgeschäft nehmen und strategische Entwicklungen ihrer Unternehmen diskutieren. Toms und Jacques‘ Unternehmen hatten über die Zeit ein enges Verhältnis entwickelt. Tom war mit Abstand der größte und wichtigste Lieferant für Jacques‘ Unternehmen und im Gegenzug machte Tom einen nicht unerheblichen Anteil seines Umsatzes mit Jacques.

Nachdem Jacques im 18.Loch eingelocht hatte und wie abzusehen war, die Partie für sich entscheiden konnte, machten sich die beiden Männer auf den Rückweg zum Clubhaus. Hier würden sie gemeinsam den Abend ausklingen lassen, um am nächsten Morgen frühzeitig abzureisen. Tom wusste, dass er mit Jacques am Abend noch eine volle Agenda vor sich hatte. So erinnerte er sich an den „elektronischer Bestelleingang“, den ihn Hr. Philippsburg von der Orga-Abteilung mitgegeben hatte. Hr. Philippsburg hatte ihn gebeten, Jacques darauf anzusprechen, ob es für Jacques‘ Unternehmen möglich sei, die Bestellung auf elektronischem Wege zu übermitteln. Der Rückweg zum Clubhaus und die Hochstimmung Jacques‘ wäre ein gute Gelegenheit, um dieses Thema anzusprechen.

    „Über die Jahre ist die Auftragsabwicklung immer komplexer geworden“, fing Tom an und fuhr fort: „Habt ihr bei euch auch den Effekt, dass dieser Posten zu einem großen Kostenfaktor geworden ist?“

    „Ja, du hast recht; die gesetzlichen Regularien erfordern einen immer höheren  Dokumentationszwang“, erwidert Jacques.

    „Unsere Orga hat zu diesem Thema einen Ansatz“, sagte Tom. „Sie bittet euch, eure Bestellungen uns auf elektronischem Weg zu übermitteln. Meinst du, das ist machbar?“

    Jacques überlegte kurz und antwortete dann: „Ich denke das sollte kein Thema sein. Soweit ich mich erinnere, liegen unsere Bestellungen in einer übersichtlichen Excel-Datei vor. Es sollte möglich sein diese Datei auf eine Diskette zu ziehen und euch einmal die Woche per Post zuschicken.“

 

Excel – Diskette – Post? Nein das ist bestimmt nicht State-of-the-Art, für den elektronischen Datenaustausch im Geschäftsverkehr. Heutzutage werden die Mehrzahl der Geschäftstransaktionen elektronisch ausgetauscht; und es ist das strategische Ziel vieler Unternehmen diesen Wert nahe an die 100% zu bringen. Der Austausch von Daten per Diskette, den es vielfach tatsächlich gab, sollte heutzutage kein Thema mehr sein.

Aktuell verläuft der elektronische Datenaustausch nach folgendem Prinzip ab:

# Aus dem ERP-System des sendenden Partners wird ein Datensatz generiert und an das Konverter-System übergeben

## Bestellung wird als ORDERS01-IDoc an den Konverter übergeben

# Der Konverter übernimmt die Daten und konvertiert sie in ein abgestimmtes Format und leitet die Daten an den Empfänger weiter

## ORDERS01-IDoc wird in das EDIFACT-Format ORDERS konvertiert

# Der Empfänger übernimmt die Daten in seinem Konverter-System und wandelt die Daten in ein Format um, dass das ERP-System verarbeiten kann

## EDIFACT-Format wird in ein ORDERS01-IDoc konvertiert

# Das empfangende ERP-System übernimmt die Daten verarbeitet sie anschließend.

## Mit der Verarbeitung des ORDERS01-IDocs wird ein Kundenauftrag angelegt

 

Für einen erfahrenen SAP-Berater erzähl ich hier natürlich nichts Neues. Egal in welchem Bereich man arbeitet, ob Finanzen, Controlling, Vertrieb, Einkauf, Produktion oder Qualitätsmanagement in allen Themengebieten werden elektronisch Daten ausgetauscht. Damit sollte jeder SAP-Berater mehr oder weniger mit IDocs in Verbindung gekommen sein. An dieser Stelle will ich ein paar Tricks vorstellen, die ich über die Jahre im Umgang mit IDocs gesammelt habe. Bei dieser Auflistung gehe ich davon aus, dass ihr prinzipiell IDocs kennt, d.h. die allgemeinen Zusammenhänge, wie Partnervereinbarung, Nachrichtenfindung, WE02, BD87 setze ich voraus.

 

1. IDoc-Daten verändern (WE02 / WE19)

Egal ob man ein Test-IDoc anpassen will, oder sogar im Produktivsystem ein IDoc anpassen muss, gibt es prinzipiell 2 Möglichkeiten:

# Die Daten eines IDocs direkt verändern

# Oder ein bestehendes IDoc verändern und eine Kopie des IDocs erstellen

Bei der ersten Option ruft man das zu verändernde IDoc mit der Transaktion WE02 auf. Anschließend springt man in die Detailebene eines IDoc-Segments, in dem man auf das Blatt-Icon neben dem Segment-Namen doppelklickt, das man ändern will. Von hier aus ruft man den Editiermodus auf, in dem man oben in der Menüleiste „Datensatz“ von Anzeigen auf Ändern wechselt. ZU BEACHTEN: Nur wenn es der aktuelle Status es zulässt, können die Daten eines IDoc-Segments geändert werden. Wenn man das veränderte IDoc erneut verarbeiten will, geht man einfach mit der IDoc-Nummer in die Transaktion BD87.

Bei der zweiten Option ruft man ein bestimmtes IDoc per Transaktion WE19 auf; hierzu muss man vorher die IDoc-Nummer ermittelt haben. Anschließend wird das komplette IDoc mit allen Segmenten und Daten dargestellt. Wenn man nun hier auf ein Segment doppelklickt bzw. Einfach-Klick auf die Daten des Segments durchführt, öffnet sich ein Editierfenster, in dem die Felder des Segments mit Inhalten dargestellt werden. In diesem Fester kann man die Daten verändern und anschließend bestätigen. Nachdem die Daten geändert wurden, wird das IDoc prozessiert: Wenn es sich um ein Eingangs-IDoc  handelt, dann klickt man auf den Button „Standard Eingang“. Wenn das IDoc, das man verändert hat, ein Ausgangs-IDoc ist, dann muss der Button „Standard Ausgang“ betätigt werden. Nachdem man das Zwischenfenster mit Enter bestätigt hat, wird ein neues IDoc erzeugt, das gemäß Partnervereinbarung entweder direkt verarbeitet wird oder auf die Verarbeitung wartet (BD87) – Voila, jetzt hat man eine veränderte Kopie des ursprünglichen IDocs. Der Vorteil dieser Option gegenüber der erst vorgestellten Option (WE02) ist, dass man hier komplette Segment löschen bzw. hinzufügen kann.

 

2. Liste spezielles Segment (WE02)

Stell dir vor, du kommst Montag morgens ins Büro – etwas verschlafen – und die erste Mail, die du liest, kommt von deinem Boss: „Vertriebsinnendienst hat sich gemeldet; übers Wochenende sind keine Kundenaufträge reingekommen, weil die ORDERS-IDocs auf ein Fehler gelaufen sind, bitte bis 9 Uhr Liste der betroffenen Kunden mit Mailadresse des Ansprechpartners erstellen und mir zu mailen.“ – du schaust auf die Uhr: 8:45 Uhr!

Du startest die Transaktion WE02 und selektierst alle fehlerhaften ORDERS-IDocs – Ergebnis der Selektion: 9.672 IDocs. Du klickst in ein IDoc rein und siehst, dass der Ansprechpartner des Kunden mit Kontaktdaten in einem bestimmten Segment enthalten ist. Wenn du in jedes IDoc einzeln reinklickst und die Kontaktdaten rauskopierst, dauert es ca. 8 Stunden – du bist geliefert!

Nicht ganz, denn du kennst du Funktion „Liste spezielles Segment“: Nachdem man die Liste der IDocs per WE02 selektiert hat, gibt es in der oberen Menüleiste einen unscheinbaren Button „Liste spezielles Segment“ – das Icon sieht wie ein liniertes Blatt mit Rand aus. Du markierst im linken Bildschirmbereich einen IDoc-typ (in unserem Beispiel ORDERS), dann klickst du den oben erwähnten Button. Jetzt gibst du das Segment an, dessen Inhalte per Liste dargestellt werden soll – in unserem Beispiel das Segment, in dem die Kontaktdaten der Kunden stehen. Jetzt hast du alle Kontaktdaten der betroffenen Kunden als Liste vorliegen. Du lädst die Liste in Excel, bereinigst die doppelten Einträge und sendest sie an deinen Boss – es ist 8:54 Uhr.

 

3. Übersicht alle Daten eines IDocs (WE02 / WE19)

Du kennst bestimmt auch die Situation: Du sitzt vor dem Rechner und analysierst ein fehlerhaftes IDoc. Die Fehlermeldung des IDoc ist kryptisch und nicht wirklich hilfreich; zusätzlich kommt hinzu, dass das fehlerhafte IDoc aus hunderten von Segmenten besteht, d.h. du müsstest in jedes einzelne Segment reinklicken, um einen Überblick zu bekommen, ob du an den Inhalt oder der Struktur etwas fehlerhaftes erkennen kannst. Hier gibt es 2 hilfreiche Wege, mit denen man einen guten Überblick über das gesamte IDoc und dessen Daten bekommt:

# In der Transaktion WE02 das IDoc anzeigen lassen und in der oberen Menüleiste  auf IDoc -> Drucken IDoc gehen. Nun wird der komplette Inhalt des IDocs mit den einzelnen Segmenten und Feldern in einer Liste dargestellt.

# Die zweite Möglichkeit, die ich persönlich übersichtlicher finde, ist die Transaktion WE19. Hier gibst du die IDoc-Nummer eines bestimmten IDocs vor und startest die Transaktion. Anschließend werden alle Segmente des IDocs  (in ihrer jeweiligen Hierarchie) mit Inhalten dargestellt.

 

4. Leere Segment- Felder eines IDocs anzeigen (WE02)

Die Segmente eines IDocs bestehen aus unterschiedlichen Feldern, die per Offset definiert sind – dies kann man sich im Detail per WE30 anschauen. Wenn man sich nun mit der WE02 ein konkretes IDoc anzeigen lässt, gelangt man mit Doppelklick auf das Blatt-Icon links neben dem Segmentnamen zur Anzeige der einzelnen Felder dieses Segments – SAP nennt diesen Bereich „Anzeige eines Datensatzes des IDocs“. Wenn nun einzelne Felder dieses Segments nicht gefüllt sind bzw. keinen Wert enthalten, dann werden im Anzeige-Modus diese leeren Felder nicht dargestellt. Will man sich auch die leeren Felder anzeigen lassen, muss man über die Menüleiste zu „Datensatz -> Anzeigen -> Ändern“ wechseln – nun werden auch die leeren Felder dargestellt.

 

5. Dokumentation der IDocs (WE60)

Gerade wenn man zum ersten Mal ein IDoc einsetzen / nutzen will, finde ich folgende Transaktion sehr hilfreich: WE60 – Dokumentation für IDoc-Typen. Wie der Name schon sagt, kann man sich mit dieser Transaktion  für alle IDoc-Typen eine sehr ausführliche, sowohl technische als auch betriebswirtschaftliche Dokumentation anzeigen lassen.

Bei der WE60 ist folgende (etwas versteckte) Option besonders hervorzuheben: Nachdem man die WE60 aufgerufen hat, kann man über die Menüleiste „Springen -> Benutzereinstellungen …“ zu den Benutzereinstellungen IDoc-Dokumentation wechseln. Hier kann man für seinen User – nachdem man in den Änderungsmodus gewechselt ist – die beiden Option „Ausgabe der Dokumentation“ und „Ausgabe der Feldwerte“ aktivieren und die Einstellungen speichern. Wenn man nun zurückgeht und sich die Dokumentation zu einem IDoc anzeigen lässt, dann werden auch betriebswirtschaftliche Informationen und Feldwerte zu den einzelnen Feldern mit Beschreibung dargestellt.

 

6. IDocs nach Inhalten suchen (WE09)

Stell Dir vor, du arbeitest in einem Pharma-Unternehmen und ein kleiner GAU ist aufgetreten: Eine Produktionscharge ist verunreinigt. Nun willst du dir einen Überblick verschaffen, wo überall die Charge verwendet wurde – natürlich bietet SAP umfangreiche Funktionen, um die Verwendung einer bestimmten Charge zu ermitteln. Aber dich interessiert besonders in welchen IDocs diese verunreinigte Charge genutzt wurde: Rückmeldung von der Produktion, Lieferung zu Kunden, Umlagerung zwischen Werken oder in Speditionsaufträgen. Um diese IDocs zu ermitteln ist die Transaktion WE09 die erste Wahl. Mit dieser Transaktion kann IDoc nach betriebswirtschaftlichen Inhalten suchen. Bezogen zur oben dargestellten Szene würde man die Transaktion WE09 aufrufen und die betroffene Chargennummer in das „nach Wert …“ eintragen und ausführen, nun werden alle IDocs aufgelistet, in denen die gesuchte Charge vorkommt.

 

7. Fehlerhafte IDocs auf erledigt setzen

Es ist Freitag 14:54 Uhr – du hast dich zurückgelehnt, deine Beine ausgestreckt und genießt deinen frischen Cappuccino aus einer großen Tasse. Doch so entspannt wie der Tag ausklingt, hatte der Freitag nicht begonnen. Morgens als du ankamst, gab es mehrere Hiobsbotschaften: Eine davon hieß, dass keine Aufträge mehr erfassbar waren, weil hunderte Materialstamm-Update-IDocs nicht verarbeitet wurden. Nachdem du den Fehler analysiert hattest, hattest du gemeinsam mit dem Lager einen Lösungsweg erarbeitet. Anschließend  wurden vom Lagerverwaltungssystem neue IDocs versandt, die die Materialbestände wieder sauber aufgebaut hatten – dies hatte den ganzen Vormittag in Anspruch genommen und die letzten Stunden hattest du damit verbracht, zu analysieren, ob die Bestände nun korrekt waren – das waren sie. Doch bevor du dich in das wohlverdiente Wochenende verabschieden kannst, steht noch eine abschließende Aufgabe aus.

Die fehlerhaften IDocs, die morgens reingelaufen sind, müssen auf erledigt gesetzt werden. Hier gibt es folgenden Report, der die erste Wahl zum Umsetzen von IDoc-Status ist: RC1_IDOC_SET_STATUS. Diesen Report kann man per SE38 aufrufen. Im Selektionsbild gibt man die IDoc ein, deren Status man umsetzen will. Zusätzlich gibt man den aktuellen Status der IDocs an und den Status auf den die IDocs gesetzt werden sollen. Hier macht es Sinn, fehlerhafte IDocs, die nicht mehr weiter verarbeitet werden sollen, auf den Status „68 – Fehler, keine weitere Bearbeitung“ zu setzen.

 

8. Eingangs-IDocs per Job verarbeiten

In der Partnervereinbarung zu den IDocs (WE20) kann man unter anderem einstellen, dass die IDocs nicht direkt verarbeitet werden. Bspw. kann man Eingangs-IDocs zunächst nicht direkt beim Eingang verarbeiten, sondern paketweise und parallel  per Job.

Der Job  für die Eingangsverarbeitung der IDoc s wird mit dem Report (SE38) RBDAPP01 eingeplant.

 

9. Fehlerhafte IDocs per Job nachverarbeiten

Wie bei der oben beschriebenen Eingangsverarbeitung kann man auch fehlerhafte IDoc per Job nach verarbeiten lassen; hier muss der Report (SE38) RBDMANI2 mit entsprechender Variante als Job eingeplant werden.

 

10. IDoc-Tabelle (EDID4 / EDIDC / EDIDS)

Nicht nur für Entwickler, sondern auch für Berater kann es nützlich sein, die Tabellen zu kennen, in den die IDoc-Daten abgelegt sind. Folgende 3 Tabellen sind im Bereich IDocs essentiell:

# EDID4 – IDoc-Datensätze ab 4.0

In dieser Tabelle sind die Daten (Inhalte) eines bestimmten IDocs abgelegt; dabei wird pro Segment eines IDocs genau ein Satz (Zeile) in dieser Tabelle geschrieben. Die einzelnen Felder innerhalb eines Segments werden in dieser Tabelle nicht strukturiert abgelegt. Die einzelnen Felder können nur per Offset ermittelt werden.

# EDIDC – Kontrollsatz (IDoc)

In der Tabelle EDIDC ist der Kopfsatz eines IDocs abgelegt – pro IDoc wird in dieser Tabelle genau ein Eintrag erzeugt. In der EDIDC werden Daten wie IDoc-Nummer, Erstellungsdatum, IDoc-Typ abgelegt.

# EDIDS – Statussatz (IDoc)

Ein IDoc durchläuft während seines Lebenszyklus mehrere Status: „Erstellt“, „Zur Verarbeitung übergeben“, „Erfolgreich verarbeitet“ oder „Fehlerhaft verarbeitet“. Alle diese Status zu einem IDoc werden in der Tabelle EDID4 je IDoc abgelegt.

 

11. Bereichsmenü – WEDI

Auch wenn ich hier einige Funktion und Transaktion im Bereich IDoc vorstelle, gibt es doch eine große Menge von anderen hilfreichen Funktionen / Transaktionen zur Anzeige, Administration oder Test von IDocs. Zum Thema IDoc hat SAP ein Bereichsmenü spendiert in dem alle wichtigen IDoc-Transaktionen zusammen gefasst sind. In dieses Bereichsmenü gelangst du einfach aus dem Startbild des SAP-GUI mit der Transaktion WEDI.

 

12. Umsetzregel für IDocs

Das Aufsetzen einer neuen IDoc-Kommunikation ist im Grunde innerhalb von Stunden möglich. Doch die große Kunst bei diesem Thema ist es, das Mapping der Daten zwischen den Partnern abzustimmen – d.h. du musst übergreifend abstimmen, welche Daten, in welchem Format, in welchen Feldern enthalten sind. Selten wird man als Berater so viel Glück haben, dass genau die Daten im IDoc enthalten sind, die benötigt werden. Damit das IDoc trotzdem sauber verarbeitet werden kann, wird man an einer Entwicklung nicht drum herum kommen.

Doch vielfach muss es nicht soweit kommen. Hier bietet SAP die Funktion „Datenumsetzung zwischen Sender und Empfänger einstellen“. Mit dieser Funktion können die Inhalte eines IDoc mittels Customizing manipuliert werden:

# Bspw. kann man in ein bestimmtes Feld eines Segments immer eine Konstante eintragen

# Oder abhängig von einer Variable ein Wert in einem Segment setzen

Ich kann hier jedem den Tipp geben: Bevor man anfängt zu entwickeln, sollte man sich unbedingt diese Funktion mal genauer anschauen.

Übrigens: Die Umsetzregeln habe ich im folgenden Beitrag detailliert erklärt: Details zu den Umsetzregeln

 

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

 

P.S.: In den letzten Jahren habe ich mich mit SAP-IDocs in verschiedenen Projekten intensiv beschäftigt, weshalb zu diesem Thema einige Beiträge zusammengekommen sind:

# Die wichtigsten SAP IDoc-Transaktionen: Lass dir diese Liste nicht entgehen.

# SAP-Idoc-Tabellen – erfahrene Berater kennen diese Tabellen.

# FUBA: Welcher Beleg gehört zu einem IDoc.

# WLF_IDOC: Die Zauber-IDoc-Transaktion, die die WE02, WE09 und BD87 altaussehen lässt.

# Einfacher geht es nicht: IDoc-Beleg-Verlinkung per SE16 ermitteln

# Datenumsetzung bei IDocs: 3 detailliert beschriebene Fallbeispiele, um viel Zeit und Entwicklungskapazität zu sparen

 

…Übrigens findet ihr alle Beiträge im Buch „SAP Helden“ kompakt zusammengefasst.

„Das wird ein vorzüglicher Käse“, dachte sich Guiseppe Angelini, als er vorsichtig das Lab aus dem alten hölzernen Trog  abstrich und anfing den Käsebruch mit gekonnten Handgriffen in die vorgefertigten Formen zu pressen. Guiseppe hatte sich mit seiner Frau in den letzten Jahren in einem urigen Bauernhof oberhalb des Comer Sees eingerichtet. Sie genossen die Natur Oberitaliens, und Guiseppe ging völlig in seiner neuen Berufung als Käsereimeister auf.

Vor nicht allzu langer Zeit hatte er noch in seinem großen Büro im Zentrum von Mailand gesessen, von wo er als CEO das größte italienische SAP-Beratungshaus lenkte. Er hatte das Unternehmen vor über 25 Jahren mit 2 Freunden gegründet und stetig aufgebaut. Doch letztlich hatte er sich – nach reichlicher Überlegung – für das Übernahmeangebot eines großen multinationalen Beratungskonzerns entschieden. Guiseppe hatte alle Anteile seines Unternehmens verkauft und sich hierher „zurückgezogen“ – und es gab keinen Tag, an dem er diesen Schritt bereute.

Wenn Guiseppe in einer ruhigen Minute an die Zeit im SAP-Beratungsgeschäft zurückblickte, fiel ihm immer wieder die Anekdote mit seiner Großmutter ein, die bei ihm ein Schmunzeln hervorrief. Jeden ersten Sonntagnachmittag im Monat war die ganze Großfamilie Angelini bei der resoluten Oma in Verona eingeladen – das war ein gesetzter Termin, den man nicht verpassen durfte. Und gemäß dem Motto „… täglich grüßt das Murmeltier …“ fragte die Oma Guiseppe jedes Mal was er beruflich machte. Zunächst hatte er sich bemüht die Frage seiner Oma gewissenhaft zu beantworten: „Nonna, ich optimiere Prozesse in Unternehmen …“, „Nonna, ich helfe Unternehmen schneller zu arbeiten …“, „Nonna, ich aktualisiere die Buchhaltungs-Software von Unternehmen …“  Guiseppe bemerkte schnell, dass seine Erklärungsversuche nicht fruchteten. Als seine Oma weiterhin Monat für Monat die gleiche Frage stellte, machte er sich einen Spaß daraus, für seine Oma immer wieder neue Geschichten auszudenken. Einmal erzählte er, er sei Lokführer, ein anderes Mal sagte er, er sei Schneider für Damenkleider. Und einmal wurde er sogar Kapitän eines Kreuzfahrtschiffes. Letztlich bemerkte Guiseppe, dass die Oma nun nicht mehr so oft fragte. Was er sich bis heute nicht erklären konnte war, warum die Oma nicht mehr nachhakte: Lag es daran, dass die Oma bemerkt hatte, dass ihr Enkel sie nicht ernst nahm. Oder war es eher der Umstand, dass die Nonna mit den „neuen“ Berufsbildern besser umgehen konnte.

Und was erzählst du deiner Oma, wenn sie dich fragt, was du machst?

Jeder SAP-Berater, der ein paar Jahre Berufserfahrung auf dem Buckel hat, wird bemerkt haben, dass seine Aufgaben abhängig von seiner Rolle im Projekt, dem Projektziel und der Projektphase variieren. Mal ist man Projektleiter, mal übernimmt man die Aufgabe des 3rd-Level-Supporters. Ein anderes Mal wird man sich im Testteam wiederfinden und wieder ein anderes Mal muss man das Training bzw. das Coaching übernehmen. Die klassische Rolle, die man einnimmt, wird die des SAP-Beraters sein. Der SAP-Berater kommt im Idealfall zu Beginn des Projektes ins Team und hat die Aufgabe: Anforderungen aufzunehmen, Lösungen zu konzipieren, Lösungen umzusetzen, diese zu testen und sie abschließend produktiv zu setzen.

Also 5 einfache Schritte, die im Idealfall nacheinander abgearbeitet werden:

1. Anforderungsmanagement

2. Konzept

3. Umsetzung

4. Test

5. Go-Live

Um dem Thema noch etwas Fleisch zu geben, hier eine konkrete Situation aus der Praxis:

Du bist SD-Berater und dein Boss schickt dich zu einem neuen Auftrag, den er ans Land gezogen hat. Da dein Boss aktuell keine Zeit hat dich persönlich zu treffen, bekommst du eine Mail mit Eckdaten. Sinngemäß steht in der Mail:

Betreff: Neues Projekt für Dich

Projekt: Frachtkosten im Auftrag

Kunde: Maßmann GmbH

Kontakt: Frau Wassenberg

Ort/Datum: Sprockhövel / 15.02.2016 / 09:00 Uhr

Details bitte bei Frau Wassenberg erfragen …

Wenn man sich die Liste der bereitgestellten Informationen anschaut, ist sie nicht sehr üppig, entspricht aber leider vielfach dem gängigen Informationsumfang, den man vor einem Projekt bekommt.

Anforderungsmanagement

Nach dem ersten Treffen mit Fr. Wassenberg, das unbedingt pünktlich und vorbereitet stattfinden sollte, wird es deine erste Aufgabe sein, zu verstehen, was die Anforderung ist – sprich, was will der Kunde erreichen, was soll realisiert werden. Die Aufnahme der Anforderungen ist immer eine Kunst für sich und für mich immer die wichtigste Phase im Projekt, da hier die Grundlagen fürs weitere Vorgehen gelegt werden. Prinzipiell stehen für die Aufnahme der Anforderungen unterschiedliche Methodiken zur Verfügung: Interview, Systemvorstellung, Fragebogen, … Egal für welche Vorgehensweise man sich entscheidet, Ziel der Anforderungsaufnahme sollte die Beantwortung folgender Fragen sein:

# Was soll umgesetzt werden?

# Welche Sonderfälle gibt es, die man auch berücksichtigen sollte?

# Warum soll es umgesetzt werden?

# Welche zeitlichen, gesetzlichen oder projekttechnischen Rahmenbedingungen sind zu beachten?

# Welche Alternativen wurden bedacht?

# Welche Abteilungen/Personen betrifft die Umsetzung?

# Welche Ansprechpartner stehen für Detailfragen zur Verfügung?

Zusammenfassend kann man sagen, dass in dieser Phase zum einen in Erfahrung gebracht werden sollte, was das Projektziel ist und der Kunde auch darauf hingewiesen werden sollte, weitere wichtige Punkte in Erwägung zu ziehen, an die er bis dato nicht gedacht hat.

Nachdem diese Fragen in einer oder mehreren Sitzungen geklärt worden sind, solltest du die Ergebnisse dokumentieren und dem Kunden präsentieren (Word oder eher PowerPoint). Dabei sollte die Präsentation möglichst zwei Ziele erfüllen: Zum Einen sollte mit dem Kunden geklärt werden, ob ein gemeinsames Verständnis vorliegt, und zum Zweiten sollte mit der Präsentation auch eine Strukturierung der Aufgabenstellung erfolgen, so dass man das Dokument als Grundlage für eine weitere Projektplanung nutzen kann.

Der letzte Schritt in dieser Phase – wenn bei allen Beteiligten, ein gemeinsames Verständnis vorliegt – sollte ein Projektplan für das weitere Vorgehen aufgestellt werden.

Konzept

Sooo … wenn die Anforderungsaufnahme abgeschlossen ist und du im Idealfall GENAU weißt, was der Kunde will, solltest du mit der Konzeption einer Lösung beginnen. In dieser Phase ist das Ziel, sich eine Lösung für die Umsetzung der Anforderungen zu überlegen. Im Detail solltest du in dieser Phase folgende Arbeitspakete abgearbeitet haben:

# Du hast die Anforderung des Kunden genau verstanden

# Du hast dir eine oder besser mehrere Lösungsansätze zur Realisierung überlegt

# Du stellst Vor- und Nachteile der Lösungsansätze dar und gibst eine Empfehlung für einen Lösungsansatz

# Wenn möglich, solltest du einen Prototypen für den empfohlenen Lösungsweg aufbauen

# Alle Ergebnisse des Konzeptes werden dokumentiert und dem Kunden dargestellt

# Letztlich liegt es beim Kunden sich für einen konkreten Lösungsansatz zu entscheiden und diese Entscheidung zu bestätigen

Natürlich läuft die Konzeption in der Praxis nicht so eindimensional ab, wie es hier dargestellt ist. Meine Erfahrung hier ist, dass die Lösungsansätze eine Richtschnur für die Konzeption bilden, aber in der Detaildiskussion der Kunde noch eine Vielzahl von Impulsen für Umsetzung liefert, die in die Konzeption einfließen.

Umsetzung

Nachdem man sich GEMEINSAM mit dem Kunden auf ein Konzept geeinigt hat, steht die Umsetzung an. In dieser Phase sollten – basierend auf dem abgenommenen Konzept – folgende Punkte abgearbeitet werden:

# Alle Aktivitäten im Detail planen und mit dem Kunden und allen Beteiligten abstimmen

# Customizing der relevanten Funktionen / Prozesse

# Erstellung von Entwicklungsvorgaben / Begleitung der Entwicklung

# Dokumentation der Einstellungen und Entwicklungen

# Pflege der benötigten Stammdaten

# Erste Tests der Umsetzung (Funktionstests)

# Präsentation der neuen Funktionen / Prozesse am System (erste Schulung)

Test / Schulung

Nachdem die Umsetzung vom Kunden abgenommen wurde, sollte man sich im nächsten Schritt um die Testphase und die Schulung der User kümmern. Vor allem die Testphase ist eine sehr wichtige Phase, da erfahrungsgemäß in dieser noch sowohl Fehler, als auch Konzeptlücken entdeckt werden, deren Behebung maßgeblich zum Projekterfolg beitragen. Damit sollten in dieser Phase folgende Punkte erarbeitet werden:

# Konzeption und Planung des Tests

# Aufbau des Testsystems: Sollte möglichst ein sauberes und eigenes System sein

# Schulung der Mitarbeiter in den neuen Funktionen / Prozessen

# Durchführung der Tests

# Saubere Dokumentation der Fehler

# Behebung und Nachtest der Fehler

Wie hat mein lieber Projektleiter Jose einmal gesagt: „Testen ist heilig.“ – auch wenn ich diese Aussage so nicht teilen würde, stimme ich ihm doch zu, dass die Testphase sehr wichtig ist. Der Test ebnet vielfach den Weg für einen reibungslosen Go-Live und deckt viele Fehler auf, die man im Produktivsystem nicht haben will.

Go-Live

Wenn die Testphase abgeschlossen ist und alle Beteiligten sich mehr oder weniger ausgelaugt zurückziehen, steht als Krönung des Projektes der Go-Live an, d.h. die neuen Funktionen und Prozesse werden in die tägliche Arbeit und die Produktivumgebung überführt und „scharf“ geschaltet. Dabei darf man sich den Go-Live nicht als großen Schalter vorstellen, den man einmal umlegt und prompt funktioniert alles. Vielmehr ist der Go-Live ein Prozess, der über eine gewisse Zeit begleitet werden muss. Im Einzelnen sollten zum Go-Live folgende Punkte vorbereitet sein:

# Cut-Over-Plan aufstellen und abarbeiten

# Supportplan erstellen: Welcher Kollege unterstützt wann wen? Denn Unterstützung bei den Usern wird auf jeden Fall nötig sein

# Fehlermanagement-Tool aufsetzen und Monitoring der Fehler und Behebung organisieren

# KPIs aufstellen und täglich an alle Beteiligten berichten

Nach mehreren Tagen oder Wochen intensivem Support, Fehleranalyse und –behebung sollte auch diese Phase abgeschlossen sein. Als Berater kann man nun den Go-Live-Support in den Regel-Support übergeben und sich Stück für Stück rausziehen und sich die Frage stellen „… wurde es tatsächlich ein vorzüglicher Käse?“

Quintessenz

Ich hoffe, ich konnte euch einen Einblick geben, was ein SAP-Berater macht und was seine Aufgaben sind. Abschließend noch die Quintessenz zu den einzelnen Phasen: Was ist wirklich wichtig in den einzelnen Phasen, was wird oft übersehen:

Anforderungsmanagement

„Mach in dieser Phase nicht den Fehler schon an Lösung zu denken; versuche einfach objektiv die Anforderungen zu verstehen – Verstehe deinen Kunden!“

Konzept

„Du bist der Berater, aber keiner denkt, dass du Supermann bist, d.h. keiner erwartet von dir die brillante Lösung, die die Welt revolutioniert – die besten Ideen entstehen in Zusammenarbeit mit dem Kunden!“

Umsetzung

„Vielfach erlebe ich, dass sich Berater über die Umsetzung definieren. Es ist definitiv falsch sich hinzustellen und zu sagen: Sagt mir was ich machen soll und ich mache das und damit gut. Umsetzung ist Handwerk, das du beherrschen musst und meist nur ein kleiner Teil deiner Aufgaben als SAP-Berater!“

Test

„Teste niemals selber. Organisieren, plane und prüfe Ergebnisse, aber teste niemals selber. Denn die Details, was wichtig ist und wo die Fallstricke liegen, kennt nur der Fachbereich – sie müssen testen!“

Go-Live

„Vernachlässige und unterschätze den Go-Live nicht! Leg vor allem beim Go-Live viel Akribie an den Tag. Mit dieser Phase wirst du beim Kunden im Gedächtnis bleiben, ob du ein guter oder ein mittelmäßiger SAP-Berater bist!“

 

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

„Nein, lass bloß die Finger davon … “, das waren die ersten Worte, die ich zum Thema Preisfindung in SD-Modul von einem Kollegen gehört hatte.

Damals war ich direkt nach dem Studium in meinem ersten SAP-Projekt und arbeitete in Bereich Disposition (Schnittstelle zwischen SD und MM). Nach einigen Wochen, in denen ich im Projekt war, verließ ein Kollege das Team, der sich intensiv mit dem Thema Preisfindung auseinandergesetzt hatte. Natürlich hatte ich in seinen Aufgabenbereich stückweise reingeschnuppert und gemerkt, dass die Preisfindung recht komplex war. Ich bemerkte aber auch, dass sie ein sehr wichtiger und interessanter Bereich war. So spielte ich mit dem Gedanken, mich bei dem Projektleiter zu melden und ihm vorzuschlagen, dass ich den Bereich übernehmen könnte. Doch ich hörte auf den Rat des Kollegen und tat es nicht. Rückblickend war es die richtige Entscheidung; heute würde ich keinem Greenhorn, der erst vor ein paar Wochen seinen Abschluss gemacht hat, die Preisfindung überlassen.

Aber kommen wir jetzt zum eigentlichen Thema. Die Preisfindung ist von SAP im SD-Modul im Bereich Grundfunktionen angeordnet. Um hier auch nochmals die Wichtigkeit der Preisfindung zu betonen, hat SAP wohl die Preisfindung an erster Stelle im Customizingpfad Grundfunktionen angeordnet. Die Preisfindung erfüllt innerhalb des SD-Auftrags die „banale“ Aufgabe einen Preis für den Auftrag zu ermittelt – den Auftragswert. Das folgende kleine Szenario soll den Prozess kurz darstellen:

„Ring, Ring … Das Telefon klingelt bei der Auftragsannahme des Büromaterialgroßhandel Stiegmüller. Fr. Meier geht ran. Am anderen Ende meldet sich Hr. Hofbauer vom Zentraleinkauf einer großen Anwaltskanzlei und bestellt 2 Paletten Druckerpapier. Fr. Steigmüller startete mit der Auftragserfassung (VA01) und gibt die Auftragsart TA (Terminauftrag) ein. Im Übersichtsbild der Auftragserfassung gibt sie noch folgende Daten ein: Kunde (Auftraggeber), Material (Druckerpapier), Anzahl (2 Paletten) und den Wunschliefertermin des Kunden. Und prompt erscheint im oberen, mittleren Bereich des Bildschirms im Feld Nettowert der Betrag 364,50 EUR.“

Die Berechnung des Preises scheint aus der Sicht eines Laien nicht wirklich spektakulär. Man könnte behaupten: Ist doch klar 2 Paletten Druckerpapier, also muss eine Palette Druckerpapier genau 182,25 EUR kosten, was zum Material hinterlegt sein muss. Doch leider funktioniert die Preisfindung nicht so simpel.

Doch bevor ich die Preisfindung vorstelle, muss ich einen kleinen Exkurs in die Organisationsstrukturen des SD-Moduls machen, weil die für die Preisfindung essentiell sind: Die wichtigsten Organisationseinheiten im SD-Modul sind die Verkaufsorganisation, der Vertriebsweg und die Sparte.

# Die Verkaufsorganisation steht für eine verkaufende Einheit im rechtlichen Sinne und ist unteranderen dem Kunden gegenüber für die Produkthaftung verantwortlich (Quelle SAP SE). Beispielsweise können Verkaufsorganisation geographisch (Nord / Süd) gegliedert sein.

# Der Vertriebsweg definiert einfach gesprochen den Vertriebskanal: Einzelhandel, Großhandel, Versandhandel, usw.

# Die Sparte kann einzelne Produktgruppen, wie bespielweise Sportartikel, Pflegeprodukte, usw., definieren.

Das entscheidende an den Organisationseinheiten im SD-Modul ist:

# dass Objekte wie Material, Kunde oder Auftragsart diesen Org-Einheiten zu geordnet sein müssen

# und dass nur Objekte zusammen verwendet werden dürfen, die auch den gleichen Org-Einheiten zugeordnet sind, d.h. ein Kunde kann nur ein Material erwerben, das in der gleichen Vertriebslinie (entspricht der Kombination aus Verkaufsorganisation-Vertriebsweg) wie der Kunde angelegt ist.

 

OK, klingt etwas verwirrend aber hier ein Beispiel:

# Du hast eine einfache Organisationstruktur im SD definiert: Verkaufsorganisation 0001 – Nord, Vertriebsweg 01 – Einzelhandel und Sparte 01 – Sportartikel (Übrigens: SAP nennt die Kombination aus Verkaufsorg-Vertriebsweg-Sparte einen Vertriebsbereich)

# Nun hast Du den die Verkaufsart TA nur diesem Vertriebsbereich zugeordnet, aber den Kunden Fa. Rüdiger diesem Vertriebsbereich nicht zugeordnet. In diesem Fall kannst Du keinen TA-Auftrag für die Fa. Rüdiger anlegen.

# Wenn der Kunde auch diesem Vertriebsbereich zugeordnet wäre aber das Material Druckerpapier nicht, dann könntest Du für den Kunden F. Rüdiger die Auftragsart TA nutzen, aber es wäre nicht zugelassen, der Fa. Rüdiger mit der Auftragsart TA Druckerpapier zu verkaufen.

 

Kurz zusammengefasst gilt:

# Im SD-Modul kann man nur Objekte zusammen verwenden, die in den gleichen Org.-Einheiten angelegt sind.

Doch nun wieder zurück zur Preisfindung im SD-Modul. Im folgende habe ich den Ablauf der Preisfindung im SD-Modul skizziert – bitte nicht erschrecken, ich werde weiter unten das Schaubild im Detail beschreiben.

 

#1 Wie gehabt beginnt die Preisfindung mit der Anlage eines Kundenauftrags:

# Hier gibt Du zunächst eine Auftragsart ein

# gibst den Vertriebsbereich (VKOrg, VWeg, SP) vor

# und erfasst einen Kunden

#2 Basierend auf diesen 3 Informationen ermittelt das System genau ein Kalkulationsschema.

#3 Das Kalkulationsschema ist eine Liste mit Preiselementen, die zur Berechnung des Auftragspreises heran gezogen werden. Die Preiselemente können sein: Preis, Zuschläge, Abschläge und Weiteres. In der Praxis enthält ein Kalkulationsschema 10-50 Preiselemente. In der oberen Darstellung habe ich mich mit 3 begnügt. SAP nennt diese Preiselemente Konditionsarten.

#4 Alle Preiselemente (oder Konditionsarten) aus dem Kalkulationsschema werden durch das System im Detail untersucht, ob ein bestimmter „Preis“ gefunden werden kann. Ich habe hier Preis in Gänsefüßchen gestellt, weil im Kalkulationsschema natürlich nicht nur Preise, sondern auch (prozentuale) Zu-/Abschläge, Steuern, statistische Konditionen oder Zwischensummen vorkommen können. Im nächsten Schritt wird genau eine Zugriffsfolge zur Konditionsart ermittelt, die weiter untersucht wird.

#5 Die Zugriffsfolge ist technische gesprochen eine Liste mit Tabellen, die Zugriffe bzw. Schlüsselfolgen genannt werde. Im oberen Beispiel ist der erste Zugriffe Kunde/Material/Versandbedingung. Dahinter steckt genau eine Tabelle (die man sich mit der Transaktion SE16 anschauen kann) mit den Feldern oder Spalten Kunde, Material und Versandbedingung. Hier ist auch die erste Stelle in der ganzen Systematik, wo konkret ein Preis auftaucht. Pro Eintrag in dem Zugriff kann ein Preis gepflegt werden.

#6 Wenn hier ein Preis oder Zuschlag oder Rabatt gefunden wurde, wird dieser festgehalten und zur Endkalkulkation an den Auftrag übergeben (#7).

#8 Wenn in dem aktuell untersuchten Zugriff kein Preis ermittelt wurde, wird zunächst geschaut, ob ein weiterer Zugriff zu dieser Zugriffsfolge vorhanden ist, die das System durchsuchen könnte.

#9 Wenn ein weiterer Zugriff vorhanden ist, wird dieser nach der gleichen Systematik untersucht.

#10 Wenn kein weiterer Zugriff vorhanden ist oder schon ein Preis gefunden wurde, wird das nächste Preiselement (Konditionsart) aus dem Kalkulationsschema nach vorhandenen Preisen durchsucht.

Nach dieser Systematik durchläuft das System für jede Position das komplette Kalkulationsschema durch und versucht für einen Nettowert zu ermitteln. Die Summe der Nettowerte aller Positionen werden kumuliert zum Auftragswert zusammengefasst.

 

Und, raucht dir der Kopf?

Ich kann mir gut vorstellen, dass dir der Kopf raucht, wenn du bis jetzt noch nie etwas mir der Preisfindung zu tun hattest. Ich kann an dieser Stelle nur empfehlen, am System einfach mal zu probieren, verschiedene Konstellationen durchzuspielen und  zu schauen wie das System reagiert.

Für die Preisfindung muss man sich einfach die Muße nehmen und ein Gefühl entwickeln, damit man sich auf dieser Findungsebene (Konditionstechnik) sicher bewegen kann. Denn leider muss ich sagen, dass alles was ich bis jetzt ausgeführt habe, nur einen ersten Einstieg in die Preisfindung bildet. Aber dies sind die Grundlagen, mit denen man sich die Details im Weiteren erarbeiten kann.

 

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

 

Vor einigen Jahren hatte ich folgende Geschichte erlebt:

„Ich war in einem Projekt tätig, wo in unserem Bereich verschiedene Teilprojekte umgesetzt und abgeschlossen waren. Unsere Aufgabe war es noch, bestimmte Prozesse zu optimieren und hochkommende Fehler zu korrigieren. In dieser Zeit bekam ich eine Mail von einem jungen Mitarbeiter, den ich nicht kannte. Er stellte sich kurz vor und führte eine Reihe von Verbesserungsvorschlägen in den Freigabeprozessen des operativen Einkaufs auf, die man noch optimieren könnte. Als ich die Liste durchging erkannte ich, dass das alles sinnvolle Punkte waren. Zusätzlich kam noch hinzu, dass man sie mit einem überschaubaren Aufwand umsetzen konnte. Also setzten wir uns zusammen, gingen die Punkte im Detail durch und anschließend stellte ich ein grobes Konzept der Projektleitung vor. Auch die Projektleitung erkannte, dass die Punkte „gut“ waren, und ich verfasste einen Projektantrag, der auch direkt durchgewinkt wurde. Die nächsten Tage hatten wir schon die Ärmel hochgekrempelt, die ersten Lösungsansätze erarbeitet und wollten schon die Arbeitspakete schnüren. Doch urplötzlich bekam ich von einem Herrn einen „ungewöhnlichen“ Anruf. Es stellt sich heraus, dass dieser Kollege der Leiter einer Querschnittsabteilung war, der genau diese Freigabeverfahren steuerte. Er stellte mir auf eine ruhige doch unmissverständliche Art klar, dass das Projekt in dieser Form nicht weitergeführt werden kann – das Projekt war tot!“
Ein schonungsloser Blick hinter die Kulissen: Effektives Stakeholder-Management für SAP-Berater. weiterlesen

„Luzern / Schweiz – Nachdem 3 tägigen Marathon-Turnier im Luzerner Convention Center steht nun der aktuelle SAP-Weltmeister bekannt. Es ist der 34 jährige Gundolf Stelzinger aus Sprockhövel. Er konnte sich in der letzten Runde gegen seinen chinesischen Kontrahenten Chi-Ho Yeung durchsetzen.  Vor allem seine detaillierten Kenntnisse der Zusammenhänge zwischen den User-Exits in der Preisfindung und Schnittstelle zum CO-PA verhalfen ihm dazu, seinen knappen Vorsprung zu wahren, und den Titel für sich zu erringen. Auf die Frage unseres Report, welche Projekte er in nächster Zeit annehmen werde, um sein geballtes Wissen gewinnbringend einzusetzen, antwortete der wortkarge Stelzinger, dass er noch nie in einem Projekt gearbeitet hätte „
15 Gründe warum der SAP-Weltmeister nie ein Projekt bekommt weiterlesen

Wenn man sich die Statistiken der Projektbörse Gulp der letzten Jahre anschaut, gehören Berater im Modul SD (Sales & Distribution) immer zu den TOP5 der meist gesuchten SAP-Beratern auf dem Markt. Mit dem SD-Modul werden innerhalb eines Unternehmens die Vertriebs- und Distributionsprozesse gesteuert. Die Prozesse fangen (meist) mit der Auftragsanlage an, gehen über die Lieferung und enden mit der Faktura.
Der ultimative SD-Überblick anhand von 23 Funktionen weiterlesen