Blog

Das Altsystem läuft weiter, weil der Projektplan ein Go-live-Datum enthält, aber kein Abschaltdatum. Der Cutover-Plan regelt Datenladung und Konfigurationsschalter. Was danach mit dem Vorgängersystem geschieht, fällt zwischen Migrations-Teilprojekt und Rechnungswesen, und der IT-Betrieb geht davon aus, dass einer von beiden zuständig ist.

Die Kosten laufen in zwei Richtungen zugleich. Solange das System beschreibbar bleibt, kann jemand darin buchen, und die beiden Hauptbücher laufen auseinander. Solange es ohne Enddatum weiterläuft, braucht es Sicherheitspatches und einen Benutzeradministrator. Der Ausweg ist ein Plan mit Enddatum, geschrieben vor dem Cutover und im selben Dokument wie die Go-live-Checkliste.

Jedes Datenobjekt des Altsystems bekommt genau eines von drei Ergebnissen, und darüber entscheidet der Eigentümer des Objekts, nicht das Migrationsteam. Der Migrationsumfang beantwortet, was IFS Cloud am ersten Tag braucht. Das Archiv beantwortet, was das Unternehmen später noch belegen muss. Das sind zwei Fragen mit unterschiedlichen Verantwortlichen.

Die Ergebnisse in der Tabelle sind eine Ausgangsposition für den Workshop, keine Vorgabe. Lädt Ihr Datenmigrationsplan zwei Jahre abgeschlossener Bestellungen, weil ein Einkäufer die Preishistorie braucht, wandern diese zwei Jahre aus der Zeile „archivieren“ in die Zeile „migrieren“. Strategie und Plan dazu stehen in den Vorlagen IDK-14 Datenmigrationsstrategie und IDK-15 Datenmigrationsplan mit Checkliste.

Die Aufbewahrungsfrist für Buchführungs- und Steuerunterlagen legt das Recht fest, und sie gilt für die Unterlagen, nicht für das System, das sie erzeugt hat. In Deutschland nennt § 147 Abs. 3 der Abgabenordnung (AO) drei Fristen, die sich nach der Art der Unterlage richten.

Die Tabelle gibt § 147 Abs. 3 AO in Kurzform wieder, gelesen am 17.10.2026 auf gesetze-im-internet.de. Rechtsberatung ist das nicht. Welche Ihrer Unterlagen unter welche Frist fallen, wann die Frist zu laufen beginnt und welche Pflichten das Handelsrecht oder Ihre Branche zusätzlich setzen, hängt von Fakten ab, die ich nicht kenne. Lassen Sie sich von Ihrem Steuerberater oder Wirtschaftsprüfer eine schriftliche Liste geben, die je Unterlagenart Frist, Fristbeginn und geforderte Form nennt. Diese Liste wird die Spalte zum Aufbewahrungsbedarf in Ihrer Abschalttabelle.

Ein Konzern mit Gesellschaften in anderen Ländern braucht diese Liste je Gesellschaft, denn dort gilt jeweils das Recht des Landes, in dem die Gesellschaft eingetragen ist.

• Lohn- und Personalunterlagen folgen anderen Regeln als die Buchhaltung und können in einem eigenen System liegen. Behandeln Sie sie als eigenen Punkt.
• Personenbezogene Daten bleiben im Archiv personenbezogen (DSGVO). Das Archiv braucht eine Zugriffsliste und ein Löschdatum, nicht nur ein Aufbewahrungsdatum.
• Verträge und Gewährleistungspflichten können Unterlagen länger erfordern als das Steuerrecht. Fragen Sie Rechtsabteilung und Service, nicht nur das Rechnungswesen.

Ein Nur-Lese-Archiv taugt, wenn eine Person, die nie im Altsystem gearbeitet hat, einen bestimmten Beleg innerhalb eines Arbeitstags in lesbarer Form liefert. Diesen Test führe ich in den letzten Wochen vor der Abschaltung durch, gemeinsam mit dem Rechnungswesen und nicht mit der IT.

Der Maßstab dahinter ist § 147 Abs. 6 AO. Er regelt den Datenzugriff der Finanzverwaltung und nennt drei Wege: die Einsicht in das Datenverarbeitungssystem und seine Nutzung, die maschinelle Auswertung der Daten nach den Vorgaben der Prüfer und die Übermittlung der Daten in einem maschinell auswertbaren Format. Der Zugriff erstreckt sich auch auf Daten, die bei Dritten gespeichert sind, und die Kosten trägt der Steuerpflichtige. Planen Sie das Archiv deshalb so, dass es alle drei Wege bedienen kann. Ob Ihr Archiv die Anforderungen der GoBD erfüllt, prüfen Sie anhand des Originaltexts des BMF-Schreibens mit Ihrem Steuerberater.

