In einer Rollout-Welle ist meine Aufgabe nicht, die Template-Entscheidungen neu zu treffen, sondern den SD- und EDI-Teil des bestehenden Templates in ein weiteres Werk zu bringen. Der Zuschnitt: Fit-Gap gegen das bestehende Template, Übernahme des SD- und EDI-Teils in der Rollout-Welle, Testfälle und Cutover-Schritte für die Abrufstrecke.

Diese Rolle kenne ich von beiden Seiten. Als Teilprojektleiter Vertrieb bei Werks-Rollouts: Aufnahme der lokalen Prozesse, Customizing, Test, Cutover, Betreuung nach dem Go-Live. Und als fachlich Verantwortlicher für den Versandbereich eines Konzern-Templates — Konzeption der Ausgangsseite, Abstimmung mit den Prozessverantwortlichen, Abnahme gegen Testfälle, Einführung in mehreren Werken, Anbindung von Lagerdienstleistern.

Fit-Gap gegen das bestehende Template

Am Anfang steht der Abgleich der Werksprozesse gegen das Template: Abrufstrecke, Preis- und Steuerfindung, Intercompany und Umlagerung. Entscheidend ist dabei, woher die Bestandsaufnahme kommt.

Die Bestandsaufnahme muss aus dem Produktivsystem kommen. Entwicklung, Qualitätssicherung und Produktion laufen über die Jahre auseinander, und ein Fit-Gap allein aus der Entwicklung führt in die Irre.

Zum Fit-Gap gehört auch ein Abgleich zwischen den konfigurierten Partnerprofilen und den Partnern, die im letzten Jahr wirklich Verkehr hatten. Erfahrungsgemäß ist ein erheblicher Teil davon Karteileiche und wandert bei jeder Migration unbesehen mit.

Der SD- und EDI-Teil der Welle

Partnervereinbarung in WE20, Vorgangscode, Nachrichtensteuerung und die Feldbelegung für den Konverter beurteile ich zusammen, weil sie zusammen wirken. Viele Abruf- und Avis-Fehler sitzen genau auf dieser Grenze und wandern sonst zwischen zwei Zuständigkeiten hin und her.

Laufen im Haus Automotive-Add-ons für Abrufe, Etiketten, Packmittel oder Gutschriftsprüfung, gehört deren Konfiguration je Kunde, Werk und Abrufart in die Welle. Wirksam wird eine Funktion erst über diese Konfiguration; laufen Entwicklungs-, Test- und Produktivstand auseinander, rechnet derselbe Abruf im Test anders als produktiv. Steht die Welle zugleich auf einem Releasewechsel, muss der Add-on-Stand zum Zielrelease passen und die kundeneigenen Anpassungen müssen den Sprung überstehen.

Testfälle entlang der Nachrichtenarten

Ein grünes IDoc ist kein bestandener Test. Die Testfälle müssen die Findung und die werksabhängigen Einstellungen treffen, nicht nur den Verarbeitungsweg:

• Lieferabruf und Feinabruf. Nachrichtenart DELINS auf den Basistypen DELFOR01 und DELFOR02, Vorgangscode DELI. Die Lieferplanfindung läuft über den Index VLPKM mit Kundenmaterial, Auftraggeber, Kundenwerk, Abladestelle und Abrufverwendung. V4 034 heißt kein Treffer, V4 035 mehrere Treffer — beide setzen denselben Fehlerstatus, die Korrekturen laufen in entgegengesetzte Richtungen.
• JIT-Abruf. Der sequenzierte Abruf unter der Nachrichtenart SEQJIT, der Mengenabruf unter PAB_ORDERS, beide auf den Basistypen SEQJIT01 bis SEQJIT03.
• Fortschrittszahlen. Der Jahreswechsel richtet sich nach der Geschäftsjahresvariante des Warenempfängers in den allgemeinen Kundenstammdaten (KNA1-PERIV); ist sie nicht gepflegt, rechnet SAP mit dem Kalenderjahr. Der Wert gehört in die Stammdaten-Checkliste der Welle.
• Lieferavis mit NVE. Ob eine Handling Unit überhaupt eine NVE bekommt, entscheidet die Packmittelart über die Nummernvergabe in TVTY. Die ILN-Basisnummer kommt aus dem Customizing auf Werk- und Lagerortebene (T313Y) beziehungsweise auf Ebene der Lagernummer (T313Z) — also aus genau den Objekten, die im neuen Werk erst entstehen.
• Abrechnung. Rechnung INVOIC aus der SD-Faktura, Gutschriftsverfahren über den Vorgangscode GSVE zum Abrechnungsbeleg oder über SBAP in den Eingangsmonitor VSB1N, Zahlungsavis REMADV im Eingang.
• Statistik. Vier Statistikgruppen an Kunde, Material, Belegart und Positionstyp ergeben je Vertriebsbereich die Fortschreibungsgruppe. Fehlt dazu ein Findungseintrag, bleibt die Statistik ohne jede Fehlermeldung leer — im Test fällt das nur auf, wenn jemand hinsieht.

Cutover und die Wochen danach

Für den Cutover schreibe ich die Schritte der Abrufstrecke in der Reihenfolge fest, in der sie greifen müssen: Partnervereinbarungen umschalten, Nachrichtensteuerung scharfstellen, Mapping des Konverters auf das neue Werk ziehen. Abnahmepunkt ist nicht das Transportprotokoll, sondern der erste produktive Abruf im Lieferplan und das erste vom Partner quittierte Avis.

Danach begleite ich die Hypercare-Phase. Beim Monitoring ist der IDoc-Status als Alarmkriterium zu grob — ein Alarm auf Statusebene weckt entweder die falschen Leute oder niemanden. Ich baue stattdessen regelbasiertes Monitoring aus Nachrichtenart, Partner, Meldung und Schwellwert, mit eigener Empfängerliste je Regel. Key-User-Schulung und Beraterdokumentation zu meinen Themen mache ich selbst und gern.

Was ich übernehme — und was nicht

Mein Teil	Bleibt beim Programm
SD- und EDI-Teil der Rollout-Welle mit der angrenzenden Logistik	Programmleitung über mehrere parallele Teilprojekte mit eigenem PMO und Steuerungsgremien
Fit-Gap, Customizing, Testfälle, Cutover und Hypercare in diesem Schnitt	FI/CO-Kern einer vollständigen Greenfield-Einführung über alle Module
Key-User-Schulung und Beraterdokumentation zu meinen Themen	Schulungsrollout über mehrere Standorte mit vielen parallelen Gruppen
ABAP und Basis über mein Partnernetz — Vertragspartner bleibe ich	Basis- und HANA-Betrieb, Systemkopien, Upgrade-Durchführung, Berechtigungs-Redesign

Fährt ein größeres Haus das Programm, arbeite ich dort als Nachunternehmer im SD- und EDI-Teil mit, nach der Projektmethodik und dem Transportwesen des Hauses.

---

Beschreiben Sie mir in ein paar Sätzen, welche Welle ansteht: welches Werk, welcher Kunde oder OEM, welche Nachrichten und welches Release. Im ersten Gespräch sage ich, ob ich der Richtige bin und in welchem Zuschnitt.