← Zurück zum Blog

Kann KI Fachkonzepte schreiben? Nicht am System — auf strukturierten Daten

· Conjola

Fachkonzepte sind der teuerste Text in SAP-Projekten. Jemand muss verstehen, was das System heute tut, was es künftig tun soll, und beides so aufschreiben, dass Fachbereich, Entwicklung und Test damit arbeiten können. Wochen an Aufwand, gebunden an die Leute, die man eigentlich für Entscheidungen bräuchte.

Naheliegend also die Frage: Kann KI das übernehmen?

Der naheliegende Weg — und warum er wackelt

Die verlockendste Variante ist schnell aufgesetzt: ein Coding-Agent wie Claude Code, eine ADT-Verbindung ins System, und der Auftrag „lies dir den Bestellprozess an und schreib ein Fachkonzept”. Technisch funktioniert das. Der Agent liest Code, folgt Aufrufen, schaut in Customizing-Tabellen. Man kann ihm dabei zusehen.

Nur: Er läuft sehr lange — und niemand weiß, wann er fertig ist. Das ist kein Geduldsproblem, sondern ein strukturelles:

  1. Kein Abbruchkriterium. Ein Agent, der sich durch ein gewachsenes System hangelt, hat keine Landkarte. Er weiß nicht, was er noch nicht gesehen hat — also weiß er auch nicht, wann das Bild vollständig ist. Er hört auf, wenn ihm die Schritte ausgehen.
  2. Der Pfad ist zufällig. Wo der Agent zuerst hinschaut, entscheidet, was er findet. Zwei Läufe mit derselben Frage liefern zwei verschiedene Konzepte. Für ein Dokument, auf dem ein Projekt aufbaut, ist das ein ernstes Problem.
  3. Code zeigt nicht Nutzung. Ein Z-Programm zu lesen sagt nichts darüber, ob es jemand ausführt. Customizing zu lesen sagt nichts darüber, welche Prozessvariante das Volumen trägt. Genau diese Unterscheidung trägt aber jede Scope-Entscheidung.
  4. Das Ergebnis liest sich gut. Das ist das Tückische. Ein flüssig geschriebenes, plausibel klingendes Fachkonzept, dessen Lücken man erst im Test bemerkt, ist teurer als gar keines.

Dazu kommt der architektonische Preis: ein Agent mit offener Verbindung ins System, der zur Laufzeit selbst entscheidet, was er liest. Warum das eine eigene Diskussion verdient, steht in Attached vs. Detached.

Die eigentliche Trennlinie

Agent am System KI sucht und schreibt

Das Modell muss gleichzeitig herausfinden, was relevant ist, und daraus einen Text formen. Beides unbeaufsichtigt, in einem Durchlauf.

Struktur zuerst System liefert, KI formuliert

Extraktion und Strukturierung laufen deterministisch. Die KI arbeitet auf einem fertigen, vollständigen Ist-Bild — und tut nur noch das, was sie gut kann.

Der Unterschied ist keine Geschmacksfrage. Sprachmodelle sind stark darin, Zusammenhänge zu formulieren, zu gliedern und Sprache zu erzeugen. Sie sind schwach darin, eigenständig Vollständigkeit herzustellen. Wer beides in einen Lauf packt, bekommt die Schwäche im Fundament des Ergebnisses.

Der strukturierte Ansatz

Die Reihenfolge macht den Unterschied:

  • Extrahieren. Aus dem SAP-System kommt einmalig heraus, was gebraucht wird — Belegdaten, Customizing, Repository-Informationen, Nutzungsdaten. Definiert, nicht agentengesteuert.
  • Strukturieren. Daraus entsteht deterministisch das Ist-Bild: die realen End-to-End-Prozesse aus den Belegflüssen, eine Feature Map aus implementierten und tatsächlich genutzten Funktionen, die Eigenentwicklungen mit fachlichem Kontext und Nutzung, die Stammdatenqualität. Kein Modell im Spiel — nur Daten.
  • Formulieren lassen. Erst jetzt kommt die KI ins Spiel, und zwar auf einem Bestand, der bereits vollständig, benannt und verlinkt ist. Sie muss nichts mehr suchen. Sie gliedert, verdichtet und schreibt — mit Verweisen auf konkrete Prozesse, Features und Objekte, die man aufklappen und prüfen kann.