• Suche: Beleg nach Nummer, nach Lieferant oder Kunde und nach Periode finden.
• Vollständigkeit: Beleg, Positionen, Buchungen und angehängte Dateien kommen zusammen zurück.
• Export: Ein Ergebnis verlässt das Archiv als Datei, die der Empfänger ohne die alte Software öffnen kann.
• Nur lesend: Kein Benutzer, auch kein Administrator, kann buchen oder ändern. Das Datum, ab dem das durchgesetzt wird, ist dokumentiert.
• Zugriff: Ein benannter Verantwortlicher und eine Benutzerliste, einmal im Jahr geprüft.
• Feldzuordnung (Mapping-Dokument): Ein kurzes Dokument, das festhält, welches Altfeld zu welchem IFS-Cloud-Feld wurde, damit ein Leser einen archivierten Saldo mit dem migrierten abstimmen kann.
• Wiederherstellungstest: Das Archiv wurde mindestens einmal aus der Sicherung geöffnet, bevor das Altsystem heruntergefahren wurde.

Wählen Sie fünf Belege aus unterschiedlichen Jahren und von unterschiedlicher Art, geben Sie sie einer Buchhalterin, die nicht im Projekt war, und messen Sie die Zeit bis zur Antwort. Muss sie dafür einen Berater anrufen, ist das Archiv nicht bereit.

Ich setze in Projekten drei Archivwege ein, und sie unterscheiden sich darin, was erhalten bleibt und was weiter Geld kostet. Sie lassen sich kombinieren: Dokumente im Dokumentenarchiv, Hauptbücher als Datenauszug, kein Altsystem bleibt in Betrieb.

Ein Archivierungsprodukt empfehle ich in diesem Artikel nicht. Die Wahl hängt vom Datenvolumen ab, von der Zahl der aufzubewahrenden Jahre und davon, wer das Archiv abfragt. Sie gehört mit einem Kostenvergleich in die Abschaltstrategie.

Den Abschalttermin legt der Lenkungskreis fest, auf Empfehlung der Leitung Rechnungswesen und der IT-Leitung, und eine benannte Person verantwortet die Abschalttabelle. Die Projektleitung bereitet sie vor, das Risiko eines fehlenden Belegs trägt aber das Rechnungswesen, deshalb unterschreibt das Rechnungswesen.

Die Struktur liefert die Cutover-Vorlage. Abschnitt 7 von IDK-20 Cutover-Plan, Checkliste und Rückfallplan ist eine Tabelle mit sechs Spalten: System oder Schnittstelle, Aktion beim Go-live, spätere Aktion, Aufbewahrungsbedarf, Verantwortlicher und Datum. Die Beispielzeile für ein Alt-ERP sieht beim Go-live den Nur-Lese-Zugriff für alle Benutzer an einem nummerierten Schritt der Checkliste vor und später Archivierung und Abschaltung nach der Frist aus der Abschaltstrategie. Die Vorlage nennt diese Abschaltstrategie als mitgeltendes Dokument, und dieser Artikel ist eine Anleitung, sie zu schreiben.

1. Vor dem Cutover: die Aufbewahrungsliste des Steuerberaters, Archivweg und Verantwortlicher je Datenobjekt sowie das Vertragsende samt Kündigungsfrist aus den Lizenz- und Hostingverträgen.
2. Beim Go-live: Das Altsystem wird an einem nummerierten Schritt der Cutover-Checkliste auf Nur-Lese-Zugriff gesetzt, und seine Schnittstellen werden gestoppt.
3. In den ersten Abschlüssen in IFS Cloud: Salden abstimmen, den Abruftest mit fünf Belegen durchführen und danach die Feldzuordnung korrigieren.
4. Abschaltung: Freigabe durch den Lenkungskreis, dann eine letzte Sicherung mit Wiederherstellungstest, dann die Kündigung des Vertrags.
5. Projektabschluss: Archivort und Verantwortlichen in der Übergabe festhalten, siehe IDK-24 Projektabschluss und Lessons Learned.

Zwischen Go-live und Abschaltung ist die Datenqualität im neuen System am schwächsten. Der SCM Exception Scan ist ein einmaliger, rein lesender Scan Ihrer Einkaufsdaten in IFS Cloud über OData, der offene Ausnahmen auflistet. Er installiert nichts in Ihrem IFS, es bleibt also nichts von uns, das Sie später entfernen müssten. Ob er zu Ihren ersten Wochen nach dem Cutover passt, klären wir am besten im Gespräch.

