Im SAP-Umfeld gibt es bei eigentlich nur zwei Modi. Entweder ich entwickle und mache technische Analysen (ABAP Cloud, RAP, CDS, ab und zu BTP), oder ich bin als Berater quer durch den Modulgarten unterwegs, heute FI, morgen MM, übermorgen die Frage, warum die Kontenfindung anders bucht als gedacht.
In beiden Fällen bin ich bisher gleich vorgegangen: Chat auf, größtes Modell, drauflos. Ohne Persona, ohne Vorgaben, ohne alles. Das ist wunderbar bequem und produziert erstaunlich lange Wartezeiten. Irgendwann kam die Frage, ob das eigentlich sein muss.
Irrweg Nummer eins: ein Profil für beides
Der erste Reflex war, eine einzige gute Persona zu bauen, die beide Rollen abdeckt. Also so etwas wie „du bist SAP-Experte für Entwicklung und Beratung, richte dich danach, was ich gerade brauche“.
Funktioniert schlecht. Ein solcher Vorspann muss beide Welten beschreiben, und du schleppst in jedem Entwicklungs-Chat die Beratungsanweisungen mit und umgekehrt. Schlimmer noch: das Modell muss in jedem Turn selbst entscheiden, in welchem Modus es gerade ist, und liegt dabei zuverlässig manchmal daneben. Antworten in der falschen Flughöhe waren bei uns ohnehin das häufigste Ärgernis, eine Umschalt-Persona macht das nicht besser.
Die Lösung war unspektakulär: zwei getrennte Projekte, eins für Entwicklung, eins für Beratung, jeweils mit einer festen Persona in den Instructions. Kein Umschalten, kein Ballast.
Was in so eine Persona gehört
Die Entwickler-Variante regelt vier Dinge: Rolle und Haltung (Clean Core, Erweiterung vor Modifikation), die Antwortstruktur (Einordnung, Lösung, Transport- und Upgradefolgen), die Arbeitsweise (nur geänderte Codeabschnitte zeigen, bei Fehlern erst Hypothese plus einen Prüfschritt in ST22 oder ST05, unsichere technische Namen als „zu verifizieren in ADT“ markieren statt zu raten) und ein Ausgabebudget.
Die Berater-Variante sieht anders aus, weil die Arbeit anders aussieht. Dort ist die Antwortstruktur: Prozesskontext, Standardweg im Sinne von Fit-to-Standard, konkreter Customizing-Pfad, Delta und Aufwand, offene Punkte für den Kunden. Dazu die Anweisung, die modulübergreifende Wirkung immer mitzuprüfen, also Bewertungsklasse und Kontenfindung von MM nach FI, Erlöskontenfindung von SD nach FI, die Ergebnisrechnung in CO-PA.
Ein Detail, das mehr gebracht hat als erwartet: die Anweisung, unsichere technische Namen zu kennzeichnen, statt plausibel klingende zu erfinden. Ein erfundener BAdI-Name kostet dich zwanzig Minuten im System, bis du merkst, dass es ihn nicht gibt.
Der Kickoff-Block
Pro Chat kommt ein sechszeiliger Block obendrauf, ausgefüllt in etwa 30 Sekunden:
ROLLE: SAP-Entwickler, Schwerpunkt RAP
SYSTEM: S/4HANA 2023 On-Prem, Developer Extensibility
ZIEL: Determination ergänzen, die bei Anlage die Kostenstelle ableitet
GEGEBEN: BDEF, CDS View, Handler-Klasse (angehängt)
NICHT: Draft-Handling, UI, Berechtigungen
OUTPUT: Diff plus drei ABAP-Unit-Testfälle, max. 80 ZeilenFür die Beratungsseite hat der Block zwei andere Zeilen, die den Unterschied machen: ADRESSAT (Fachbereich, IT oder Lenkungskreis) und ANNAHMEN (was das Modell ungefragt voraussetzen darf). Das erste steuert Ton und Tiefe und erspart die Runde „bitte nochmal für den Lenkungskreis“, das zweite ersetzt die Rückfrageschleife.
Die wirksamsten Zeilen sind aber in beiden Fällen NICHT und OUTPUT. Die erste verhindert ungefragte Zusatzarbeit, die zweite deckelt die Ausgabeseite. Zusammen etwa 60 Tokens Aufwand.
Irrweg Nummer zwei: „Sonnet lohnt sich nicht, weil ich es dann zweimal mache“
Dann die Modellfrage. Die Listenpreise pro Million Tokens sehen so aus:
| Modell | Input | Output |
|---|---|---|
| Opus 5 | 5 $ | 25 $ |
| Sonnet 5 | 2 $ | 10 $ |
| Haiku 4.5 | 1 $ | 5 $ |
Das Verhältnis ist auf beiden Seiten gleich: Opus kostet das 2,5-fache von Sonnet und das 5-fache von Haiku. Wer grundsätzlich das größte Modell fährt, zahlt für jede Formatierungsaufgabe den fünffachen Preis.
Der Einwand kam sofort, und zwar von mir selbst: wenn Sonnet nicht reicht, mache ich die Arbeit zweimal, und dann war nichts gespart. Klingt plausibel, hält aber der Rechnung nicht stand.
Bei „Sonnet zuerst, bei Bedarf Eskalation auf Opus“ kostet eine Aufgabe 1 + p × 2,5 Einheiten, wobei p der Anteil der eskalierten Fälle ist. „Immer Opus“ kostet 2,5. Gleichstand liegt bei p = 0,6.
Solange also weniger als 60 Prozent der Aufgaben hochgestuft werden müssen, ist Sonnet zuerst billiger, und zwar selbst dann, wenn die Eskalation die komplette Arbeit wiederholt. Im SAP-Alltag liegt der Wert deutlich darunter, weil der Großteil nachschlagen, formulieren oder nach klarer Spec umsetzen ist. Was tatsächlich sofort auf das große Modell gehört: modulübergreifende Konzeptarbeit, Root-Cause-Analyse ohne klare Fehlermeldung, Migrations- und Architekturentscheidungen. Also alles, wo ein Fehler später Tage kostet.
Und was ich bewusst nicht optimiert habe
Der naheliegende nächste Gedanke war, die Persona möglichst knapp zu halten, um Tokens zu sparen. Das ist Unsinn, und zwar aus einem Grund, der uns erst später richtig klar wurde: stabile Vorspänne werden gecacht und dabei mit einem Zehntel des normalen Preises abgerechnet. Eine gut ausformulierte Persona kostet praktisch nichts, solange du sie nicht ständig umschreibst.
Genau das ist übrigens die häufigste Selbstsabotage: Instructions mitten in einer Arbeitssitzung nachschärfen. Jede Änderung wirft den Cache weg. Sammle die Änderungen und zieh sie gebündelt nach.
Learnings
- Zwei Rollen, zwei Projekte. Eine Umschalt-Persona schleppt in jedem Chat die jeweils andere Hälfte mit und rät trotzdem gelegentlich falsch.
NICHTundOUTPUTsind die wirksamsten Zeilen im Prompt. Sie kosten 60 Tokens und sparen Nachfragerunden.- Sonnet zuerst rechnet sich bis zu 60 Prozent Eskalationsquote. Selbst wenn die Eskalation die ganze Arbeit wiederholt.
- Unsichere technische Namen kennzeichnen lassen. Ein erfundener BAdI kostet mehr Zeit als jeder Tokenpreis.
- An der Persona zu sparen ist die falsche Baustelle. Sie ist gecacht und damit fast gratis.
Damit war ich zufrieden. Bis ich angefangen haben zu messen, wo die Tokens tatsächlich hingehen. Das Ergebnis hat meine Prioritätenliste umgeworfen, und die Modellwahl war plötzlich nicht mehr der Hauptschuldige. Darum geht es in Teil 2.