Was daraus entsteht, ist überprüfbar. Jede Aussage im Konzept hängt an einem Datenpunkt, und der Extrakt ist das vollständige Protokoll dessen, was zugrunde lag. Ein zweiter Lauf liefert dasselbe Fundament — nicht denselben Text, aber dieselben Fakten.

Und noch etwas wird dadurch möglich, das beim frei laufenden Agenten prinzipiell fehlt: Nachvollziehbarkeit der Entscheidungen. Warum steht eine Prozessvariante im Scope und eine andere nicht? Warum ist dieses Z-Programm als abzulösen markiert? Weil die Quelle danebensteht — die Belegzahlen, die Nutzungsdaten, das konkrete Objekt. Man kann jede Einordnung im Konzept aufklappen, bis auf die Daten, aus denen sie stammt, und ihr dort widersprechen. Beim Agenten am System bleibt am Ende nur ein Text und die Frage, worauf er eigentlich beruht.

Ein Fachkonzept hat immer ein Ziel

Ein Ist-Bild ist noch kein Konzept. Ein Fachkonzept schreibt man, weil man etwas vorhat — und genau dieses Vorhaben bestimmt, welcher Ausschnitt des Ist-Bilds relevant ist und wo die Soll-Diskussion überhaupt beginnt:

  • Optimierung im Bestand — Varianten reduzieren, Sonderwege abschaffen, Standard zurückgewinnen.
  • Neue Module oder Prozesse — was existiert schon an Vorleistung, welche Stammdaten tragen, wo hakt es.
  • Brownfield, Bluefield, Greenfield — jede der drei Optionen braucht ein anderes Konzept aus derselben Faktenlage: Was wird übernommen, was neu gebaut, was fällt weg. Und wie weit ist der gelebte Prozess vom Public-Cloud-Standard entfernt.

Dasselbe strukturierte Fundament, verschiedene Blickrichtungen. Das ist der eigentliche Gewinn: Man erhebt einmal und konzipiert mehrfach, statt für jede Frage neu ins System zu gehen.

Was ehrlich dazugehört

Zwei Einschränkungen, die man nicht wegdiskutieren sollte.

Die Qualität hängt am Modell. Welcher LLM-Provider hinter dem Schreibschritt steht, macht einen spürbaren Unterschied in Gliederung, Präzision und Sprache. Ein strukturiertes Fundament hebt jedes Modell — aber es macht kein schwaches Modell zu einem starken.

KI schreibt Entwürfe, keine Entscheidungen. Ein generiertes Fachkonzept ist ein belastbarer erster Wurf, der Wochen an Fleißarbeit spart. Was übernommen, gestrichen und neu entschieden wird, bleibt Sache der Menschen, die das Projekt verantworten. Der Unterschied zum Agenten-Durchlauf ist: Man diskutiert über Inhalte statt darüber, ob die Grundlage überhaupt stimmt.

Nicht die KI vom System bremsen ist der Punkt — sondern ihr die Arbeit abnehmen, für die sie nicht gebaut ist.


Genau so ist Conjola gebaut: ein Extrakt aus Ihrem System, daraus in rund 24 Stunden ein strukturiertes Ist-Bild aus Prozessen, Feature Map, Custom Code und Stammdaten — und eine Knowledge Base, in der Ihre Konzepte direkt neben diesen Daten liegen und mit ihnen verlinkt sind. Dort entstehen Ihre Fachkonzepte KI-gestützt: Sie schreiben, der Assistent entwirft Kapitel, verdichtet und prüft gegen den echten Datenbestand — ausschließlich auf diesem Bestand. Die Hoheit über das Dokument bleibt bei Ihnen. Ohne Live-Verbindung in Ihr SAP-System — durchgehend detached.