Zur Datenseite des vorangehenden Projekts siehe Datenmigration IFS Cloud: Governance-Checkliste und Datenqualität vor dem Go-live, zum Go-live selbst IFS Cloud Go-live: Probelauf, Abgleich und Hypercare. Planungsnotizen zur Migration stehen auf der Beratungsseite: IFS Cloud Data Migration Plan und Data Migration Is a Business Reset (beide auf Englisch).

• Vorlage IDK-20 des Dokumentenpakets Einführung, Abschnitt 7 zur Stilllegung von Altsystemen, mit sechs Spalten.
• § 147 Abgabenordnung auf gesetze-im-internet.de (Aufbewahrungsfristen in Absatz 3, Datenzugriff in Absatz 6)
• Aufbewahrungsfristen in anderen Ländern: Steuerbehörde und Gesellschaftsrecht des jeweiligen Landes, je Gesellschaft schriftlich vom Steuerberater oder Wirtschaftsprüfer bestätigt.

Dieser Artikel beschreibt eine Projektpraxis und ist keine Rechts-, Steuer- oder Buchhaltungsberatung. Die Fristen sind aus der am 17.10.2026 abgerufenen, oben verlinkten Fassung des § 147 AO zusammengefasst und können sich ändern. Bestätigen Sie sie mit Ihrem Steuerberater oder Wirtschaftsprüfer.

Dariusz Myśliwiec: 18 Jahre Praxis mit IFS, heute mit IFS Cloud. Ich bin IFS Certified Associate Consultant und nach PRINCE2® 7 zertifiziert. Unabhängige Beratung mit Sitz in Krakau, remote in Europa und weltweit. Sie sprechen direkt mit dem Berater, der die Arbeit ausführt.

Ausgewählte Kunden aus meiner IFS-Arbeit: 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 Seite Known Limitations im Tailoring-Guide von IFS Cloud enthält einen Abschnitt „Custom Attributes on Assistants“. Ich habe ihn in der Dokumentation zu 24R1 und zu 25R1 geöffnet, und beide Ausgaben tragen denselben Text. Der Abschnitt stellt normale Anwendungsseiten, auf denen ein Anwender Daten sucht, Informationen ändert oder ergänzt und dann ausdrücklich speichert, den Assistants gegenüber, die „provide flexible implementation to suit the task at hand“. Sein Schluss lautet: „it is not currently possible to provide custom attributes on assistants.“

Dieselbe Seite erwähnt Dialoge nicht. Die Lücke zählt, denn „Custom Field“ meint im Alltag sowohl das Custom-Attributes-Framework als auch die Felder, die Anwender auf dem Bildschirm sehen, und die dokumentierte Aussage ist enger als das Problem, das Anwender melden. Für Dialoge ist der Community-Thread, den der nächste Abschnitt beschreibt, der einzige Beleg, den ich öffnen konnte.

Die Einführung in den Page Designer im Tailoring-Guide 25R1 ergänzt einen relevanten Punkt. Sie nennt das Konfigurieren von Schritten in Assistants als Aufgabe des Page Designers und merkt an, dass Dialoge und Assistants im Vergleich zu normalen Seiten nur begrenzte Konfigurationsmöglichkeiten haben. Keine der beiden Aussagen verspricht einen Weg, diesen Ansichten ein neues Feld hinzuzufügen.

Der Thread „Missing CUSTOM Functions in Dialog and Assistant Views in IFS Cloud“ besteht aus einer Frage und zwei Antworten, alle datiert vom 12. bis 17. März 2026, mit dem Tag 25R1 und als gelöst markiert. Jede Antwort ist das, was sie ist: die Auskunft einer Person in einem Forum und keine Seite der Dokumentation.

• Die Antwort eines IFS-Mitarbeiters sagt nach Rücksprache mit Kollegen, dass sich Dialog- oder Assistant-Ansichten über die Standard-Custom-Fields nicht erweitern lassen, weil diese Ansichten nicht den Mustern folgen, die das Custom-Attributes-Framework verlangt. Es ist die einzige Quelle, die ich fand und die Dialoge nennt, und sie hat das Gewicht der Antwort eines Mitarbeiters, nicht das einer Dokumentationsseite.
• Die Antwort eines Kunden nennt denselben Grund mit anderen Worten (Seiten müssen gängigen Mustern für Speicherung und Umsetzung folgen) und führt vier Workarounds auf. Einen davon bevorzugt der Kunde, weil sein Team die nötigen Fähigkeiten im Haus hat.
• Keine Antwort nennt einen Termin für eine Änderung. Ich fand keine Aussage von IFS, die Möglichkeit später nachzuliefern. Planen Sie deshalb mit der Grenze, wie sie heute besteht.

