Die taktische Ebene - in Projekten und Change Requests

Wenn die strategische Ebene entscheidet, was ein Unternehmen erreichen will, entscheidet die taktische Ebene, was das praktisch bedeutet.

Auf dieser Ebene findet heute, gemessen an den Stunden, der größte Teil der Projektarbeit statt. Softwarefunktionen werden dem Business erklärt, Anforderungen werden auf Standardsoftware abgebildet, Gaps werden definiert, Umsetzungspläne werden erstellt. Projektleiter, Teamleiter, Berater, Business-Vertreter und Architekten versuchen, breite Projektziele in Software zu übersetzen, die tatsächlich funktioniert.

Methoden haben sich über die Zeit verändert, jedes Mal mit dem Versprechen, einen Teil des Aufwands zu sparen. Im Kern bleibt diese Ebene aber ein Verhandlungsprozess.

Welche Anforderungen sind wirklich nützlich, also positiv, wenn Implementierungskosten, Wartungskosten, Prozesskomplexität, Schulungsaufwand und Upgrade-Risiko berücksichtigt werden? Welche sind es nicht? Wenn man auf die eigentliche Bedeutung der Anforderung schaut, nicht auf die Art, wie sie im Altsystem umgesetzt war: Kann sie durch eine mehr oder weniger kreative Nutzung von Standardsoftware gelöst werden, oder nicht?

Die ewige Frage: SAP Standard oder nicht?

Hier taucht die vertraute Frage immer wieder auf:

Können wir das mit Standardsoftware lösen, oder brauchen wir eine Custom-Entwicklung?

Die konventionelle Antwort ist oft zu einfach. "SAP-Standard ist billiger." "Custom Development ist teuer." "Bleib nah am Standard."

Diese Aussagen sind oft richtig. Aber nicht immer.

Entgegen der verbreiteten Erwartung kann es länger dauern und in der Implementierung teurer sein, eine kreative Lösung im SAP-Standard zu finden, als eine Custom-Entwicklung zu bauen. In vielen Fällen wird es trotzdem in der Wartung billiger sein. In anderen Fällen kann eine zu kreative Nutzung von Standardfunktionalität in der Implementierung billig wirken, aber in der Wartung zum Problem werden. Und manchmal ist eine saubere Custom-Entwicklung billiger, klarer und stabiler, als einen Geschäftsprozess in einen Standardmechanismus zu pressen, für den er nie gedacht war.

Gute Beratung erfordert Urteilsvermögen

Deshalb geht es bei guter Beratung auf der taktischen Ebene nicht um Ideologie. Es geht um Urteilsvermögen.

Im optimalen Fall nehmen erfahrene Berater die Orientierung von der strategischen Ebene und übersetzen sie in praktische Lösungsentscheidungen. Sie verstehen die Business-Anforderung, den Softwarestandard, die Wartungsfolgen, das Projektbudget und die Menschen, die nach Go-live mit dem Ergebnis leben müssen.

Ihre Aufgabe ist es, zum Kern der Anforderung vorzudringen: zu verstehen, ob die tieferen Gründe und Ziele dahinter erklärt werden können, ob sie heute noch gelten, ob sie durch SAP-Standardfunktionalität irrelevant werden könnten, und ob es nach all dem eine Lösung im oder nahe am Standard gibt, ohne ihn zu missbrauchen.

Auf dieser Ebene kann vieles schiefgehen.

Zu hoher Druck auf Projektbudgets oder Festpreismechanismen kann zu Lösungen führen, die einfacher und schneller zu implementieren sind, aber bereits im Test, beim Go-live oder später in der Wartung scheitern, selbst wenn die Berater qualifiziert und erfahren sind.

Mangelnde Erfahrung mit Projekten, Wartung oder beidem kann ähnliche Effekte haben. Auf der anderen Seite können Projektteams, die später auch für die Wartung verantwortlich sind, einen übertriebenen Fokus auf Wartbarkeit entwickeln, der zu endlosen Diskussionen und Projekten führt.

Was ändert sich durch KI?

Welche Vorteile und Nachteile bringt KI auf dieser Ebene?

Mit KI-Systemen ist es möglich, große Informationsmengen zu Legacy-Prozessen und Anforderungen in sehr kurzer Zeit zu analysieren. Das kann direkte Codeanalyse einschließen, aber auch frühere Anforderungen, Spezifikationen, Tickets, Testfälle, Prozessbeschreibungen und Dokumentation. Mit ausreichend Wissen über Standardfunktionalitäten und Lizenzkosten werden KI-Systeme bald mögliche Implementierungspläne erstellen können.

Die Analyse von Anforderungen und Spezifikationen nutzt die Fähigkeit von KI, Mehrdeutigkeit zu bearbeiten. KI kann Lücken in der Spezifikation identifizieren und sie Beratern oder Business-Vertretern zur Klärung vorlegen.

Coding ist oft weniger mehrdeutig, aber nur dann, wenn auch die Systemarchitekturen und Schnittstellen, die zum aktuellen Design geführt haben, dokumentiert und als Kontext verfügbar sind. Ohne diesen Kontext kann KI Code korrekt erklären oder übersetzen und trotzdem verpassen, warum die Lösung existiert, ob der Grund noch gilt und ob die Anforderung in die Zukunft getragen werden sollte.

Es gibt mehrere Herausforderungen.

Legacy-Dokumentation und Coding repräsentieren die Ziele und Präferenzen der Organisation zum Zeitpunkt der Implementierung. Eine der zentralen Herausforderungen auf dieser Ebene ist herauszufinden, ob sie die Ziele und Präferenzen der Organisation heute noch repräsentieren.

