Vor einer größeren Weichenstellung sieht die Lage meist gleich aus: Es gibt mehrere gangbare Wege, jeder hat Anhänger im Haus, und die Unterschiede zwischen ihnen zeigen sich erst im Betrieb. Ein Proof of Concept holt diese Unterschiede nach vorn — an der eigenen Prozesskette, nicht an einer Folie.
Mein Schwerpunkt dabei ist die Strecke, über die ein Automobilzulieferer seine Kunden beliefert und abrechnet: Lieferabruf und Feinabruf im Lieferplan, JIT-Abrufe, Fortschrittszahlen, Verpackung mit NVE, Lieferavis, Rechnung und Gutschriftsverfahren. SAP-Customizing und EDI-Seite liegen bei mir in einer Hand, und ich arbeite in beiden Welten – auf ECC 6.0 und auf S/4HANA.
Der Zuschnitt
Ein Proof of Concept ist bei mir ein abgegrenztes Paket mit vier Schritten:
- Bestandsaufnahme der System- und Prozesslandschaft — was heute wirklich läuft, nicht was dokumentiert ist.
- Zwei bis drei Zielvarianten, sauber gegeneinander abgegrenzt.
- Prototypische Umsetzung des kritischsten Szenarios. Nicht der einfachste Fall wird gebaut, sondern der, an dem die Entscheidung hängt.
- Bewertung der Integrationswege.
Ergebnis ist eine Entscheidungsvorlage: die Varianten nebeneinander, was davon gebaut wurde, wie es sich verhalten hat und was offen bleibt. Was darin Projektpraxis ist und was Konzept- und Bewertungsarbeit, sage ich im ersten Gespräch von selbst.
Fragen, die sich so klären lassen
- Welcher Weg für die Frachtabrechnung. Im SAP-Standard stehen mehrere nebeneinander: Embedded TM mit eigener Frachtabrechnung, verfügbar nur im S/4HANA; der klassische LE-TRA-Frachtkostenbeleg, der im S/4 technisch weiterhin neben TM liegt; die reine Dienstleistungsbeschaffung im Einkauf mit Abrechnung über das Gutschriftsverfahren; und für die Eingangsfracht die geplanten Bezugsnebenkosten in der Bestellung, die allerdings keine Frachtkalkulation über die Transport-Konditionstechnik kennen. Welcher Weg passt, entscheidet sich an Kalkulationstiefe, Richtung der Fracht und Lizenz. Diese Abgrenzung gehört an den Anfang eines Vorhabens.
- Was der Umstieg an der Außenhandelsseite bedeutet. Präferenz ist im S/4HANA kein SD-Thema mehr: Sämtliche Präferenz-Pakete liegen dort in der GTS-Auslieferungseinheit, während der S/4-Kern Klassifizierung, Legal Control und Intrastat mitbringt. Die klassischen SD-Außenhandelsobjekte liegen technisch weiter im S/4-Repository und sind nicht gesperrt, gelten als Zielarchitektur aber nicht mehr. Wer heute im ERP kalkuliert und den Umstieg plant, sollte das früh wissen.
- Was der Standard trägt und was das Add-on. Neben dem Standard laufen bei vielen Zulieferern Automotive-Add-ons für Abrufe, Etiketten, Packmittel und Gutschriftsprüfung. Ich betrachte sie auf Nutzenebene: Welche Funktion trägt der Standard, welche das Add-on, und was heißt das für Betrieb und Upgrade. Dazu die Verträglichkeit — der Add-on-Stand muss zum Zielrelease passen, und die kundeneigenen Anpassungen müssen den Sprung überstehen.
- Wo eine Erweiterung künftig sitzt. Beim Zurücksetzen der Fortschrittszahlen zum Geschäftsjahreswechsel ändert sich mit dem Umstieg der Bauplatz. Im ECC gibt es dafür ausschließlich den klassischen Customer-Exit, die SAP-Erweiterung V45L0001 mit der Komponente EXIT_SAPLV45L_004. Im S/4HANA kommt der BAdI SD_SLS_RESET_CUMLTV_QTY_SA hinzu, der aber nur die Verfahren A und B annimmt. Beide greifen nacheinander, und der Exit läuft danach — wer beides implementiert, überschreibt sein eigenes BAdI-Ergebnis.
Nicht jede Frage braucht einen Prototyp. Das Gutschriftsverfahren etwa liegt im S/4HANA unverändert im Standard: Eingangsmonitor VSB1N, Customizing ab T665B, IDoc-Basistyp GSVERF03. Wo der Befund eindeutig ist, sage ich das — und spare die Bauzeit für die Stelle, an der sie nötig ist.
Wann ein Proof of Concept die falsche Form ist
Der Prototyp lohnt sich, wenn eine Entscheidung ansteht. Geht es um etwas anderes, ist eine andere Einsatzform schneller und günstiger:
| Anlass | Passende Form |
| Zwischen zwei bis drei Zielvarianten ist zu entscheiden | Proof of Concept mit Entscheidungsvorlage |
| Der Bestand soll erst einmal beurteilt werden | Health-Check der Abruf- und Avis-Strecke: wenige Tage, rein lesend, Bericht mit Befund und Rangfolge |
| Etwas läuft nicht und muss kurzfristig eingegrenzt werden | Störungsfall und Zweitmeinung: tageweise, kurzfristig |
| Die Richtung steht, der SD- und EDI-Teil ist zu liefern | Rollout- und Template-Mitarbeit oder Interim-Inhouse |
Nächster Schritt
Am schnellsten kommen wir voran, wenn Sie in ein paar Sätzen beschreiben, was ansteht: welcher Kunde oder OEM, welche Nachrichten, welches Release, und ob es um einen Aufbau, eine Störung oder eine Entscheidung geht. Eine Seite Aufgabenbeschreibung reicht für die Antwort, ob ich der Richtige bin und in welchem Zuschnitt.
Anfragen beantworte ich kurzfristig. Ein Profil mit Projektübersicht schicke ich auf Anfrage.