AI ist kein Technologie-Thema – sondern eine Frage des Prozessverständnisses

Die meisten AI-Vorhaben beginnen mit der falschen Frage – welches Modell, welche Plattform, welcher Hyperscaler. Der Nutzen entsteht aber nicht im Modell, sondern im Prozess, in den das Modell eingebettet wird: an den Entscheidungspunkten, den Ausnahmeschleifen, den Übergaben zwischen Fachbereich und System. Dieser Insight zeigt an drei SAP-Prozessen (O2C, Materialstammdaten, Qualitätsprüfung), warum Prozessverständnis das eigentliche Engpass-Wissen ist – und welche Rolle AI Hub, HANA Cloud Vector Engine, Joule und ein BTP-/CAP-Side-by-Side erst danach spielen.

Die falsche Frage zuerst

Fast jedes AI-Vorhaben startet mit einer technischen Frage: Welches Modell? SAP AI Hub oder direkt über Microsoft Azure? Welcher Hyperscaler, welche Region? RAG über die HANA Cloud Vector Engine oder ein externer Store? Diese Fragen sind nicht falsch – sie sind nur zu früh gestellt. Sie beantworten das „Womit", bevor das „Wofür" geklärt ist.

Der Nutzen eines AI-Use-Case entsteht nicht im Modell. Er entsteht in dem Prozess, in den das Modell eingebettet wird – an den Entscheidungspunkten, an denen heute ein Mensch auf unvollständiger Information urteilt, an den Ausnahmeschleifen, die niemand dokumentiert hat, an den Übergaben zwischen Fachbereich und System. Wer diesen Prozess nicht versteht, kauft ein Modell, das keine Frage beantwortet.

Wert entsteht im Prozess, nicht im Modell

Ein Sprachmodell ist heute eine Ware. Zwei Anbieter liefern für dieselbe Klassifikations- oder Extraktionsaufgabe vergleichbare Qualität, und die Lücke schliesst sich quartalsweise weiter. Was sich nicht kopieren lässt, ist das Wissen darüber, wie ein Bestellprozess in Ihrem Haus wirklich läuft – mit welchen Sonderfällen, welchen Freigabegrenzen, welchen Altlasten im Customizing.

Genau dieses Wissen ist das Engpass-Wissen. Der Hebel liegt selten im letzten Prozentpunkt Modellgüte, sondern in der Frage, an welcher Stelle des Prozesses eine Vorhersage überhaupt eine Entscheidung verändert. Eine korrekte Klassifikation, die niemand im Prozess weiterverarbeitet, erzeugt keinen Wert – nur Rechenkosten.

Drei Fragen, die jedem AI-Use-Case vorausgehen

Bevor wir über Modell oder Plattform sprechen, klären wir mit dem Fachbereich drei Prozessfragen:

  1. Wo im Prozess fällt eine Entscheidung auf unvollständiger Information? Dort, wo heute geschätzt, nachtelefoniert oder „aus Erfahrung" entschieden wird, liegt der Kandidat – nicht dort, wo eine Regel ohnehin eindeutig ist.
  2. Was passiert mit der Ausnahme? Ein Prozess ist im Normalfall langweilig. Der Aufwand steckt in den 10–20 % Ausnahmen. Ein AI-Use-Case, der die Ausnahme nicht mitdenkt, verschiebt nur die Arbeit – er reduziert sie nicht.
  3. Wer übernimmt das Ergebnis – und wann darf der Mensch widersprechen? Ohne klaren Übergabepunkt und ohne nachvollziehbare Begründung bleibt jede Vorhersage ein Vorschlag, den niemand verantworten will.

Diese drei Fragen entscheiden über Erfolg oder Stillstand – lange bevor das erste Embedding berechnet ist.

Beispiel 1 – Order-to-Cash: der Agent ist das letzte Fünftel

Ein agentischer Order-to-Cash-Workflow (usecase.ai.agent-end-to-end-o2c) klingt nach Technik: ein Agent liest die eingehende Bestellung, legt den Kundenauftrag in S/4HANA an, prüft Verfügbarkeit, meldet zurück. Der Wert hängt aber nicht am Agenten, sondern an der Frage, die ein Maschinenbauer beantworten muss: Was tut der Prozess heute, wenn die Bestellung mehrdeutig ist? Falsche Materialnummer, abweichende Mengeneinheit, Konditionen ausserhalb des Rahmens, Teil-Lieferfähigkeit.

Erst wenn diese Ausnahmen kartiert sind, lohnt sich die Technik: der Agent auf SAP BTP mit CAP, sauber gegen das Clean Core gebaut statt über Modifikationen, mit AI Hub als Modell-Layer und einem klaren Übergabepunkt an den Innendienst, sobald die Konfidenz fällt. Der Agent erledigt die langweiligen 80 % – die kartierte Ausnahme bleibt beim Menschen, mit Beleg.

