KI im SAP-Projekt: Coding ist die kleinere Hälfte

„Was ist unsere KI-Strategie für das S/4-Projekt?” — die Frage steht inzwischen in jedem Lenkungsausschuss. Was als Antwort zurückkommt, ist meistens eine Werkzeugliste: ein Coding-Assistent für die Entwicklung, ein Chat-Werkzeug für alle anderen, vielleicht ein Pilot für Testfälle. Drei Piloten, drei Verträge, drei Diskussionen mit Security und Betriebsrat.

Was in dieser Liste fehlt, ist der größere Teil des Projekts.

Ein Projekt hat zwei Hälften

Für die linke Hälfte ist die KI-Frage weitgehend beantwortet. Es gibt reife Coding-Assistenten, die Entwicklerarbeit spürbar beschleunigen, und der übliche Zuschnitt — Entwicklungssystem, enger Scope, menschliches Review — ist vertretbar. Diese Hälfte ist nicht das Problem.

Das Problem ist die rechte. Sie macht in einer Transformation den größeren Aufwandsblock aus, sie bindet genau die Leute, die man für Entscheidungen bräuchte, und sie ist in den meisten KI-Strategien schlicht nicht besetzt.

Warum generische Werkzeuge dort scheitern

Der naheliegende Griff ist ein allgemeiner Chat-Assistent für alle. Er weiß viel über SAP im Allgemeinen und nichts über Ihres. Auf die Frage, welche Bestellprozessvariante bei Ihnen das Volumen trägt, kann er nur allgemein antworten — und tut es leider flüssig.

Der zweite Griff ist ein Agent mit Live-Verbindung ins System. Der kennt Ihr System, aber er erkauft das mit einer Architektur, die durch Security, Basis und Betriebsrat muss; und er weiß trotzdem nicht, was er noch nicht gesehen hat. Warum das eine eigene Diskussion ist, steht in Attached vs. Detached und auf der Seite zur KI-Strategie.

Beide scheitern an derselben Stelle: Es fehlt nicht das Modell, es fehlt die Wissensbasis. Eine KI kann im Projekt nur dort etwas beitragen, wo jemand vorher zusammengetragen hat, wie dieses System tatsächlich aussieht — vollständig, strukturiert und aktuell. Genau diese Vorarbeit ist der Teil, den keiner der Piloten mitliefert.

Wenn die Basis einmal steht

Ist das Ist-Bild einmal strukturiert vorhanden, hört „KI-Anwendungsfall” auf, ein Einzelprojekt zu sein. Es wird eine Eigenschaft der Plattform, auf der man ohnehin arbeitet:

• Fragen ans eigene System. Welche Werke buchen noch mit Sonderweg, welche Feature-Nutzung ist auf Null gelaufen, wo hängt eine Eigenentwicklung an einem Prozess — beantwortet auf Ihren Daten, nicht auf Allgemeinwissen.
• Eigenentwicklungen bewerten. Die KI liest den Quelltext der Z-Objekte und liefert Befunde mit Fundstelle — Cloud-Tauglichkeit, Ablösekandidaten, fachliche Einordnung statt einer Zahl von 0 bis 100, der niemand widersprechen kann (Custom-Code-Analyse).
• Scope-Entscheidungen vorbereiten. Was bleibt, was fällt weg, was ist vom Public-Cloud-Standard wie weit entfernt — mit den Belegzahlen daneben.
• Fachkonzepte und Dokumentation entwerfen. Der Assistent schreibt Kapitel in Ihrer Knowledge Base, verdichtet und prüft gegen den echten Datenbestand. Wie das im Detail funktioniert, steht in Kann KI Fachkonzepte schreiben?.

Das ist der eigentliche Punkt: Nicht vier Werkzeuge für vier Anwendungsfälle, sondern ein Bestand, auf den vier Fragen zugreifen. Der Aufwand steckt in der Basis, nicht im jeweils nächsten Piloten.

Die drei Fragen, die jede KI-Strategie beantworten muss

Werkzeugauswahl ist der einfache Teil. Freigegeben wird eine KI-Strategie an drei anderen Fragen — und die stellt Ihnen Ihr Datenschutzbeauftragter, Ihr Betriebsrat und Ihr Controlling, nicht Ihr Architekt.

1. Welche Daten verlassen das Haus, und wohin? Nicht „nutzen wir KI”, sondern: welche Datenklassen gehen an welchen Anbieter. In Conjola hinterlegen Sie Ihren eigenen LLM-Zugang — OpenAI, Gemini oder Mistral, Ihr Vertrag, Ihre Konditionen, Ihre Zusagen zur Verarbeitung. Und weil die Plattform durchgehend detached arbeitet, ist die Menge, um die es überhaupt gehen kann, vorher definiert: der freigegebene Extrakt. Keine offene Leitung ins Produktivsystem, aus der ein Modell zur Laufzeit nachfordert.

