Polski (PL) 
English (United Kingdom) 
Unabhängige IFS-Cloud-Beratung · Automatisierung & Governance
Was KI in Ihrem ERP nicht billiger gemacht hat
Auf einen Blick
- Ein Sprachmodell entwirft in Minuten eine OData-Abfrage gegen Ihre IFS-Cloud-Projections. Automatisierungscode zu schreiben ist damit fast kostenlos geworden.
- Die Verantwortung dafür, was dieser Code um sechs Uhr morgens unbeaufsichtigt in einem laufenden ERP tut, ist nicht billiger geworden, weil das Modell keinen Namen unter das Ergebnis setzen kann.
- Ein lauffähiges Skript und eine Automatisierung mit Eigentümer, Prüfung und begrenztem Wirkungsbereich sind zwei unterschiedliche Lieferergebnisse, auch wenn der Code identisch ist.
- Bevor Sie etwas KI-Gestütztes an IFS Cloud anschließen, stellen Sie eine Frage: Wessen Name steht darauf, wenn es um 6 Uhr schiefgeht?
Die Abfrage zu schreiben ist dieses Jahr fast kostenlos geworden. Richtet man ein Modell auf Ihre IFS-Cloud-Projections, liefert es in Minuten einen funktionierenden OData-Aufruf, Arbeit, die einen Entwickler früher einen halben Tag kostete. Das ist nützlich und echt. Es verschiebt aber den schwierigen Teil der ERP-Automatisierung an eine andere Stelle: Der Code ist nicht länger das knappe, wertvolle Gut. Nicht billiger geworden ist das Einstehen für das, was der Code tut, sobald er unbeaufsichtigt gegen laufende Bestellungen, Lieferanten und Kunden läuft, zu einer Uhrzeit, zu der niemand zusieht. Dieser Artikel behandelt die Lücke zwischen dem Erzeugen von Automatisierung und der Verantwortung dafür, und warum sie wichtiger wird, je leichter sich Automatisierung erzeugen lässt.
1.Warum die Lücke jetzt entsteht
Bei ERP-Anpassungen war die Knappheit lange technischer Art: Jemand musste das Schema kennen, PL/SQL beherrschen und wissen, wie Projections und Custom Events in IFS Cloud tatsächlich zusammenspielen. Diese Knappheit wirkte als zufälliger Filter. Wer die Automatisierung schreiben konnte, hatte im System im Normalfall auch genug Zeit verbracht, um ein Gespür dafür zu haben, was bei echten Daten schiefgehen kann.
Ein Modell entfernt den technischen Filter, ohne das Urteilsvermögen zu liefern, das früher mitgeliefert wurde. Wer IFS Cloud nie geöffnet hat, bekommt heute in Minuten einen plausibel aussehenden PL/SQL-Block oder OData-Aufruf. Der Code mag durchaus korrekt sein. Es fehlt der Teil, bei dem es nie ums Schreiben von Code ging: zu wissen, was genau diese Abfrage beim ersten Lauf über fünf Jahre Historie tut, an einem Montagmorgen, wenn die E-Mails, die sie auslöst, bei echten Lieferanten ankommen.
2.Was fehlende Verantwortung tatsächlich kostet
Nichts, bis die Automatisierung etwas tut, was sie nicht hätte tun dürfen. Dann kommt die Rechnung auf einmal.
- Ein Fehler nach außen. Ein erster Lauf ohne Eingrenzung und ohne Mengenbegrenzung kann Hunderte Lieferanten oder Kunden mit einer Nachricht anschreiben, die sie nie hätten bekommen sollen, mit dem Namen Ihres Unternehmens darunter.
- Unbegrenzter Wirkungsradius. Code, der gegen einen Testfall korrekt aussieht, kann sich beim ersten Lauf gegen die gesamte Historie einer produktiven Tabelle völlig anders verhalten, und niemand hat festgelegt, was der volle Lauf tatsächlich bewirkt.
- Niemand, den man um 6 Uhr anruft. Wenn ein generiertes Skript nachts unerwartet anläuft, braucht die Organisation einen Namen, der es erklären, stoppen und beheben kann, kein Chat-Protokoll.
- Vertrauen läuft der Prüfung davon. Code, der sofort erscheint und gepflegt aussieht, wird weniger kritisch gelesen als Code, an dem ein Entwickler einen Tag gesessen hat, und zwar genau dann, wenn er genauere Prüfung verdient.
Ein Modell übernimmt keine Schuld. Es hat keinen Namen, den man unter das Ergebnis setzen kann.
3.Wo sich das in einer IFS-Cloud-Landschaft zeigt
Es zeigt sich eher als Custom Event oder geplanter Task, den im Change-Review niemand recht erklären kann, als in einem dramatischen Ausfall: Die Logik ist stimmig, aber ihr Autor kann aus dem Kopf nicht sagen, was beim ersten Produktivlauf gegen fünf Jahre Bestellhistorie geschieht oder wer die Empfängerliste vor dem Go-live geprüft hat.
Verräterisch ist die einzeilige Antwort auf eine zweiteilige Frage. Was eine generierte Automatisierung tun soll, lässt sich erklären. Schwieriger wird es bei den Fragen, ohne Nachschlagen zu beantworten: wer den Lauf gegen Produktion freigegeben hat, wie groß der Wirkungsradius ist, falls die zugrunde liegende Annahme falsch war, und wer alarmiert wird, wenn sie danebengeht.
4.KI-entworfener Code und verantwortete Automatisierung im Vergleich
Der Code selbst kann identisch sein. Die beiden Spalten trennt alles, was um ihn herum liegt.
| KI-entworfenes Skript | Verantwortete Automatisierung | |
|---|---|---|
| Autor im Protokoll | Wer es eingegeben hat, informell | Ein benannter Eigentümer, dokumentiert |
| Verhalten beim ersten Lauf | Nicht gegen die gesamte Historie getestet | Probelauf (Dry-run) gegen Echtdaten vor dem Go-live |
| Wirkungsradius | Unbekannt, bis es läuft | Vorab eingegrenzt und mengenbegrenzt |
| Wer alarmiert wird | Wer es zuerst bemerkt | Ein definierter Eigentümer mit Kontext |
| Update-Sicherheit | Nicht bedacht | Innerhalb des Extensibility Framework gebaut |
Nichts davon spricht dagegen, die Abfrage mit KI zu entwerfen: Sie beschleunigt den Teil der Arbeit, der nie der riskante war. Es spricht dafür, den Entwurf als Ausgangspunkt zu behandeln, der weiterhin einen Eigentümer braucht, und nicht als fertiges Ergebnis, nur weil er ohne Fehler lief.
5.KI-gestützt entwerfen und die Verantwortung behalten
Das Ziel ist nicht, das Entwerfen zu bremsen, sondern die Verantwortung nachzuziehen, bevor etwas Produktion berührt.
- Vor dem ersten Lauf einen Eigentümer benennen. Wer ein generiertes Skript beauftragt oder übernimmt, setzt seinen Namen darunter, nicht das Werkzeug, das beim Schreiben half.
- Zuerst einen Dry-run gegen die echte Historie fahren. Die erste Ausführung gegen fünf Jahre Bestellungen läuft in einem Modus, der protokolliert, was geschehen wäre, und nichts tatsächlich versendet.
- Den Wirkungsradius ausdrücklich eingrenzen. Begrenzen Sie die Menge, schränken Sie die Empfänger ein und setzen Sie für alles, was extern mailt oder schreibt, ein Mengenlimit, bis das Verhalten erwiesen ist.
- Vor dem Go-live prüfen, jedes Mal. Eine zweite Person prüft die Logik und die Ausgabe des Dry-runs. Die KI-gestützte Herkunft verdient keine Abkürzung, sondern dieselbe Prüfung wie jeder andere Eigencode.
- Im Extensibility Framework bleiben. Gleich, was den ersten Entwurf erzeugt hat: Die ausgelieferte Regel besteht aus Standard-Custom-Events, Workflows und PL/SQL. Sie ist update-sicher, ändert nichts am Kern und lässt sich von einem Menschen prüfen, den man alarmieren kann.
Dieselbe Disziplin, die Custom Events und einen Clean Core wartbar hält, gilt unabhängig davon, ob ein Mensch oder ein Modell die erste Fassung entworfen hat. KI ändert, wer den ersten Entwurf schreibt, nicht, wer für das Ergebnis geradesteht.
Technisches 30-Minuten-Gespräch buchen SCM Automation Pack ansehen
6.Fragen und Antworten
Raten Sie davon ab, KI für IFS-Cloud-Automatisierung zu nutzen?
Nein. Ein Modell für den Entwurf einer Abfrage oder einer ersten Logikfassung zu nutzen, spart zu Recht Zeit. Entwerfen und Verantworten sind aber zwei getrennte Aufgaben: Auch ein generierter Entwurf braucht einen benannten Eigentümer, einen Dry-run und eine Prüfung, bevor er Produktion berührt.
Was ist das größte Risiko KI-gestützter Automatisierung in einem laufenden ERP?
Ein erster Lauf ohne Eingrenzung: Code, der gegen einen kleinen Testfall geprüft wurde, kann sich beim ersten Durchlauf der gesamten Historie einer produktiven Tabelle völlig anders verhalten, und weil es weder Mengenlimit noch Dry-run gibt, erreicht der Fehler echte Lieferanten oder Kunden.
Wie unterscheidet sich das von jedem anderen Code-Review?
Grundsätzlich gar nicht. KI-generierter Code verdient dieselbe Prüfung wie jeder andere ERP-Eigencode, nur verführt sein gepflegtes, sofortiges Erscheinungsbild dazu, diesen Schritt zu überspringen.
Ist so gebaute Automatisierung update-sicher?
Ja, sofern die ausgelieferte Regel (unabhängig davon, wie der erste Entwurf entstand) aus Standard-Custom-Events, Workflows und PL/SQL im IFS Extensibility Framework besteht und keine Änderung am Kern enthält, die das nächste Release brechen könnte.
7.Über den Autor
Dariusz Myśliwiec: 18 Jahre Praxis mit IFS (Apps 7.5 bis 10 und IFS Cloud). Ich bin IFS Certified Associate Consultant und nach PRINCE2® 7 zertifiziert. Unabhängige Beratung mit Sitz in Krakau, remote tätig in Europa und weltweit. Sie sprechen direkt mit dem Berater, der die Arbeit ausführt.
Ausgewählte Kunden: Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm.
IFS ist eine eingetragene Marke der IFS AB. Diese Beratung steht in keiner Verbindung zur IFS AB.
Die Frage nach 6 Uhr morgens vorher stellen
Gleich, was die erste Fassung entworfen hat: In einem 30-Minuten-Gespräch grenzen wir Wirkungsradius, Dry-run und Eigentümer ein, bevor etwas KI-Gestütztes laufende Bestellungen, Lieferanten oder Kunden berührt.
