Polski (PL) 
English (United Kingdom) 
Sprechende Artikelnummer im ERP: Ja oder Nein in IFS Cloud?
IFS Cloud · Datenmigration · Artikelstamm Sprechende Artikelnummer im ERP: Warum Sie das Schema vor dem ersten Laden festlegen Eine sprechende Artikelnummer im…
Read moreSprache auswählen
Sprache auswählen
IFS Cloud · Datenmigration · Artikelstamm Sprechende Artikelnummer im ERP: Warum Sie das Schema vor dem ersten Laden festlegen Eine sprechende Artikelnummer im…
Read moreUnabhängige IFS-Cloud-Praxis · Einführung Testergebnisse, die als Beleg taugen: Systemlandschaft und Datenkopie in IFS Cloud Eine IFS Cloud Testumgebung…
Read moreUnabhängige IFS-Cloud-Beratung · Einführung Festlegen, was das Altsystem behält, wer es öffnen darf und wann es abgeschaltet wird Für die…
Read moreUnabhängige IFS-Cloud-Beratung · Anpassungen Warum Dialoge und Assistants in IFS Cloud kein Custom Field annehmen und was Sie stattdessen bauen Ein IFS Cloud…
Read moreUnabhängige IFS-Cloud-Beratung · Vertrieb Der Preis läuft ab, die Aufträge laufen weiter Läuft in einer Kundenpreisvereinbarung in IFS Cloud (oder einer…
Read moreUnabhängige IFS-Cloud-Beratung · Supply Chain Was Ihr ERP-Berater Ihnen nicht gesagt hat: Der Prozess driftet Prozessabweichung nach dem Go-live (Prozessdrift)…
Read moreUnabhängige IFS-Cloud-Beratung · Supply Chain Drei Bestellzustände, die niemand hinterfragt. Um einen davon kümmert sich keiner. Eine Bestellung in IFS Cloud…
Read moreUnabhängige IFS-Cloud-Beratung · Erweiterbarkeit Quick Report, Custom Field oder Custom Event: was Sie in IFS Cloud wann einsetzen Quick Reports, Custom Fields…
Read moreUnabhängige IFS-Cloud-Beratung · Datenmigration IFS Cloud Datenmigration mit FndMig und DMM: ein Leitfaden aus der Praxis Die Datenmigration ist die Phase, an…
Read more
Unabhängige IFS-Cloud-Beratung · Lieferkette
Auf einen Blick
Eine Bestellung steht elf Tage im Status Released. Niemand bemerkt es. Der Liefertermin verstreicht, ohne dass ihn jemand meldet, und an Tag elf ist der Artikel immer noch nicht da. Die Produktion steht vier Stunden, weil eine Linie auf eine Komponente wartet, die rund 200 € kostet. Der Artikel ist billig. Der Linienstillstand ist es nicht: vier Stunden Leerlauf bei den Personalkosten, eine verpasste Sendung, ein Kunde, der nun einen späteren Liefertermin hat als den zugesagten. Das Verhältnis zwischen dem Preis des Artikels und den Kosten des Versäumnisses ist kein Zufallsergebnis, sondern nahe an der Routine, und genau deshalb verdient das Ausnahmemanagement größere Aufmerksamkeit, als es bekommt. Dieser Artikel zeigt, warum das Verhältnis gilt, was es treibt, wie Sie die Lücke sehen, bevor sie zum Stillstand wird, und wie Sie sie schließen, ohne jeden Einkäufer zum Vollzeit-Ausnahmejäger zu machen.
An den elf Tagen war nichts verborgen. Der Bestellstatus stimmte, der Liefertermin stimmte. Die Information, um das Problem an Tag zwei statt an Tag elf zu fangen, lag die ganze Zeit in IFS Cloud. Es fehlte nicht an Daten, sondern an jemandem, der dieses Feld bei dieser Bestellung ansah, bevor es darauf ankam.
Das ist die Falle bei Ausnahmen mit geringem Wert. Wer einen Bildschirm voller offener Bestellungen durchgeht, verteilt seine Aufmerksamkeit selbstverständlich nach dem Wert: Die Bestellung über 80.000 € bekommt einen zweiten Blick, die Position über 200 € nicht. Die Kosten des Versäumnisses haben aber mit dem Wert des Artikels nichts zu tun. Sie hängen davon ab, was der Artikel nachgelagert freigibt (eine Linie, eine Schicht, eine Sendung), und diese Folgekosten sind in der Bestellmaske nicht zu sehen.
Die Kosten einer verpassten Prüfung stecken im Kern nicht im Material. Sie fallen nachgelagert an, an vier Stellen, die der auslösenden Ausnahme nie in Rechnung gestellt werden:
Die teuerste Ausnahme in Ihrer Lieferkette ist die, die Sie mit den vorhandenen Daten hätten verhindern können und trotzdem verpasst haben.
IFS Cloud hat bereits alles, was dafür nötig ist: Bestellstatus, Bestätigungsstatus und zugesagten Liefertermin, die an der Bestellung hängen, sobald sie angelegt ist. Eine Bestellung, die über ein sinnvolles Alter hinaus im Status Released bleibt, ohne Bestätigung und mit nahendem Liefertermin, ist ein Muster, nach dem Sie heute schon filtern können. Es ist dasselbe Signal wie bei einer unbestätigten Bestellung, nur durch die Brille des Folgerisikos statt des Lieferantenverhaltens betrachtet.
Die Lücke liegt nicht in der Sichtbarkeit. Sichtbarkeit allein verlangt, dass jemand am richtigen Tag den richtigen Filter ansieht. Eine Position über 200 € verdient diese Aufmerksamkeit an einem vollen Dienstag nicht, und deshalb braucht sie eine Regel, die unabhängig vom Wert prüft, statt eines Menschen, der daran denken muss.
Der Unterschied liegt nicht im Einsatz, denn ein guter Einkäufer arbeitet ohnehin hart. Er liegt darin, was eine Regel erfasst, das menschliche Aufmerksamkeit, so sorgfältig sie auch ist, strukturell nicht erfassen kann.
| Manuell | Systematisch | |
|---|---|---|
| Gewichtet nach | Bestellwert, instinktiv | Folgerisiko, per Regel |
| Kleine Bestellungen | Leicht zu überspringen | Geprüft wie jede andere |
| Gleichmäßigkeit | Je nach Einkäufer und Tag unterschiedlich | Dieselbe Regel, jedes Mal |
| Zeitpunkt der Erkennung | Wann immer es jemand bemerkt | An dem Tag, an dem der Schwellenwert überschritten wird |
| Schlimmster Fall | Tag elf, an der Linie | Tag zwei, am Schreibtisch |
Eine systematische Prüfung ersetzt nicht das Urteil des Einkäufers. Sie nimmt ihm den Teil der Arbeit ab, der davon abhängt, sich an etwas zu erinnern, das nicht dringend aussah. Genau das ist die Lücke zwischen der 200-€-Bestellung und dem 40.000-€-Stillstand.
Beginnen Sie eng, lassen Sie die Daten zeigen, wo das Verhältnis am stärksten zuschlägt, und erweitern Sie nach Belegen statt nach Vermutung.
Weil die Prüfung innerhalb des IFS Extensibility Framework gebaut wird (Standard-Custom-Events, Workflows und PL/SQL, keine Änderung am Kern), ist sie update-sicher und erspart den Upgrade-Aufwand, während sie weiter wacht.
Technisches 30-Minuten-Gespräch buchen SCM Automation Pack ansehen
Es liegt nahe an der Routine. Wenn ein fehlender Artikel eine Linie stoppen kann, richten sich die Kosten des Versäumnisses nicht nach dem Preis des Artikels, sondern nach dem, was die Linie pro Stunde erzeugt, und dieser Abstand ist im Normalfall groß.
Weil eine nach Bestellwert gewichtete Aufmerksamkeit Positionen mit geringem Wert zwangsläufig zu wenig prüft. Der Instinkt ist natürlich und vernünftig, für genau dieses Risiko aber falsch.
Beide Prüfungen beruhen auf demselben Signal (Bestellstatus und Termin). Die Prüfung der Folgekosten fragt jedoch nach den Kosten nachgelagert, die Überwachung unbestätigter Bestellungen nach dem Verhalten des Lieferanten. Die beiden Prüfungen ergänzen sich, statt sich zu doppeln.
Ja. Die Prüfung wird mit Standard-Custom-Events, Workflows und PL/SQL im IFS Extensibility Framework gebaut, ohne Änderung am Kern und ohne etwas, das das nächste R1/R2-Release leise bricht.
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.
Hat eine 200-€-Bestellung Sie schon einmal einen Linienstillstand gekostet, ist die Lösung kleiner als der Vorfall. In einem 30-Minuten-Gespräch lege ich eine systematische Prüfung auf Ihre Bestellstatus und Schwellenwerte aus (Festpreis, Dry-run, bevor etwas versendet wird).
Unabhängige IFS-Cloud-Praxis · Supply Chain
Auf einen Blick
Der Reflex bei Lücken im Reporting ist ein weiteres Dashboard, ein weiterer KPI, ein tieferer Schnitt derselben Zahlen. Das greift zu kurz, denn die Daten hinter den Entscheidungen, auf die es ankommt, fehlen nicht. Lagerbestand unter Minimum, eine unbestätigte Bestellung, ein Wareneingang ohne passende Rechnung, ein Auftrag in einem Status, den er vor Tagen hätte verlassen sollen: IFS Cloud hält jede dieser Tatsachen jetzt, korrekt und aktuell, in dem Moment, in dem sie wahr wird. Die Ausnahme ist nicht versteckt. Sie liegt in einer Projektion und wartet. Es fehlt die letzte Meile: die kurze Strecke zwischen dem Moment, in dem ein Datensatz den Zustand wechselt, und dem Moment, in dem eine bestimmte Person davon erfährt, solange sie noch eine Wahl hat. Dieser Beitrag gibt den Überblick über diese Idee: woher die Lücke kommt, was sie kostet und wie die Lösung aussieht, mit Verweisen auf die vertiefenden Beiträge zu einzelnen Ausnahmen.
ERP-Systeme sind dazu gebaut, Zustände genau zu erfassen, nicht zu entscheiden, wen die Änderung eines Zustands interessieren soll. Diese Arbeitsteilung war sinnvoll, solange die Alternative manuelles Reporting auf Abruf war, bei dem jemand eine Abfrage startet und jemand einen Ausdruck liest. Bei zeitkritischen Ausnahmen trägt sie nicht, denn ein System, das nur auf Anfrage antwortet, ist strukturell immer einen Schritt hinter der Person, die noch nicht gefragt hat.
Reporting verschärft das Problem, statt es zu lösen. Ein Monats- oder Wochenbericht fasst von Natur aus zusammen, was geschehen ist, aggregiert zu einem Zeitpunkt, an dem das Fenster zum Handeln im Einzelfall schon geschlossen sein kann. Für Trend und Muster (wird es über ein Quartal besser oder schlechter) ist er wertvoll, für den einen hängenden Auftrag, der heute vor Ihnen liegt, wertlos. Teams bauen weitere Berichte, weil Berichte das sind, was die Werkzeuge einfach machen, nicht weil sie die eigentliche Lücke schließen.
Die Kosten zeigen sich in den Momenten, in denen eine mögliche Entscheidung durch eine Aufräumarbeit ersetzt wurde:
Das Problem sind nicht die Daten, sondern die letzte Meile zwischen Datensatz und Person.
Gehen Sie Ihre letzten drei echten Überraschungen durch (die Fehlmenge, die niemand kommen sah, den Auftrag, der still verrutschte, die Rechnungsabweichung, die am Monatsende auftauchte) und stellen Sie jeweils eine Frage: Stand in IFS Cloud schon vorher, dass es dazu kommen würde? In fast jedem dieser Fälle war es so. Bestandsposition, Auftragsstatus und -alter, Bestätigungsstatus: Die Projektionen hielten die Wahrheit lange vor der Überraschung.
Diese Übung liefert zuverlässig eine kurze Liste von zwei oder drei Ausnahmearten, die weiter Kosten verursachen, und jede wird zum Kandidaten für dasselbe Muster: ein Custom Event, das den betreffenden Zustand beobachtet, ihn gegen eine sinnvolle Schwelle prüft und eine benannte Person informiert, bevor das Fenster schließt. Zwei naheliegende Ausgangspunkte haben eigene ausführliche Beiträge: unbestätigte Bestellungen und die Automatisierungen für SCM in IFS Cloud insgesamt.
Reporting und zugestellte Ausnahmen lösen nicht dasselbe Problem, sie beantworten unterschiedliche Fragen. Reporting beantwortet „wie stehen wir da“. Zugestellte Ausnahmen beantworten „was braucht heute eine Entscheidung von mir“, und nur diese Frage hat ein Fenster, das sich schließt.
| Reporting | Zugestellte Ausnahmen | |
|---|---|---|
| Beantwortet | Wie stehen wir insgesamt da | Was braucht jetzt eine Entscheidung |
| Zeitpunkt | Im Nachhinein, im festen Takt | Sobald sich der Zustand ändert |
| Wer hinsehen muss | Wer daran denkt, den Bericht zu ziehen | Der zuständige Verantwortliche, automatisch |
| Geeignet für | Trend, Muster, Vorstandsunterlagen | Den hängenden Auftrag, der heute vor Ihnen liegt |
| Entscheidungsfenster | Zum Berichtszeitpunkt womöglich schon geschlossen | Noch offen |
Keines ersetzt das andere. Eine Lieferkette braucht beides: die Trendsicht, um zu erkennen, ob es besser wird, und die zugestellte Ausnahme, um zu handeln, solange noch eine Wahl besteht.
Dafür braucht es weder eine Plattformentscheidung noch ein Transformationsprogramm. Es ist ein kleines, wiederholbares Muster, das Sie auf jeweils eine Ausnahmeart anwenden.
Jede dieser Regeln entsteht im IFS Extensibility Framework (Standard-Custom-Events, Workflows und PL/SQL). Die letzte Meile, die Sie heute schließen, bleibt deshalb nach jedem künftigen Upgrade geschlossen, ohne dass eine Änderung am Core gefährdet wäre.
Es ist die Strecke zwischen dem Moment, in dem ein Datensatz in IFS Cloud in einen Zustand wechselt, der Aufmerksamkeit braucht, und dem Moment, in dem eine bestimmte Person die Änderung tatsächlich bemerkt. Die Daten sind die ganze Zeit korrekt und verfügbar. Die Lücke betrifft allein, ob und wann ein Mensch sie sieht.
Reporting beantwortet eine andere Frage (wie sich Dinge entwickeln) und ist dafür wertvoll. Die Aufmerksamkeitslücke schließt es nur, wenn das Entscheidungsfenster einer Ausnahme länger ist als der Berichtszyklus, denn Reporting läuft im festen Takt.
Bei der Ausnahmeart, die Ihre jüngste echte Überraschung verursacht hat. Gehen Sie die letzten drei Überraschungen zurück und prüfen Sie, ob die Daten vorher existierten: Das zeigt im Normalfall den Ausgangspunkt mit dem höchsten Nutzen, ohne dass Sie raten müssen.
Nein. Jede Ausnahmeart wird mit einem einzelnen Custom Event geschlossen, das auf eine Schwelle und einen Empfänger zugeschnitten und vor dem Livegang im Dry-run geprüft ist. Das Muster ist bewusst klein und wiederholbar, keine Plattformänderung. Es beginnt mit der teuersten Ausnahme und wächst von dort.
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.
Ihrem ERP fehlen nicht Daten, sondern ein Mechanismus, der die richtige Tatsache zur richtigen Person bringt, solange noch eine Entscheidung möglich ist. Ein 30-Minuten-Gespräch genügt, um Ihre teuerste Ausnahme zu benennen und die Lösung zu skizzieren (Festpreis, Dry-run, bevor etwas live geht).
Unabhängige IFS-Cloud-Praxis · Supply Chain
Auf einen Blick
„Steht im System“ ist einer der gefährlicheren Sätze in der Lieferkette, weil er im Normalfall stimmt und trotzdem die eigentliche Frage nicht beantwortet. Die Bestellung ist im System. Die Position ist da, das Datum ist da, die Artikelnummer ist da. Der Satz überspringt, ob die Gegenseite (Lieferant, Lager, Kreditorenbuchhaltung) tatsächlich darauf reagiert hat. Ein vorhandener Beleg und ein bestätigter Beleg sind zwei getrennte Tatsachen, und IFS Cloud zeigt, wie andere ERP-Systeme auch, bereitwillig die erste, ohne die zweite je zu erzwingen. Dieser Beitrag ergänzt eine vertiefte Betrachtung der Variante unbestätigter Bestellungen. Hier geht es um das Muster selbst: Es wird an drei Belegarten gezeigt, und „angenommen“ und „bestätigt“ werden als strukturell getrennte Zustände behandelt, nicht als Abstufungen desselben.
Ein Bildschirm unterscheidet nicht zwischen Absicht und Bestätigung. Eine Bestellung im Status Freigegeben sieht gleich aus, ob der Lieferant sie vor einer Stunde angenommen oder nie gesehen hat. Ein Kundenauftrag mit zugesagtem Termin sieht gleich aus, ob das Material tatsächlich reserviert ist oder die Deckungsprüfung still fehlgeschlagen ist. Ein Wareneingang im System sieht gleich aus, ob er je gegen die zugehörige Rechnung abgeglichen wurde oder darauf wartet, dass jemand das Fehlen bemerkt. In jedem Fall existiert der Beleg, das Auge liest „vorhanden“ als „erledigt“ und geht zur nächsten Zeile.
Ein Datenqualitätsproblem ist das nicht. Die Felder stimmen, der Zustand ist korrekt erfasst. Es ist ein Aufmerksamkeitsproblem, das wie ein Datenproblem aussieht: Der Beleg zeigt den unbestätigten Zustand richtig, und der Fehler liegt darin, dass niemand einen Mechanismus gebaut hat, der genau diesen Zustand bemerkt und anders behandelt als einen bestätigten. Ohne ihn verschwimmen beide Kategorien auf jedem Bildschirm und in jedem Bericht, bis der Unterschied eines Tages plötzlich sichtbar wird.
Der sichtbare Schaden liegt immer weiter hinten: ein verspäteter Artikel, eine verpasste Lieferung, eine unerwartete Abweichung bei der Rechnung. Die eigentlichen Kosten liegen früher, in den Tagen, in denen alle glaubten, der Beleg sei weiter, als er war:
Teuer ist nicht der verspätete Artikel, sondern jeder Tag, an dem Sie glaubten, etwas sei unterwegs, das nie losgefahren war.
Die Information fehlte nie. Jedes dieser Beispiele (Bestellbestätigung, Auftragsdeckung, Abgleich von Wareneingang und Rechnung) liegt heute in einer IFS-Cloud-Projektion, korrekt und aktuell, sobald sich der Zustand ändert oder die Änderung ausbleibt. Es fehlt eine feste Frage an diese Daten: Welche Belege stehen in einem Zustand, der endgültig aussieht, es strukturell aber nicht ist?
Der praktische Test ist bei allen Belegarten derselbe. Wählen Sie den Zustand, der nur vorübergehend sein sollte (freigegeben, aber unbestätigt; zugesagt, aber ungedeckt; eingegangen, aber nicht abgeglichen), und fragen Sie, wie lange ein Beleg dort liegen darf, bevor jemand Bescheid bekommen sollte. Lautet die ehrliche Antwort „unbegrenzt, weil niemand genau diesen Zustand beobachtet“, haben Sie eine Belegkategorie gefunden, die angenommen statt bestätigt ist, und einen Kandidaten für dasselbe Erkennungsmuster, das der Beitrag zu unbestätigten Bestellungen im Detail behandelt.
Dem Bildschirm zu vertrauen heißt, „im System vorhanden“ als „bestätigt“ zu lesen und das Gegenteil erst zu erfahren, wenn ein nachgelagerter Termin die Frage erzwingt. Den Zustand zu prüfen heißt, dass eine Regel zwischen Beleg und Annahme steht, gezielt den unbestätigten Fall sucht und ihn meldet, bevor er zum Terminproblem wird.
| Dem Bildschirm vertrauen | Den Zustand prüfen | |
|---|---|---|
| Wann die Lücke auffällt | Am Termin | Tage oder Wochen früher |
| Was den Blick auslöst | Ein Fehler weiter hinten im Ablauf | Eine definierte Schwelle für Alter oder Zustand |
| Wer es zuerst merkt | Wen der Fehler trifft | Wer den Beleg verantwortet |
| Anwendung über Belegarten | Uneinheitlich, von Fall zu Fall | Dasselbe Muster für jede Belegart |
| Kosten der Lücke | Voll und spät bezahlt | Klein und früh bezahlt oder vermieden |
Die Mechanik dieser Prüfung (Schwelle, Probelauf (Dry-run), Eskalation) ist für jede Belegart dieselbe. Für die Bestellbestätigung im Einzelnen gibt es eine eigene Darstellung mit genauer Tabellenstruktur und Einführungsschritten im Beitrag zu unbestätigten Bestellungen in IFS.
Behandeln Sie das als Muster, das Sie anwenden, nicht als einzelne Lösung, die Sie einmal ausrollen. Dieselben fünf Schritte gelten für Bestellung, Kundenauftrag und Wareneingang.
Jede Ausprägung des Musters entsteht im IFS Extensibility Framework (Standard-Custom-Events, Workflows und PL/SQL). Die Ausdehnung auf eine neue Belegart ist deshalb eine Ergänzung, kein Neuaufbau, und bleibt beim Wachsen update-sicher.
Ein angenommener Beleg existiert im System und sieht erledigt aus (die Felder sind gefüllt, der Status wirkt endgültig), doch keine externe Stelle und keine nachgelagerte Prüfung hat ihn tatsächlich bestätigt. Bei einem bestätigten Beleg ist diese Bestätigung ausdrücklich erfasst, sodass sein Zustand belegt ist und nicht nur vermutet wird.
Unbestätigte Bestellungen sind das klarste Einzelbeispiel für dieses Muster und haben auf dieser Website eine eigene Darstellung. Dieser Beitrag fasst es weiter: Dieselbe Lücke zeigt sich bei der Deckung von Kundenaufträgen, beim Abgleich von Wareneingang und Rechnung und bei anderen Belegarten, nicht nur im Einkauf.
Beginnen Sie mit der Lücke zwischen angenommen und bestätigt, die heute die höchsten Kosten verursacht. Unbestätigte Bestellungen sind das klarste Beispiel. Weisen Sie das Muster dort nach und dehnen Sie es dann auf Auftragsdeckung oder Wareneingangsabgleich aus, sobald Mechanik und Vertrauen stehen.
Nein. Die Daten sind bereits korrekt: Sie zeigen den unbestätigten Zustand genau. Es fehlt eine Regel, die diesen Zustand bemerkt und jemandem Bescheid gibt. Es handelt sich um Erkennung und Eskalation, nicht um ein Datenqualitätsprojekt.
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.
Vermuten Sie, dass mindestens eine Belegart in Ihrem Betrieb diese Lücke trägt, genügt ein 30-Minuten-Gespräch, um die Kandidaten zu benennen und festzulegen, welche zuerst nachgewiesen wird (Festpreis, Dry-run, bevor etwas versendet wird).
IFS Cloud Anlagenlebenszyklus · Functional Object · Verkaufsangebot · Servicevertrag
Wer ein Functional Object erst beim ersten Serviceauftrag anlegt, baut Datenstrukturen nach, die das Angebot längst kannte. Dieser Beitrag zeigt am Beispiel von SMAY, wo in IFS Cloud das Objekt entsteht, womit man es verknüpft und warum dafür kein Custom Code nötig ist.
Technisches 30-Minuten-Gespräch buchen Zum Verkaufsangebot springen
Ein Sales Quotation ist in IFS Cloud der früheste Zeitpunkt, an dem die Konfiguration einer Anlage feststeht. Wer das Angebot nur als kaufmännisches Dokument behandelt, verschenkt diesen Zeitpunkt. Legt man dort die funktionalen Anforderungen und die erwartete Einbauumgebung fest, stehen sie in der Projekt- und Servicephase ohne Bruch zur Verfügung.
Stellt SMAY ein Angebot aus, sollte das System die Platzhalter für die physische Hardware bereits vorbereiten. So bleibt der Bedarf des Kunden mit der späteren Instandhaltung verbunden. Fehlt diese Verbindung, müssen Sie Datenstrukturen sechs Monate später von Hand nachbauen. Das kostet Zeit und Geld, und die Arbeit hätte das Angebot bereits geleistet.
Das Serial Part ist das Gerät, das Sie ausliefern. Ein Functional Object ist die Rolle, die dieses Gerät im Gebäude oder in der Anlage übernimmt. Wer nur das Serial Part verfolgt, kennt die Historie des Metalls. Wer das Functional Object verfolgt, kennt die Historie der Position.
| Merkmal | Serial Part | Functional Object |
|---|---|---|
| Was es beschreibt | Das physische Gerät, das Sie liefern | Die Funktion des Geräts in der Anlage |
| Beispiel | Der Lüfter, der heute eingebaut ist | Die Absaugung, die über zwanzig Jahre gebraucht wird |
| Austausch | Wird zurückgenommen, aufgearbeitet und ersetzt | Bleibt bestehen, die Betriebsdaten bleiben erhalten |
Diese Trennung macht Kreislaufwirtschaft technisch möglich: Sie nehmen das Serial Part zur Aufarbeitung zurück, löschen dessen Historie und setzen ein neues Gerät ein, ohne die Betriebsdaten der Anlage zu verlieren. Ohne diese Trennung bleibt nur eine Sammlung von Tabellen.
Eine Kreislaufwirtschaft braucht einen Mechanismus, der das Gerät zurückholt, und in IFS Cloud ist das der Service Contract. Hängt er vom ersten Tag an am Functional Object, plant der Service Wartung voraus. Er repariert nicht nur, was ausfällt, sondern verwaltet einen Gerätebestand, dessen Komponenten später ausgebaut oder für ein zweites Leben aufgearbeitet werden.
Hat das Serviceteam keinen Zugriff auf die Konfiguration aus dem Sales Quotation, muss es Artikel identifizieren, die längst mit dem Objekt verknüpft sein sollten. Diese Suche kostet Arbeitszeit und drückt die Marge im Service.
IFS Cloud bietet die Mittel, ein Angebot mit einem Functional Object zu verknüpfen, über Konfiguration. Für den Datenfluss vom Angebot in die Anlagenstruktur sind Workflow und Business Process Automation vorgesehen, nicht CRIMS und keine eigenen Skripte.
Jedes PL/SQL, das das Erzeugen von Anlagenobjekten steuert, erschwert das Update auf 25R1 oder 25R2. Ziel ist ein Clean Core. Kommen Daten aus einem externen CRM-System, übergeben Sie sie über die Standard-OData-APIs. Das hält die Integration stabil, und Ihre Daten zum Anlagenlebenszyklus überstehen die folgenden Updates.
Die Reihenfolge ist damit festgelegt: Das Functional Object entsteht im Angebot, der Service Contract wird vor der Auslieferung verknüpft, und beides läuft über Standardfunktionen.
Das Serial Part ist das physische Gerät, das ausgeliefert wird. Ein Functional Object ist die Funktion, die dieses Gerät in der Anlage erfüllt. Wird das Gerät getauscht, bleibt das Functional Object samt Betriebsdaten bestehen, und nur das Serial Part wechselt.
Ein Functional Object sollte in IFS Cloud im Sales Quotation entstehen. Dort liegen die funktionalen Anforderungen und die Einbauumgebung vor, und die Daten gelangen ohne Nacharbeit in die Projekt- und Servicephase. Wer es erst beim ersten Serviceauftrag anlegt, baut die Struktur nachträglich von Hand auf.
Nein. In IFS Cloud übernehmen Workflow und Business Process Automation den Datenfluss vom Angebot in die Anlagenstruktur. Eigenes PL/SQL erschwert dagegen das Update auf 25R1 oder 25R2, daher hält Konfiguration den Core sauber.
Ich bin Dariusz Myśliwiec. Ich arbeite seit 18 Jahren praktisch mit IFS (Apps 7.5 bis 10 und IFS Cloud). Ich bin IFS Certified Associate Consultant und nach PRINCE2® 7 zertifiziert.
Ausgewählte Kunden aus meiner IFS-Arbeit: Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm.
Nennen Sie mir Ihr IFS-Cloud-Release und den Punkt im Prozess, an dem Anlagen heute erfasst werden. Sie gehen mit einer klaren Empfehlung aus dem Gespräch. Sie sprechen direkt mit dem Berater, der die Arbeit ausführt.
Technisches 30-Minuten-Gespräch buchen CRIMS-Katalog ansehen
IFS ist eine eingetragene Marke der IFS AB. Diese Beratung steht in keiner Verbindung zur IFS AB.
IFS Cloud Go-live · Go/No-Go · Rollentest · Mock Cutover
Die Go/No-Go-Entscheidung für IFS Cloud gehört an drei harte Schwellen gebunden: 100 % Erfolgsquote der automatisierten Tests auf dem kritischen Pfad, kein offener Fehler hoher Priorität im UAT-Protokoll und eine Summen- und Saldenliste, die innerhalb von 0,01 % mit dem Altsystem übereinstimmt. Wer die Freigabe von der Einschätzung einzelner Abteilungsleiter abhängig macht, bezahlt Abweichungen in der ersten Betriebswoche mit teurem Hypercare-Aufwand.
Technisches 30-Minuten-Gespräch buchen Zu den drei Schwellen
Ein professioneller Go-live ist eine Entscheidung über die Frage, ob das Geschäft auf der neuen Plattform bestehen kann, und keine rein technische Aufgabe. Der Start ist keine Ziellinie, sondern der Beginn einer laufenden technischen Weiterentwicklung. Die Annahme, ein manueller Abnahmetest (UAT) von ein paar Wochen fange die Altlasten aus zwanzig Jahren auf, trägt in einer API-first-Umgebung in der Cloud nicht.
| Schwelle | Messwert | Entscheidung bei Verfehlen |
|---|---|---|
| Automatisierte Tests | 100 % Erfolgsquote auf dem kritischen Pfad | No-Go |
| UAT-Protokoll | Null offene Fehler hoher Priorität | No-Go |
| Summen- und Saldenliste | Abgleich mit dem Altsystem innerhalb von 0,01 % | No-Go |
Jedes Zugeständnis an eine dieser Schwellen ist ein finanzielles Risiko, das sich in der ersten Betriebswoche als aufwendiger Hypercare-Einsatz zeigt. Mit dieser Methodik sinkt der Stabilisierungsaufwand nach dem Start um 40–60 %, und der Clean Core bleibt bei jedem späteren Update erhalten.
In IFS Cloud ist Testen eine Daueranforderung, denn die halbjährlichen Releases (etwa der Wechsel von 25R1 auf 25R2) sind verpflichtend. In älteren Versionen wie Apps 10 war es eine Hürde, die einmal in fünf Jahren genommen wurde. Wer sich auf Handtests verlässt, lässt irgendwann Updates aus, um den Testaufwand zu vermeiden, und sperrt damit das eigene System.
Das IFS Cloud Test Automation Tool (TSAK) senkt die laufenden Wartungskosten deutlich. Jeder eigene BPMN-Workflow und jeder Integrationsendpunkt erhält ein automatisiertes Skript. Geprüft wird dann nicht, ob die Schaltfläche funktioniert, sondern ob der Geschäftsprozess intakt bleibt. Wie die gesamte Einführung dahin aufgebaut wird, beschreibt die Checkliste für ein Clean-Core-Projekt.
Altdaten aus Apps 9, die ungeprüft nach IFS Cloud gelangen, brechen die Workflow-Automatisierung. Der IFS Data Migration Manager (DMM) bereinigt Daten schrittweise, was manuelle SQL-Skripte nicht leisten.
Ein Projekt zeigt das Risiko: Teilgelieferte Bestellungen wurden im letzten Delta-Load nicht behandelt, und daraus entstand eine Krise beim Abgleich der Finanzdaten. Eine konsequente DMM-Validierung mit drei Probemigrationen hätte die Differenz Wochen vorher gezeigt. Datenmigration bedeutet nicht Verschieben, sondern Integrität.
| Probemigration | Prüffrage |
|---|---|
| Mock 1: Technisches Mapping | Passen die Daten in die neuen Objekte? Fokus auf dem Mapping der OData-Projektionen. |
| Mock 2: Volumen und Leistung | Verarbeitet die Serviceschicht eine Million Lagerartikelsätze ohne Verzögerung? |
| Mock 3: Cutover-Probe | Wie läuft das Start-Wochenende minutengenau ab? Das zeigt Engpässe bei Menschen und Zeitplan. |
Ein UAT mit Super-User-Konten bestätigt nur, dass das System mit uneingeschränkten Rechten läuft. Am Montagmorgen nach dem Go-live melden sich echte Anwender an und stellen fest, dass ihnen die Rechte für einfache Aufgaben fehlen. Die Rollenprüfung ist deshalb eine eigene Testphase, und jede Fachrolle wird gegen die Dokumente der Prozessmodellierung validiert. Bei Unternehmen mit strenger Revision ist das eine Compliance-Pflicht.
Berechtigungen gehen dabei über OAuth 2.0 und die Projektionen von IFS Cloud: Ein Anwender sieht genau die Projektionen, die seine Rolle verlangt, und diese Zuordnung wird mit Konten getestet, die den echten Rollen entsprechen.
Der Mock Cutover ist die Abschlussprüfung, eine Probe im vollen Umfang von Freitag bis Sonntag. Sie simulieren die Datenextraktion, die Transformation im DMM und den finalen Load in eine saubere, produktionsnahe Umgebung. Dauert ein manueller Schritt länger als geplant, muss er optimiert werden.
Zeigt die Probe, dass der Datenload 48 Stunden braucht, das Geschäft aber nur ein Fenster von 24 Stunden erlaubt, liegt ein Strukturproblem vor. Es erst beim echten Go-live zu entdecken, ist ein Projektfehler. Den Ablauf der Probe und des Wochenendes selbst beschreibt der Artikel zum Go-live-Test mit Mock Cutover.
Schnittstellen können beim Go-live das schwächste Glied sein, denn sie hängen von Systemen ab, die Sie nicht allein kontrollieren. Moderne IFS-Cloud-Umgebungen stützen sich auf REST-APIs, und der Go-live-Test muss jede Anbindung an Drittsysteme von Anfang bis Ende validieren.
Ob Sie n8n für die Orchestrierung nutzen oder native IFS-Projektionen: Der Test simuliert Spitzenlast. Ein einziger schlecht geschriebener API-Aufruf kann das ganze System in Phasen mit hohem Buchungsvolumen ausbremsen, etwa beim Monatsabschluss oder an Versandspitzentagen. Wie eine Schnittstelle gegen Ratenlimit und Doppelbuchungen abgesichert wird, steht im Artikel IFS Cloud API Integration mit OData und OAuth 2.0.
Warum Anpassungen im Kern jedes Release verteuern, beschreibt der Artikel Custom Events in IFS Cloud durch Workflows ersetzen.
Der entscheidende Messwert ist der Datenabgleich. Stimmen Summen- und Saldenliste und Lagerbewertung nicht innerhalb von 0,01 % mit dem Altsystem überein, wird nicht gestartet. Funktionale Fehler lassen sich nachbessern, verfälschte Finanzdaten bleiben dauerhaft ein Schaden.
Ein Super-User-Konto besitzt alle Rechte und verbirgt dadurch fehlende Berechtigungen. Echte Anwender merken am Montagmorgen nach dem Go-live, dass ihre Rolle einfache Aufgaben nicht erlaubt. Das UAT gehört mit Konten durchgeführt, die den produktiven Fachrollen entsprechen.
Ein Clean Core verkleinert die Testoberfläche. Wer Standardfunktionen und BPMN-Workflows statt eigenem PL/SQL-Code nutzt, überlässt die Kernlogik der Pflege durch IFS. Das Team testet dann nur die eigenen Konfigurationen und die Erweiterungen, die für das Unternehmen einmalig sind.
Die Entscheidung lautet No-Go, sobald eine der drei Schwellen verfehlt wird: Die automatisierten Tests auf dem kritischen Pfad sind nicht alle erfolgreich, im UAT-Protokoll steht ein offener Fehler hoher Priorität, oder die Summen- und Saldenliste weicht um über 0,01 % vom Altsystem ab.
Ich bin Dariusz Myśliwiec. Ich arbeite seit 18 Jahren praktisch mit IFS (Apps 7.5 bis 10 und IFS Cloud). Ich bin IFS Certified Associate Consultant und nach PRINCE2® 7 zertifiziert.
Ausgewählte Kunden aus meiner IFS-Arbeit: Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm.
Nennen Sie mir Ihr Release, die Zahl der offenen UAT-Fehler und den geplanten Go-live-Termin. Sie erfahren im Gespräch, welche der drei Schwellen bei Ihnen noch nicht belegt ist. Sie sprechen direkt mit dem Berater, der die Arbeit ausführt.
Technisches 30-Minuten-Gespräch buchen Weitere Artikel zu IFS Cloud
IFS ist eine eingetragene Marke der IFS AB. Diese Beratung steht in keiner Verbindung zur IFS AB.
IFS Cloud Einführung · Clean Core · Evergreen · Datenmigration
Eine IFS-Cloud-Einführung kann ohne einen einzigen Softwarefehler scheitern, wenn die Architektur-Governance fehlt: Wer den Updatezyklus 25R1/25R2 als einmaliges Ereignis behandelt, baut ein System, das den nächsten Release-Wechsel nicht übersteht. Diese Checkliste führt in sechs Phasen zu einem Clean Core, der Evergreen übersteht, und ersetzt riskanten Eigencode durch BPMN-Workflows und Integrationen über OData.
IFS Cloud ist ein Methodenwechsel, den Projektleiter gern übergehen: Der Wechsel auf Evergreen verlangt eine feste Grenze zwischen Ihrem Geschäftsprozess und dem Kerncode des Herstellers. Wer Anpassungen auf Datenbankebene wie in Apps 8 oder 9 nachbaut, hat nach dem ersten Release-Zyklus technische Schulden, die jeden weiteren Wechsel verteuern.
Mit diesem Vorgehen sind 40–60 % weniger technische Schulden erreichbar, und das System geht ins Release 25R2, ohne dass ein großer manueller Regressionstest nötig ist.
Bevor die erste Umgebung bereitgestellt wird, müssen die Spielregeln stehen. Clean Core heißt: Der Standard bleibt unangetastet, und jede Abweichung wird begründet. Jede Abweichung vom Standard muss gegenüber dem Lenkungsausschuss verteidigt werden, nicht nur gegenüber dem Entwickler.
IFS Cloud läuft containerisiert und API-first, Sie verwalten keine Datenbank, sondern ein Geflecht aus Diensten. Sicherheit läuft deshalb über OAuth 2.0, Anbindung über OData.
Wird der technische Kern falsch aufgesetzt, entsteht später Reibung an den Schnittstellen, und Korrekturen in letzter Minute umgehen die Sicherheitsvorgaben. Wie eine solche Schnittstelle sauber aufgebaut wird, beschreibt der Artikel IFS Cloud API Integration mit OData und OAuth 2.0.
Ein Prozess, den Sie nicht zeichnen können, lässt sich nicht automatisieren. BPMN 2.0 ist die Sprache, in der der IFS Cloud Workflow Designer arbeitet, und die Modellierung zeigt den Fachberatern die Logik, bevor eine Zeile Workflow-Konfiguration entsteht.
An der Datenmigration entscheidet sich der Projektzeitplan. Excel-Uploads und die alten FndMig-Jobs reichen für komplexe Datenbestände nicht aus, für große Datenmengen ist der IFS Data Migration Manager (DMM) das Werkzeug. Er bereinigt und transformiert Daten schrittweise im Tool und hält die Zielumgebung sauber, denn verschmutzte Stammdaten lassen automatisierte Workflows scheitern.
Der IFS Cloud Workflow Designer ersetzt die alten Custom Events vom Typ „Execute Online“. Workflows sind von der Tabellenstruktur entkoppelt, deshalb zerstört eine Änderung an der darunterliegenden Datenbank Ihre Geschäftslogik nicht, und das System bleibt Evergreen.
Unter Evergreen ist Testen ein Dauerzustand: Die Plattform ändert sich mit jedem Release, also müssen Tests automatisiert und mit geringem Aufwand wiederholbar sein. Setzen Sie das IFS Cloud Test Automation Tool (TSAK) oder ein vergleichbares Framework ein. Wer jedes monatliche Update von Hand abnimmt, überspringt irgendwann kritische Prüfungen.
Die Phase Go-live behandeln die Artikel zum Go-live-Test mit Mock Cutover und zu den Go/No-Go-Kriterien.
Jeder Punkt der folgenden Tabelle ist ein Meilenstein, den Sie vor dem Go-live mit einem Nachweis belegen können.
| Meilenstein | Nachweis |
|---|---|
| Clean-Core-Charta | Von Geschäftsführung und Lenkungsausschuss unterzeichnet |
| Infrastruktur | OAuth 2.0 und IAM sind in allen Umgebungen konfiguriert |
| BPMN-Bestand | Alle kritischen Prozesse aus Lieferkette und Finanzen sind in BPMN 2.0 modelliert |
| DMM-Einrichtung | Data Migration Manager installiert, erste Probemigration abgeschlossen |
| Workflow-Audit | Alle bisherigen Custom Events sind auf den neuen Workflow Designer abgebildet |
| Integrationsprojektionen | Kein direkter SQL-Zugriff, alle Integrationen nutzen OData-REST-APIs |
| Testautomatisierung | Regressionssuite für die Evergreen-Updatezyklen automatisiert |
| Schulung der Anwender | Durchgeführt in der Aurena-Oberfläche, nicht in alten IEE-Umgebungen |
| Cutover-Plan | Minutengenauer Ablaufplan für das Go-live-Wochenende |
Jeder offene Punkt ist ein versteckter Kostenfaktor, der beim ersten Evergreen-Update sichtbar wird.
Der Workflow Designer braucht in der Entwurfsphase Zeit, die ein schneller PL/SQL-Trigger nicht kostet. Dafür verkürzt er die Testphase um 30 %, weil die Logik sichtbar ist und sich leichter debuggen lässt. Über die Laufzeit gleicht sich der Anfangsaufwand durch geringeren Pflegeaufwand aus.
Ja, denn 95 % der Anforderungen, die als komplex gelten, lassen sich über Konfiguration, State Machines und Workflows erfüllen. Die verbleibenden 5 % gehen über IFS Cloud Custom Projections, die im Gegensatz zu alten Modifikationen updatesicher sind.
Eine Datenmigration nach IFS Cloud scheitert am unterschätzten Bereinigungsaufwand. Werden Altdaten ungeprüft in ein API-getriebenes System übernommen, schlagen Transaktionen fehl und Workflows brechen ab. Der DMM bereinigt und transformiert die Daten vorher im Tool und verhindert das.
Eine IFS-Cloud-Einführung braucht mindestens vier Umgebungsstufen: Development, Build, Test (UAT) und Produktion. In der Build-Umgebung werden die Konfigurationen des Workflow Designers geprüft, bevor sie in den Test gehen.
Ich bin Dariusz Myśliwiec. Ich arbeite seit 18 Jahren praktisch mit IFS (Apps 7.5 bis 10 und IFS Cloud). Ich bin IFS Certified Associate Consultant und nach PRINCE2® 7 zertifiziert.
Ausgewählte Kunden aus meiner IFS-Arbeit: Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm.
Nennen Sie mir Ihr Release, den Stand Ihrer Anpassungen und den geplanten Go-live-Termin. Sie erfahren im Gespräch, welche Phasen dieser Checkliste bei Ihnen offen sind. Sie sprechen direkt mit dem Berater, der die Arbeit ausführt.
Technisches 30-Minuten-Gespräch buchen Weitere Artikel zu IFS Cloud
IFS ist eine eingetragene Marke der IFS AB. Diese Beratung steht in keiner Verbindung zur IFS AB.
Calculate your return on investment