Ein zweiter Thread stützt die Seite der Assistants. In einem Thread vom März 2025 zu 24R2 sagt ein IFS-Mitarbeiter, dass sich Page-Designer-Konfiguration in Assistants weitgehend nutzen lässt, etwa bedingte Sichtbarkeit, Bearbeitbarkeit und Pflichtstatus, und dass nur das Hinzufügen von Custom Fields zu einem Assistant nicht unterstützt wird. Ein weiterer IFS-Mitarbeiter im selben Thread sagt, ein BPA Workflow vom Typ Process Enrichment müsse Standardwerte befüllen können.

Thread und Dokumentation nennen sechs Ansätze. Die Nummern 1, 3 und 4 haben eine dokumentierte Grundlage in den Guides Tailoring oder Administration von IFS Cloud. Die Nummern 2, 5 und 6 stützen sich auf Forenantworten, und ich kennzeichne sie entsprechend.

1. Page Designer für das, was schon existiert. Der Page Designer ändert Beschriftungen, blendet Felder aus, setzt Felder auf Pflicht und ordnet Elemente neu an. Eine Kundenantwort im Thread schlägt vor, ?showInPageDesigner=true an die Adresse des Dialogs anzuhängen, um den Page Designer darauf zu öffnen, und fügt hinzu, dass dies keine Custom Fields erzeugt. Diesen Parameter fand ich nur im Thread, testen Sie ihn also, bevor Sie sich darauf verlassen.
2. Standardwerte in Assistants. Die Antwort eines IFS-Mitarbeiters im Thread zu 24R2 nennt Conditional Default Values (24R2 und 25R1) und einen BPA-Workflow vom Typ Process Enrichment. Beides sind Aussagen aus dem Thread; die Dokumentation, auf die sie verweisen, habe ich nicht geöffnet.
3. Custom Defined Events auf der zugrunde liegenden Entity. Der Administration-Guide 25R1 beschreibt Custom Defined Events als Ereignisse, die in einer Installation definiert und durch Datenbank-Trigger ausgeführt werden und auslösen, wenn eine Zeile angelegt, geändert oder entfernt wird. Die Aktion kann E-Mail, Application Message, Task, Workflow, Streams Message oder REST Call sein; Execute Online SQL ist als veraltet (deprecated) aufgeführt. Ein IFS-Mitarbeiter im Thread schlägt diesen Weg vor, um im Hintergrund Logik oder Validierung auszuführen, nachdem die Standardfelder des Dialogs Daten geändert haben. Ob ein bestimmter Dialog in eine Entity schreibt, die ein Ereignis tragen kann, prüfen Sie Dialog für Dialog. Wie sich Events eingrenzen lassen, steht in Custom Events in IFS Cloud.
4. Eine Custom Entity neben dem Datensatz. Der Tailoring-Guide 25R1 dokumentiert, wie eine Standardseite um eine Custom Entity erweitert wird: Sie fügen sie der Projection hinzu, die die Standardseite nutzt, legen im Page Designer eine Liste dafür an und setzen den Filter über Associations. Damit stehen die zusätzlichen Daten auf der Seite, die den Dialog öffnet, und nicht im Dialog. Die Kundenantwort im Thread schlägt für einen Fertigungsauftrag dieselbe Form vor, mit der Custom Entity über Schlüssel verknüpft.
5. Eine eigene Standardseite statt des Dialogs. Ein IFS-Mitarbeiter im Thread schlägt vor, die zugrunde liegende Entity über das Custom-Attributes-Framework um Custom Fields zu erweitern und eine eigene Standardseite zu bauen, die die Funktion des Dialogs anbietet, sodass die Anwender dort arbeiten. Eine Dokumentationsseite, die das als Muster beschreibt, fand ich nicht; es ist der Vorschlag des Mitarbeiters.
6. Projection-Anpassungen und Fragments. Der Kunde, der diesen Weg bevorzugt, sagt, er setze ein Team mit Fähigkeiten im Haus voraus. Ich fand ihn nur im Thread beschrieben, und er ist der Weg, bei dem Sie den größten Codebestand durch jedes Release tragen.

Wo der Thread die einzige Quelle ist, schreibe ich „eine Antwort im Thread sagt“. Wo der Tailoring- oder der Administration-Guide den Punkt abdeckt, nenne ich den Guide.

