SAP IS-U-Projekte starten nie bei null – Best Practices für einen erfolgreichen Projektstart

In dieser Artikelreihe geben unsere Kolleg*innen einen Blick hinter die Kulissen ihrer täglichen Arbeit. Heute teilt Fabrice Ngoko, SAP-Berater und ABAP-Entwickler bei ENECON, seine Erfahrungen aus zahlreichen Projekten im Bereich SAP IS-U.

Sein zentrales Learning:

„IS-U-Projekte starten nie bei null – und genau das macht sie so spannend.“

Wer glaubt, ein neues SAP IS-U-Projekt beginne immer mit einem weißen Blatt Papier, hat wahrscheinlich noch nie einen echten Blick in die Systemlandschaft eines Energieversorgers geworfen.

Die Realität sieht oft ganz anders aus:

• Eigenentwicklungen, die „damals“ schnell umgesetzt werden mussten, um akute Probleme zu lösen – ohne langfristige Architekturplanung.

• Customizing-Strukturen, die über Jahre hinweg gewachsen sind und deren ursprüngliche Logik heute kaum noch jemand versteht.

• Stammdaten, die eigentlich schon vor fünf Jahren bereinigt werden sollten, es aber nie wurden – oft aus Zeit- oder Budgetgründen.

Die wahre Arbeit beginnt vor der ersten Zeile Code

Für mich ist der Start eines IS-U-Projekts nicht das Erstellen von Spezifikationen oder die Planung neuer Prozesse.
Er beginnt mit Fragen, die tiefer gehen:

• Warum ist es überhaupt so geworden?

• Wer kennt noch den alten Workaround – und warum wurde er eingeführt?

• Wo treten Probleme immer wieder auf, und welche Ursachen liegen dahinter?

Erst wenn diese Fragen beantwortet sind, lohnt es sich, über technische Umsetzung nachzudenken.

Archäologie im SAP-System

Ich beginne deshalb mit Logs, Fehleranalysen und alten Z-Reports.
Diese liefern oft ehrlichere Antworten als jedes Workshop-Protokoll, weil sie das tatsächliche Verhalten des Systems widerspiegeln – nicht nur die Wunschvorstellung.

Manchmal fühlt sich das an wie Archäologie mit ABAP & GPKE:
Man gräbt alte Logiken aus, versteht ihre Entstehung und bewertet, ob sie heute noch Sinn ergeben.

Der Mehrwert dieser „Vorarbeit“

Wer diese Phase ernst nimmt, spart später Wochen an Debugging, Rückbauten und Frust im Projektteam.
Denn viele Probleme entstehen nicht durch die neue Entwicklung – sondern durch Altlasten, die vorher nicht identifiziert wurden.

📌 Mein Fazit:
Wer in IS-U nur Prozesse sieht, übersieht die Geschichten dahinter – und stolpert früher oder später über ein vergessenes Z-Programm.
Gute Projektarbeit beginnt nicht beim Neuentwickeln, sondern beim Verstehen des Alten.