2. Wer darf was — und was darf die Maschine in seinem Namen? Der Assistent bekommt seine Fähigkeiten pro Anfrage aus Modullizenz und Rollenrechten des fragenden Nutzers zusammengestellt. Der Satz dahinter lautet: Ein Skill sieht nie mehr als der Mensch, der ihn auslöst. Eine Freigabe kann diese Grenze nur enger ziehen, nie weiter — ein Konfigurationsfehler kann niemandem Zugriff verschaffen, den er ohne KI nicht hätte.

Zugriff ist dabei nicht dasselbe wie Vollmacht. „Der Redakteur darf Dispositionen setzen” ist eine andere Aussage als „die KI darf das unbeaufsichtigt tun”. Deshalb ist der Autonomiegrad je Fähigkeitsgruppe eine eigene Einstellung mit drei Stufen: aus, nur Entwurf — die KI rechnet und schlägt vor, gespeichert wird nichts — oder ausführen im Rahmen der Rechte des Nutzers. Wer KI-Schreibzugriff nicht grundsätzlich ablehnt, sondern ihn nach einer Eingewöhnungsphase freigeben will, braucht genau diese mittlere Stufe. Und was eine KI-Fähigkeit anlegt oder ändert, steht im Changelog als KI-Aktion — mit dem auslösenden Menschen als Verantwortlichem, nicht mit einem Systembenutzer.

3. Was kostet das, und wer sieht die Rechnung? Jede Anfrage an ein Sprachmodell kostet echtes Geld, und ohne Deckel bremst niemand. Weil der Zugang Ihrer ist, läuft der Verbrauch über Ihren Vertrag statt über eine undurchsichtige Pauschale; jede Anfrage wird mit ihrem Tokenverbrauch protokolliert, und darauf setzen ein Monatsbudget je Mandant, eine Frühwarnung, bevor es aufgebraucht ist, und eine verständliche Absage im Chat statt eines abbrechenden Streams. Kosten sind damit eine Größe, die man vorher festlegt — und nicht eine, die man in der ersten Provider-Rechnung nach dem Rollout entdeckt.

Wer diese drei Fragen einmal für eine Plattform beantwortet, muss sie nicht für jeden weiteren Anwendungsfall neu beantworten. Wer sie für drei Piloten beantwortet, tut genau das.

Assistenz für alle im Projekt, nicht nur für die Entwickler

Das Copilot-Muster verteilt KI entlang der Entwicklungsorganisation: Wer Code schreibt, bekommt einen Assistenten. In einer Transformation sitzt der Aufwand aber woanders — beim Prozessverantwortlichen, der wissen muss, wie oft sein Sonderweg wirklich gebucht wird; beim Berater, der ein Fachkonzept schreibt; beim Key User, der eine Entscheidung begründen soll; beim Projektleiter, der einen Statusbericht braucht.

Diese Rollen bekommen im üblichen Zuschnitt gar keine Assistenz — oder eine, die ihr System nicht kennt. Dabei arbeiten sie ohnehin schon mit den Daten. Der Assistent gehört dorthin, wo diese Arbeit stattfindet, und mit denselben Rechten, die diese Menschen dort haben.

Was ehrlich dazugehört

Conjola schreibt keinen Code und migriert keine Daten. Die linke Hälfte bleibt die linke Hälfte — dafür gibt es andere, gute Werkzeuge, und sie laufen zu Recht woanders. Wir lösen die Frage nicht dadurch, dass wir behaupten, alles zu können.

KI liefert Entwürfe, keine Entscheidungen. Ein generiertes Konzept, eine Bewertung, eine Zusammenfassung sind belastbare erste Würfe, die Wochen an Fleißarbeit sparen. Was übernommen, gestrichen und anders entschieden wird, verantworten Menschen. Der Unterschied zum Piloten mit generischem Werkzeug ist: Man diskutiert über Inhalte statt darüber, ob die Grundlage überhaupt stimmt.

Eine KI-Strategie fürs SAP-Projekt ist keine Werkzeugliste. Sie ist die Entscheidung, woher die Maschine weiß, wie Ihr System aussieht.

---

Genau dafür ist Conjola gebaut: ein lesender Extrakt aus Ihrem System, daraus in rund 24 Stunden ein strukturiertes Ist-Bild aus Prozessen, Feature Map, Custom Code und Stammdaten — und darauf eine Knowledge Base mit einem Assistenten, den alle Projektrollen nutzen, jeder mit seinen eigenen Rechten, über Ihren eigenen LLM-Zugang. Ohne Live-Verbindung in Ihr SAP-System — durchgehend detached.