Die Spalten Pflegeaufwand und Risiko beim Release-Update sind meine eigene Einschätzung aus der Praxis und keine Bewertung von IFS. Nehmen Sie sie als Ausgangspunkt für ein Gespräch über Ihre Systemlandschaft.

Gehen Sie die Tabelle von oben nach unten durch und halten Sie bei der ersten Zeile an, die den Bedarf deckt. Je weiter unten Sie landen, desto größer ist der Teil der Lösung, den Sie selbst pflegen. Dieselbe Überlegung steht hinter der Wahl zwischen Quick Report, Custom Field und Custom Event.

Clean Core heißt: Die Standardobjekte von IFS bleiben unverändert, und jede Änderung liegt im Extensibility Framework, wo ein Release-Update sie mitnehmen kann. Die Grenze bei Dialogen und Assistants drängt Teams zu einer von zwei schlechten Gewohnheiten: einer Modifikation der Standardansicht oder einem Haufen undokumentierter Events, die niemand verantwortet. Beides lässt sich mit der Tabelle oben vermeiden.

• Nehmen Sie die Zeile, die den Dialog in Ruhe lässt. Eine Custom Entity auf der übergeordneten Seite oder ein Event auf der Entity ändert nichts am Dialog selbst, sodass das Release-Update am Dialog weniger stören kann. Die Überlegung steht in Update-sichere Erweiterungen in IFS Cloud und Clean Core in IFS Cloud.
• Halten Sie fest, warum der Dialog nicht erweitert wurde. Eine Zeile je Workaround, die die Grenze und das Datum der Prüfung nennt, erspart dem nächsten Berater, sie neu zu entdecken.
• Überwachen Sie Events nach jedem Update. Ein Event, das nicht länger auslöst, meldet keinen Fehler. Stille Fehler in Custom Code nach dem Upgrade beschreibt diese Fehlerart und eine Heartbeat-Prüfung dagegen.
• Rechnen Sie die Kosten, bevor Sie die unterste Zeile wählen. Die wahren Kosten von Anpassungen in IFS Cloud zeigt, wie sich der Pflegeaufwand über Releases summiert.

CRIMS steht für Configurations, Reports, Interfaces und Modifications: die kundenspezifischen Objekte, die auf dem Standard von IFS Cloud aufsetzen. Der Marktplatz dieser Seite hat eine Kategorie Anpassungen; ihre englische Fassung (Modifications) gibt an, die Einträge seien auf Wartbarkeit und „evergreen“-Kompatibilität mit IFS-Cloud-Updates geprüft. Das ist die Selbstbeschreibung der Kategorie, und sie sagt nicht, wie ein einzelner Eintrag getestet wird.

Ob eine fertige CRIMS-Modifikation Ihre Anforderung trifft oder die Arbeit anhand der Entscheidungstabelle als Eigenbau zugeschnitten wird: Ich prüfe den vorgeschlagenen Ansatz gegen die oben genannten Grenzen, bevor etwas konfiguriert wird, damit Sie am Ende kein Feld haben, das das Framework nicht aufnehmen kann.

30-Minuten-Gespräch buchen CRIMS-Anpassungen ansehen

• Known Limitations, Tailoring-Guide, IFS Cloud 25R1 (auch in der Ausgabe 24R1 gelesen): Abschnitt „Custom Attributes on Assistants“.
• Introduction to Page Designer, Tailoring-Guide, IFS Cloud 25R1
• Extending an existing Page Model: adding a Custom Entity to a standard page, IFS Cloud 25R1
• Manage Event Actions, Administration-Guide, IFS Cloud 25R1
• IFS-Community-Thread: Missing CUSTOM Functions in Dialog and Assistant Views in IFS Cloud (März 2026, 25R1)
• IFS-Community-Thread: Is it Possible to Change Assistant Pages Using Configuration Only? (März 2025, 24R2)
• CRIMS-Marktplatz: Anpassungen

Die Dokumentation wurde in den oben genannten Ausgaben gelesen. Grenzen können sich zwischen Releases ändern; prüfen Sie die Seite Known Limitations für das Release, das Sie einsetzen.

Dariusz Myśliwiec: 18 Jahre Praxis mit IFS, heute mit IFS Cloud. Ich bin IFS Certified Associate Consultant und nach PRINCE2® 7 zertifiziert. Unabhängige Beratung mit Sitz in Krakau, remote in Europa und weltweit. Sie sprechen direkt mit dem Berater, der die Arbeit ausführt.

