SAP ohne Bildschirm? Welche Prozesse künftig keine klassische App mehr brauchen
„Warum ist die Lieferung noch nicht raus?“
Eine einfache Frage. Um sie zu beantworten, muss ein Mitarbeiter möglicherweise erst den Auftrag finden, die Lieferung öffnen, Status prüfen und Rückfragen aus einem anderen System hinzunehmen. Am Ende braucht er zwei Sätze und eine klare Aussage dazu, wer als Nächstes handeln muss.
Genau hier sehe ich Potenzial für eine andere Art, mit SAP zu arbeiten. Der Anwender beschreibt sein Anliegen. Das System stellt die benötigten Informationen zusammen und bietet einen passenden nächsten Schritt an.
Meine These: Für klar abgegrenzte Aufgaben könnte künftig der Weg durch eine klassische App entfallen. Visuelle Oberflächen würden dann vor allem dort gebraucht, wo Menschen vergleichen, prüfen und entscheiden müssen.
„Ohne Bildschirm“ ist dabei bewusst zugespitzt. Auch ein Chat hat eine Oberfläche. Interessant ist, ob Anwender weiterhin durch mehrere Masken navigieren müssen, um ihr Ziel zu erreichen.
Was Joule bereits zeigt
SAP beschreibt für Joule unterschiedliche Interaktionsmuster: Informationen finden, zu Anwendungen navigieren, Aktionen ausführen und Daten analysieren. Ein Dialog kann mehrere dieser Schritte verbinden. Damit ist die Idee, eine Aufgabe in natürlicher Sprache zu beginnen und bei Bedarf in eine Anwendung zu wechseln, bereits Teil des beschriebenen Bedienkonzepts. SAP Learning: How to Interact with Joule
Daraus folgt für mich eine neue Frage bei der Anwendungsplanung: Welcher Teil einer Aufgabe braucht überhaupt noch eine eigene Maske?
Die folgenden Szenarien sind bewusst konstruierte Zielbilder. Sie beschreiben mögliche Prozessgestaltung und sind keine Zusage, dass Joule diese Abläufe in einem bestimmten SAP-System bereits vollständig unterstützt. Das wäre je Lösung, Funktionsumfang und Systemkonfiguration konkret zu prüfen.
Statusfragen könnten ohne Appwechsel auskommen
Bei der Frage nach einer Lieferung würde ich mit einem lesenden Szenario beginnen. Eine hilfreiche Antwort müsste den aktuellen Zustand benennen und ihn mit den zugrunde liegenden Belegen verknüpfen.
Zum Beispiel:
Zur Lieferung fehlt noch die bestätigte Kommissionierung. Ein Warenausgang wurde bisher nicht gebucht. Datenstand: 10:42 Uhr. Lieferung öffnen.
Das wäre eine belastbare Statusauskunft. Die Aussage „Das Lager ist überlastet“ wäre dagegen nur dann vertretbar, wenn dafür zusätzliche, verlässliche Informationen vorliegen. Ein fehlender Status allein erklärt noch keine Ursache.
Für einen gelegentlichen Nutzer könnte diese Auskunft den gesamten Arbeitsgang abdecken. Wer die Lieferung bearbeiten muss, öffnet den verlinkten Beleg. Beide erhalten einen passenden Einstieg, ohne zunächst dieselbe Navigation durchlaufen zu müssen.
Voraussetzung wäre, dass das System eindeutig weiß, welche Lieferung gemeint ist. Bei mehreren Treffern gehört eine Auswahl dazu. Auch Berechtigungen und Datenstand müssen berücksichtigt werden.
Meldungen könnten im Arbeitskontext entstehen
Ein zweites Beispiel ist eine Störungsmeldung in der Instandhaltung. Ein Mitarbeiter steht an einer Anlage und beschreibt:
An Pumpe P-204 tritt Flüssigkeit an der Dichtung aus. Seit dem Schichtbeginn ist das Geräusch deutlich lauter.
Eine passende Anwendung könnte die Beschreibung als Entwurf übernehmen, das technische Objekt zur Auswahl stellen und gezielt fehlende Angaben abfragen. Ein Foto ließe sich ergänzen. Vor dem Anlegen sieht der Mitarbeiter kompakt, was gespeichert wird.
Hier könnte natürliche Sprache die Erfassung erleichtern. Ob sie gesprochen oder getippt wird, hängt vom Arbeitsplatz ab. In einer lauten Halle würde ich Spracheingabe erst unter realen Bedingungen testen. Ein Scan des Anlagenkennzeichens und wenige gezielte Eingaben könnten zuverlässiger sein.
Die KI sollte dabei Beobachtung und Interpretation auseinanderhalten. „Ungewöhnliches Geräusch“ ist eine gemeldete Beobachtung. „Lagerschaden“ wäre bereits eine Diagnose. Eine plausibel klingende Ergänzung darf nicht unbemerkt zum dokumentierten Befund werden.
Kleine Änderungen brauchen vor allem einen klaren Auftrag
Auch eine eng begrenzte Änderung könnte ohne vollständige Bearbeitungsmaske auskommen. Denken wir an eine interne Notiz zu einem eindeutig ausgewählten Vorgang oder an das Vorbereiten einer Bestellanforderung aus einer Beschreibung.
Die Grenze liegt für mich dort, wo wesentliche Entscheidungen verborgen würden. „Bestell wieder das Gleiche wie letztes Mal“ lässt offen, welcher frühere Vorgang gemeint ist und welche Angaben übernommen werden sollen. Lieferant, Menge, Preis und Kontierung dürfen nicht aus einer unklaren Formulierung heraus stillschweigend festgelegt werden.
Ich würde daraus zunächst einen sichtbaren Vorschlag machen. Der Nutzer prüft die entscheidenden Angaben und löst die vorgesehene Aktion aus. Bestehende Genehmigungsregeln gelten weiterhin.
Bestätigungen sollten zur Wirkung der Handlung passen. SAP empfiehlt in seinem Joule-Design für iOS einen Bestätigungsschritt insbesondere bei folgenreichen oder schwer rückgängig zu machenden Aktionen und warnt zugleich vor zu vielen Bestätigungen. SAP Design System: Confirmation Step
Ein allgemeines „Sind Sie sicher?“ hilft wenig. Sichtbar sein sollten der betroffene Vorgang und die konkrete Änderung.
Wo ich die Oberfläche behalten würde
Bei einer einzelnen Statusfrage kann eine kurze Antwort genügen. Bei zwanzig verspäteten Bestellungen möchte ein Einkäufer vielleicht Lieferanten, Mengen, Termine und Auswirkungen nebeneinander sehen. Dafür würde ich eine filterbare Tabelle vorsehen.
Ähnlich ist es bei der Produktionsplanung. Eine Frage wie „Welche Aufträge sind gefährdet?“ eignet sich als Einstieg. Sobald Kapazitäten, Materialverfügbarkeit und Terminverschiebungen gemeinsam bewertet werden, braucht der Planer eine Darstellung dieser Zusammenhänge.
Auch bei hoher Wiederholung kann direkte Bedienung überlegen sein. Wer täglich viele gleichartige Positionen bearbeitet, sollte dafür keinen langen Dialog führen müssen. Tastaturbedienung, Mehrfachauswahl und eine gut aufgebaute Liste können genau das passende Werkzeug sein.
Ich erwarte deshalb einen Wechsel zwischen verschiedenen Darstellungen: eine Frage als Einstieg, eine Tabelle zum Vergleich, eine Detailansicht zur Prüfung und eine kompakte Aktion zum Abschluss. Der bereits gewählte Vorgang und die Filter sollten beim Wechsel erhalten bleiben.
Weniger Masken verlangen klare fachliche Funktionen
Für die Entwicklung hat das eine wichtige Konsequenz. Eine Funktion muss unabhängig davon verständlich und kontrollierbar sein, ob sie aus einer App, einem Dialog oder einem automatisierten Ablauf aufgerufen wird.
Für eine Aktion wie „Meldung anlegen“ würde ich deshalb festlegen, welche Angaben benötigt werden, welche Prüfungen gelten und welches Ergebnis zurückgegeben wird. Berechtigungen und fachliche Regeln müssen im ausführenden System durchgesetzt werden. Eine Anweisung im Prompt ersetzt diese Prüfungen nicht.
Ebenso wichtig ist ein eindeutiger Ausgang. Wenn die Verbindung nach dem Speichern abbricht, darf ein erneuter Versuch nicht unbemerkt eine zweite Meldung erzeugen. Für Nutzer und Support muss erkennbar bleiben, ob die Aktion erfolgreich war, gescheitert ist oder noch geprüft werden muss.
Das ist anspruchsvolle Prozess- und Schnittstellenarbeit. Der sichtbare Dialog ist nur der Zugang dazu.
Womit ich anfangen würde
Ich würde eine häufige, klar abgegrenzte Statusfrage auswählen, deren Antwort heute mehrere Aufrufe erfordert. Zuerst lesend, mit eindeutiger Belegzuordnung, Datenstand und einem direkten Weg zur Detailansicht.
Den Nutzen würde ich daran messen, ob Anwender schneller zu einer korrekten Antwort kommen. Dazu gehören auch Rückfragen, falsche Zuordnungen und Fälle, in denen doch die klassische App benötigt wird. Die Zahl eingesparter Klicks allein wäre mir zu wenig.
Erst danach würde ich eine eng begrenzte schreibende Aktion ergänzen und sie mit den tatsächlichen Nutzern testen.
Für neue SAP-Anwendungen möchte ich deshalb früher über die notwendige Interaktion sprechen: Was muss ein Mensch sehen? Was muss er entscheiden? Welche Informationen kann das System bereits zuverlässig ermitteln?
Aus diesen Antworten ergibt sich, wie viel Oberfläche die Aufgabe braucht. Manchmal eine vollständige Fiori-App. Manchmal eine kleine Ergebniskarte. Und manchmal könnte die Arbeit bereits mit einer nachvollziehbaren Antwort erledigt sein.