Beispiel 2 – Materialstammdaten: Klassifikation ist ein Governance-Prozess

Die GPC-/eCl@ss-Klassifikation von Materialstammdaten (usecase.ai.gpc_product_classifier) wirkt wie eine reine Modell-Aufgabe: Text rein, Klasse raus. In Wirklichkeit ist sie ein Governance-Prozess. Wer darf eine Klassifikation überschreiben? Was passiert, wenn das Modell unsicher ist – Dunkelverarbeitung oder Vier-Augen-Prinzip? Wie fliesst eine korrigierte Klasse zurück, damit der nächste Lauf besser wird?

Ein Industriekomponenten-Hersteller gewinnt hier nicht durch ein grösseres Modell, sondern durch eine Taxonomie-Disziplin: klare Klassen, definierte Schwellen für die Dunkelverarbeitung, eine Rückschreibe-Strecke nach S/4HANA und in die Datasphere als Reporting-Schicht. Die Modellwahl ist dann fast nebensächlich.

Beispiel 3 – Qualitätsprüfung in der Fertigung

In der Wareneingangs- und Fertigungsprüfung (usecase.sap.qm-quality-inspection-genai) soll GenAI Prüfbefunde aus Bildern und Freitext strukturieren. Der Engpass ist nicht das Vision-Modell – es ist die Fehler-Taxonomie. Welche Defektklassen kennt das QM-Modul, wie hängen sie an den Prüfmerkmalen, wann führt ein Befund zur Sperrung und wann zur Nacharbeit? In einem Pharma-Umfeld kommt die GxP-Frage dazu: jede Vorhersage braucht einen prüfbaren Beleg und einen Audit-Trail, sonst ist sie für die Freigabe wertlos.

Auch hier gilt: erst der Prüfprozess, dann das Modell. Die HANA Cloud Vector Engine für die Suche nach ähnlichen Befunden und Joule als eingebetteter Einstieg im Fiori-Umfeld kommen danach.

Wo Technik dann doch zählt – als Folge, nicht als Anfang

Nichts davon spielt die Architektur klein. Sobald der Prozess verstanden ist, wird die technische Entscheidung wichtig und konkret:

Diese Bausteine sind das letzte Fünftel der Arbeit. Sie sind notwendig – aber sie sind nicht der Anfang.

Daten folgen dem Prozess

Datenqualität ist kein separates Projekt, das man „vorher" erledigt. Sie ergibt sich aus dem Prozessverständnis: Welche Daten produziert der Prozess an welchem Schritt, in welcher Güte, mit welcher Klassifikation? Wer den Prozess kennt, weiss, welche Felder belastbar sind und welche nur scheinbar gepflegt werden. Diese Sicht ist die Voraussetzung für jedes RAG-Setup – nicht eine nachgelagerte Aufräumarbeit.

Messbar machen: Prozess-KPIs statt „AI-Reifegrad"

Den Erfolg eines AI-Use-Case misst man am Prozess, nicht am Modell. Durchlaufzeit eines Kundenauftrags, Anteil der Dunkelverarbeitung in der Stammdatenpflege, Quote der Prüfbefunde mit vollständigem Beleg – das sind belegbare Grössen vor und nach dem Eingriff. Ein abstrakter „Reifegrad" sagt nichts darüber, ob ein Prozess heute schneller, sicherer oder nachvollziehbarer läuft.

Wer das eigentlich verantwortet

Der natürliche Eigentümer eines AI-Use-Case ist nicht die IT, sondern der Process Owner – die Person, die den Prozess und seine Ausnahmen kennt. Die IT liefert Plattform, Betrieb und Mandanten- schutz; der Fachbereich liefert das Engpass-Wissen. AI-Vorhaben, die ohne Process Owner gestartet werden, scheitern selten an der Technik und fast immer am fehlenden Prozessbild.

Was Sie mit uns klären können

Ein guter Einstieg ist eine Standortbestimmung (60 Min): Wir gehen zwei bis drei Ihrer Prozesse durch und prüfen entlang der drei Prozessfragen, wo ein AI-Use-Case eine Entscheidung wirklich verändert – und wo nicht. Für die Tiefe eignet sich ein Workshop (halbtägig), in dem wir einen Kandidaten-Prozess kartieren, die Ausnahmen aufnehmen und erst dann die Architektur auf SAP BTP, AI Hub und HANA Cloud Vector Engine skizzieren. Wenn Sie vorab nur eine Einordnung brauchen, genügt eine Rückfrage per E-Mail.

SFOUR Consulting — Übersicht · Kontakt