Ausgewählte Kunden aus meiner IFS-Arbeit: 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.

Der Preis in IFS Cloud ist keine einzelne Zahl am Artikel, sondern ein Satz aus Verkaufspreislisten und Kundenvereinbarungen, deren Zeilen ein Valid From und ein Valid To tragen. Valid To kann leer sein: Eine solche Zeile bleibt gültig, bis eine neuere Zeile mit späterem Valid From sie ablöst. Ist ein Datum gesetzt, wirkt es wie ein Schalter. Auf der einen Seite bepreist sich die Auftragsposition aus der Vereinbarung. Auf der anderen Seite gilt diese Zeile nicht länger, und die Auftragsposition nimmt, was in der Rangfolge als Nächstes kommt.

IFS dokumentiert diese Rangfolge als Leiter der Preisquellen in About Pricing. Ein von Hand an der Auftragsposition eingegebener Preis gewinnt immer. Danach folgen eine manuell gewählte Vereinbarung mit dem Kennzeichen Exclude from Auto Pricing, eine Verkaufskampagne, die automatisch ermittelte Kundenvereinbarung und eine Verkaufspreisliste. Die letzte Stufe ist der Preis aus dem Sales Part. Der Sales Part Base Price, auf derselben Seite beschrieben, ist etwas anderes: Er ist die Grundlage, aus der Preislisten und Vereinbarungen aufgebaut werden, und kein Preis, der in einem Auftrag landet.

Der Schalter fällt nach dem Kalender und nicht durch eine Handlung. Es gibt keinen Klick, keine Freigabe, keine Nachricht. Die Vereinbarungszeile, die am Freitag stimmte, wird am Montag einfach nicht gewählt, und der Auftrag nimmt kommentarlos einen anderen Preis. Der Datensatz existiert weiter, nur sein Gültigkeitsfenster ist vorbei.

Die Gültigkeit wird gegen das Preiswirksamkeitsdatum (price effective date) der Auftragsposition geprüft, und die Preisfindungsmethode je Standort und Kunde bestimmt, welches Datum das ist. Bei Preisfindung nach Lieferdatum nimmt eine Position, die vor dem Ablauf erfasst und danach geliefert wird, den Vereinbarungspreis nicht länger. Bereits erfasste Positionen werden durch den Zeitablauf nicht neu bepreist.

Damit unterscheidet sich dieser Fall von den Preisfehlern, die Sie schon beobachten. Eine Position ohne Preis fällt laut auf, weil der Auftrag nicht sauber weiterläuft. Eine abgelaufene Vereinbarungszeile fällt leise auf, weil der Auftrag problemlos bepreist wird, nur zu einer Zahl, die niemand gewählt hat. Sie kann sogar eine Position unter die Selbstkosten rutschen lassen, wenn der Ersatzpreis niedriger ist als das Geschäft, das Sie einhalten wollten.

Ein Hinweis zur Benennung: Die IFS-Masken heißen Customer Agreement und Sales Price List. „Kundenpreisvereinbarung“ ist kein IFS-Begriff, aber der Ausdruck, nach dem gesucht wird, und bleibt deshalb im Titel dieses Beitrags.

Niemand plant, eine Vereinbarung mitten in der Kundenbeziehung auslaufen zu lassen. Es geschieht an den Nahtstellen der normalen Kundenbetreuung, auf drei wiederkehrenden Wegen.

In jedem dieser Fälle wird der Auftrag weiter bepreist, und genau deshalb bleibt das Problem unsichtbar. Die Lücke zeigt sich später als Marge, die falsch ausfiel, als Kunde, der eine Rechnung gegen die zugesagten Konditionen beanstandet, oder als Vertriebsleiter, der fragt, warum ein Kunde plötzlich auf dem Preis des Sales Part steht. Dann sind die Aufträge angelegt, und als Korrektur bleibt nur die Gutschrift.

Eine zweite stille Grenze gibt es ab Release 25R1: Eine Kundenvereinbarung gilt auch dann nicht länger, wenn sie ihren Maximum Cumulative Amount überschreitet, und für einen einzelnen Artikel, wenn dieser seine Maximum Cumulative Quantity überschreitet. Das Datum kann völlig in Ordnung sein, und die Vereinbarung fällt trotzdem aus der Preisfindung. Dieser Schalter hat mit dem Kalender nichts zu tun, deshalb erfasst eine Liste der nach Datum ablaufenden Vereinbarungen ihn nicht.