Oft können weder Dokumentation noch IT- oder Fachbereiche schlüssig erklären, warum eine Lösung so implementiert wurde und ob die ursprünglichen Ziele noch gelten. Um Legacy-Funktionen auf Standardsoftware abzubilden und zu verstehen, welche Teile geändert oder angepasst werden können, ist das Verstehen der zugrunde liegenden Ziele entscheidend.

Viele Anforderungen verschwinden einfach, sobald die neue Standardsoftware richtig verstanden ist oder klar wird, dass die Herausforderungen früherer Zeiten heute nicht mehr gelten.

Für KI mag es relativ einfach sein, eine Lösung aus einer Legacy-Sprache in eine moderne Programmiersprache zu migrieren. Das ist aber nicht das Ziel, wenn wir Standardsoftware implementieren. Wir versuchen nicht, die Vergangenheit perfekt zu bewahren. Wir versuchen zu verstehen, was das Business heute wirklich braucht, und wie viel davon durch Standardsoftware, Konfiguration, Prozessveränderung oder Custom Development gelöst werden sollte.

Die größte Herausforderung entsteht durch den Fortschritt auf der Umsetzungsebene. Implementierungs- und Testaufwände sinken mit bemerkenswerter Geschwindigkeit. SAP-Software steht erst am Anfang dieses Prozesses, während KI-unterstützte Entwicklung, inklusive agentischer Entwicklung, in anderen Umgebungen bereits normal wird.

Warum sollte ein Entscheider lange Diskussionen über den Wert einer Funktion akzeptieren, wenn sie in einem Tag implementiert, schnell getestet und vielleicht sogar mit Hilfe von KI gewartet werden kann?

IT-Menschen verstehen intuitiv das Risiko einer endlosen Flut von Funktionen, die schnell implementiert und nur teilweise verstanden werden. Aber wie hält man einen Entscheider davon ab, eine Implementierung zu wählen, wenn das Gegenargument im Wesentlichen lautet: "Es dauert nur zwei Tage zum Bauen und Testen", plus eine schwer quantifizierbare Sorge um spätere Wartung?

Das ist eine der zentralen strategischen Fragen für SAP und jeden Enterprise-Software-Anbieter. Wer wird noch Tage investieren, um eine Anforderung tief zu verstehen und eine kreative Nutzung von Standardsoftware zu finden, wenn KI auf Basis von Legacy-Dokumenten eine Custom-Lösung generieren, programmieren, testen und an den Fachbereich übergeben kann?

Fazit

Ich glaube, die Schlussfolgerung, Standardsoftware werde irrelevant, ist falsch.

Standardsoftware, die so weit verbreitet ist wie SAP, hat viele Vorteile, die sich nicht leicht in TCO messen lassen. Wenn ein Unternehmen Menschen einstellt, die die Standardsoftware kennen, arbeiten sie sich leichter ein. Ideen wandern zwischen Unternehmen. Arbeitsmobilität verbessert sich. Erfahrungsaustausch wird einfacher. Das ist sehr anders als eine vollständig individuelle Softwarelandschaft zu betreiben, die außerhalb der Organisation, und vielleicht außer den beteiligten KI-Agenten, niemand wirklich versteht.

Das bedeutet nicht, dass KI-unterstützte Custom-Entwicklung schlecht ist. Im Gegenteil, sie wird oft sehr wertvoll sein. Sie verändert aber die taktische Diskussion. Die Frage wird seltener sein, ob etwas überhaupt gebaut werden kann. In vielen Fällen wird die Antwort ja lauten, und der Aufwand wird deutlich niedriger sein, als wir es gewohnt sind.

Die wichtigere Frage wird sein, ob die Funktion gebaut werden sollte: ob sie Custom Development, Konfiguration, Prozessveränderung, eine kontrollierte Erweiterung oder vielleicht gar keine Implementierung sein sollte.

SAPs Joule für Berater und andere beraterorientierte KI-Werkzeuge wie unsere accelet.ai Plattform sind sicher ein Schritt in die richtige Richtung. Wenn KI Beratern helfen kann, Anforderungen schneller zu verstehen, sie gegen Standardfunktionalität zu vergleichen, Lücken zu identifizieren und mögliche Lösungswege vorzubereiten, unterstützt sie genau die Arbeit auf dieser taktischen Ebene.

Diese Werkzeuge müssen noch beweisen, wie stark sie die Rolle von Standardsoftware stärken können und ob sie die Richtung weg von unkontrollierter KI-generierter Custom-Entwicklung in ABAP oder anderen Umgebungen verschieben können.

Insgesamt ist das Potenzial von KI auf dieser Ebene groß. Sie wird verändern, wie wir mit Standard- und Custom-Software umgehen und wie Berater, IT und Fachbereiche zusammenarbeiten. Wir sehen erst den Anfang.

KI wird den Bedarf an Beratern nicht beseitigen. Sie wird guten Beratern bessere Instrumente geben und schlechte Scope-Disziplin gefährlicher machen. Die Zukunft von SAP-Projekten wird nicht "nur Standard" oder "KI baut alles" sein. Sie wird erfordern, KI zum schnelleren Verstehen einzusetzen, SAP-Standard dort zu nutzen, wo er Stabilität schafft, Custom Development dort einzusetzen, wo es echten Business Value schafft, und genug menschliche Urteilskraft zu haben, um den Unterschied zu erkennen.

Was acceletail bietet: Mit oder ohne KI wollen unsere erfahrenen Berater die Ziele unserer Kunden tief genug verstehen, um ihnen zu helfen, die richtigen Entscheidungen zu treffen und nachhaltige IT-Lösungen zu gestalten. Mit accelet.ai können wir Dokumentation verarbeiten, SAP Legacy Code über ADT und MCP-Server analysieren und unseren Beratern helfen, die Diskussion mit besserem Kontext zu führen.

---