Valid From und Valid To stehen in den Zeilen der Preisliste und der Vereinbarung, und ein Monitor kann sie über OData lesen, ohne einen Datensatz zu berühren. Die IFS-Dokumentation behandelt die Gültigkeit von Preislistenzeilen und das Preiswirksamkeitsdatum an der Auftragsposition. Erkennen heißt, nach vorn auf die Daten zu schauen statt zurück auf den Schaden:

1. Zeilen, die in einem gewählten Zeitfenster ablaufen - alles, dessen Valid To in die nächsten Wochen fällt, damit eine Verlängerung geschieht, bevor der Schalter fällt.
2. Abgelaufene Zeilen mit jüngster Auftragsaktivität - eine abgelaufene Vereinbarung bei einem Kunden, der weiter bestellt, ist die Vereinbarung, bei der am wahrscheinlichsten gerade still falsch bepreist wird.
3. Kunden, die ihre einzige Vereinbarung verloren haben - Kunden, die aus einer Vereinbarung bepreist wurden und jetzt keine gültige haben, sodass ihre Positionen unbemerkt auf eine andere Liste oder den Preis des Sales Part fallen.

Weil es sich um ein Überwachungsmuster mit reinem Lesezugriff handelt (so funktioniert es), läuft es neben dem Vertrieb und schreibt nichts nach IFS zurück. Es verlängert keine Vereinbarung, ändert kein Datum und bepreist keinen Auftrag neu, und es soll es auch nicht: Was ein Preis sein soll, ist eine kaufmännische Entscheidung. Es gibt dem Kundenverantwortlichen die Liste der Vereinbarungen, die bald auslaufen, damit die Verlängerung vor dem Valid To geplant wird und nicht erst, nachdem ein Auftrag falsch bepreist wurde.

• Nach vorn schauen, nicht zurück - eine Warnung Wochen vor dem Valid To wiegt schwerer als ein Bericht über Aufträge, die schon falsch bepreist sind. Beginnen Sie deshalb mit dem, was bald abläuft.
• Den Kalender im Trockenlauf prüfen - sehen Sie jede Vereinbarung, die in diesem Quartal abläuft, bevor eine davon abläuft, damit Verlängerungen geplant werden statt hektisch nachgeholt.
• Nach aktiven Kunden ordnen - eine ablaufende Vereinbarung bei einem Kunden, der wöchentlich bestellt, ist wichtiger als eine bei einem ruhenden Kunden, also sortieren Sie nach jüngster Aktivität.
• Von Grund auf nur lesend - nur OData-Lesezugriffe, in IFS wird nichts erweitert oder neu bepreist, und im Kundensystem wird kein neues Objekt installiert.

SCM Automation Pack ansehen 30-Minuten-Gespräch buchen

Dariusz Myśliwiec: 18 Jahre Praxis mit IFS (Apps 7.5 bis 10 und IFS Cloud) in ERP und Supply Chain. Ich bin IFS Certified Associate Consultant und nach PRINCE2® 7 zertifiziert. Ich sitze in Krakau und arbeite als unabhängige Beratung remote 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.

Abweichung hat keine einzelne Ursache und keinen einzelnen Schuldigen. Sie besteht aus hundert kleinen lokalen Entscheidungen, von denen jede im Moment vernünftig war. Ein Disponent stellt fest, dass ein Pflichtfeld den Freitagsandrang bremst, und bittet die IT, es „vorerst“ zu lockern. Ein Teamleiter, der für einen erkrankten Kollegen einspringt, überspringt einen Prüfschritt, weil ihm niemand erklärt hat, wofür er gut ist. Ein Abteilungsleiter, der einen Wochenbericht geerbt hat, weiß nicht, dass dieser einmal etwas Bestimmtes aufgedeckt hat, und halbiert die Frequenz ohne Bedenken. Für sich genommen wirkt jede Entscheidung wie ein kleiner Effizienzgewinn.

Die Summe sieht keiner dieser Beteiligten. Die Dokumentation aus dem Go-live beschreibt weiter den ursprünglichen Entwurf. Niemand pflegt sie nach, während die kleinen Entscheidungen sich anhäufen, denn auch das Nachpflegen gehört zu niemandes Aufgaben. Zwei Jahre später ist die Lücke zwischen dem geschriebenen und dem gelebten Prozess groß genug, um echte Ausnahmen darin zu verbergen. Niemand hat diese Lücke abgenommen. Sie ist einfach entstanden.

Die Kosten entstehen nicht durch einen einzelnen Ausfall, sondern dadurch, dass sich der Raum langsam erweitert, in dem sich ein echtes Problem hinter einer Gewohnheit verstecken kann, die normal wirkt, weil sich alle an sie gewöhnt haben.

• Pflicht wird Kür. Ein Feld, das einmal gelockert wurde, um fünf Minuten zu sparen, lässt jetzt jeden Tag schlechte Daten durch, und niemand erinnert sich, wozu es nötig war.
• Eine Prüfung entfällt stillschweigend. Der Prüfschritt, der eine bestimmte Fehlerart abfangen sollte, läuft nicht. Diese Fehlerart fällt nicht länger auf, und niemand erfährt davon.
• Der Takt wird gedehnt. Ein Wochenbericht, der monatlich erscheint, bedeutet: Ein Problem, das früher in Tagen auffiel, liegt jetzt Wochen, bevor es jemand sieht.
• Rollenwechsel löschen Kontext. Wer verstand, wozu ein Schritt da war, wechselt die Stelle, und der Nachfolger übernimmt die Aufgabe ohne ihren Grund.

Das System bleibt korrekt. Das Verhalten drumherum driftet. Niemand bemerkt es, weil nichts von dem, was sich verschob, je als wichtig gekennzeichnet war.

Abweichung hinterlässt eine Spur, weil in IFS Cloud sowohl der ursprüngliche Entwurf als auch das heutige Verhalten sichtbar sind. Sie müssen beides nur vergleichen, statt eines allein zu lesen. Einstellungen zu Pflichtfeldern, Definitionen von Freigabe-Workflows und Rollenberechtigungen beschreiben, was entworfen wurde. Die tatsächlichen Transaktionsdaten beschreiben, was gelebt wird: der Anteil der Bestellungen, bei denen ein optionales Feld leer bleibt, der Anteil der Freigaben, die einen Schritt übersprungen haben, der auf dem Papier noch existiert, der Abstand zwischen den Läufen eines Berichts, der einmal wöchentlich war.

Einmal ausgeführt, ist dieser Vergleich interessant. Als geplante Prüfung wird er zum Nachweis über die Lücke selbst. Genau diesen Nachweis setzt die Checkliste zur Upgrade-Bereitschaft voraus, bevor ein Release angefasst wird. Dieselben Belege tragen eine Prüfung der Funktionstrennung, denn Rollenabweichung ist eine der Formen, die dieses Muster annimmt.

Abweichung fällt auf die harte Tour auf: bei einer Prüfung, bei einem Zwischenfall, wenn ein neuer Mitarbeiter fragt, warum der Prozess auf dem Papier nicht zu dem passt, was man ihm gezeigt hat. Ein laufender Vergleich entdeckt dieselbe Lücke, solange sie klein und billig zu schließen ist.

Der Nutzen liegt nicht darin, eine einzelne geänderte Feldeinstellung zu finden. Er liegt darin, den Trend so früh zu sehen, dass die Korrektur ein Gespräch ist und kein Projekt.

Sie bauen die Einführung nicht neu. Sie etablieren die Gewohnheit wieder, auf die Lücke zu schauen.

1. Den ursprünglichen Entwurf besorgen. Holen Sie die Dokumentation aus dem Go-live zu Pflichtfeldern, Freigabeschritten und Berichtstakt zurück. Sie ist die Basis, gegen die alles andere verglichen wird.
2. Den Vergleich einmal durchführen. Messen Sie die heutigen Daten gegen diese Basis. Rechnen Sie mit Überraschungen: Die Abweichung sitzt nicht unbedingt dort, wo man sie vermutet.
3. Nach Risiko ordnen, nicht nach Alter. Ein frisch abgewichener Freigabeschritt in einem Prozess mit hohem Wert geht einer zehn Jahre alten kosmetischen Änderung an einem Feld mit niedrigem Risiko vor.
4. Die Lücken mit dem höchsten Risiko zuerst schließen. Wieder anziehen, nachschulen oder die Änderung förmlich akzeptieren. Was Sie auch wählen: Es soll eine Entscheidung sein, kein Zufall.
5. Den nächsten Vergleich terminieren. Die Abweichung läuft ununterbrochen, also muss die Prüfung es auch. Tragen Sie den Termin in den Kalender ein, bevor Sie diese Runde abschließen.

Der Vergleich selbst entsteht im IFS Extensibility Framework mit Standard-Custom-Events, Workflows und PL/SQL. Die Überwachung verlangt deshalb keinen Eingriff in die Kernkonfiguration, die Sie schützen wollen.

30-Minuten-Gespräch buchen SCM Automation Pack ansehen

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. Meine Beratung sitzt in Krakau und arbeitet remote in Europa und darüber hinaus. 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.