Blog

• Der größte Kostenposten nach dem Go-live ist die Pflege von Anpassungen (CRIMS): Impact-Analyse, Refactoring, Regressionstest und Neuabnahme bei jedem halbjährlichen Release Update.
• Ein Clean Core senkt die Update-Kosten über fünf Jahre um bis zu 70 %. Die Beispielrechnung unten ergibt 2.350.000 € gegen 985.000 € Gesamtkosten und eine Differenz von 1.365.000 €.
• Die Update-Dauer in Kalendertagen, vom Sandbox-Test bis zum Produktivgang, ist die wichtigste Kennzahl und fehlt in ROI-Rechnungen: Unter 14 Tage gelten als vorbildlich, über 60 Tage zeigen Anpassungsschulden an.
• Ein Rollen- und Funktionstrennungskonzept (RBAC, SoD) senkt die Zahl der Permission Sets um bis zu 60 % und braucht bei Release Updates keine Neukonfiguration.
• Ein Reifegradmodell mit vier Stufen zeigt, wo Ihre Umgebung steht und was der Aufstieg kostet.

IFS Cloud arbeitet mit Continuous Delivery und halbjährlichen Release Updates, und jedes Update entscheidet darüber, ob sich die Gesamtbetriebskosten (TCO) verbessern oder aus dem Ruder laufen. Ein Finanzchef, der eine Einführung wie eine Produktionsmaschine kalkuliert, rechnet Lizenz, Einführungshonorar und erwartete Zeitersparnis. Er übersieht die laufenden Kosten der Erweiterungen, die den Update-Pfad blockieren.

Die Finanzmodelle aus über 40 Einführungen, die ich geprüft habe, haben denselben Fehler: Sie behandeln das ERP-Projekt als Investition mit festem Zeitplan. Wie viel eigener Code im System liegt, bestimmt allein, wie teuer jedes Release Update wird.

Jede Änderung am Kern des Systems bremst Ihr Projekt bei den Updates auf 25R2 oder 26R1. Eine Architektur, die auf Konfiguration statt auf Codeänderungen setzt, ist die einzige Grundlage für einen positiven ROI über fünf Jahre. Statt die Logik in IFS zu ändern, nutzen Sie Lobbies, Custom Events und ereignisgesteuerte Programmierung, was die TCO senkt.

1. Konfiguration vor Anpassung. Jede fachliche Anforderung wird zuerst gegen die Standardfunktionen von IFS Cloud geprüft: Lobbies, Quick Reports, Custom Fields und Custom Events. Erst wenn der Standard nachweislich nicht reicht, kommt eine Erweiterung in Frage.
2. Integration von außen. Eigene Logik liegt außerhalb des Datenbankschemas des Kerns. OData-Projektionen, REST-APIs und das Framework IFS Connect bilden updatesichere Integrationen.
3. Governance von Anfang an. Ein Change Advisory Board (CAB) mit technischem Vetorecht lässt keinen Code in die Umgebung, ohne dass eine dokumentierte Auswirkungsanalyse auf den Update-Pfad vorliegt. Das ist Steuerung und keine Bürokratie.

Die Tabelle stellt die TCO über fünf Jahre für zwei Fertigungsunternehmen gegenüber: eines mit stark angepasster IFS-Umgebung, eines mit einem Clean-Core-Standard. Die Werte stammen aus Einführungen, die ich beobachtet habe.

So lesen Sie die Summen: Die Gesamtkosten enthalten kein Ausfallereignis. Beim angepassten Kern ergeben 850.000 € plus fünf Jahre Regressionstest (900.000 €) plus fünf Jahre Refactoring (600.000 €) die 2.350.000 €. Jedes fehlgeschlagene Update kommt mit 250.000 € obendrauf.

Die Differenz von 1,365 Mio. € setzt sich aus Einführung, Regressionstests und Code-Refactoring zusammen. Der Clean Core beseitigt nicht alle Kosten, macht sie aber planbar: Aus Feuerwehreinsätzen werden budgetierte Wartungsarbeiten.

Vage Effizienzgewinne ersetzen Sie am besten durch vier Kennzahlen, die sich aus dem System ablesen lassen.

Standardabdeckung

Gemessen wird der Anteil der Geschäftsprozesse, die ohne eine Zeile Code auf den IFS-Cloud-Standard abgebildet wurden. Jeder Prozentpunkt über 80 % spart beim nächsten Update Geld. In meiner Beratung lehne ich Aufträge ab, bei denen der Zielwert unter 85 % liegt, weil dahinter ein Widerstand gegen Veränderung steht, den kein technisches Können auflöst.

Zeit bis zur Auskunft

Mit Power BI und der OData-Anbindung wird die Zeit von der fachlichen Frage bis zur Antwort aus IFS Cloud in Minuten gemessen. Exportiert Ihr Team Daten weiterhin nach Excel, um sie von Hand aufzubereiten, ist der ROI negativ.

Update-Dauer

Diese Kennzahl misst die Kalendertage, die Ihre Organisation braucht, um ein IFS Release Update vom Sandbox-Test bis zum Produktivgang vollständig einzuspielen. Vorbildliche Organisationen schließen den Zyklus in unter 14 Tagen ab. Dauert Ihr Update-Zyklus über 60 Tage, vernichten Ihre Anpassungsschulden aktiv Wert.

Verhältnis von Erweiterung zu Konfiguration

Gezählt werden die Anforderungen, die eigenen Code verlangten, im Verhältnis zu denen, die sich mit Standardkonfiguration (Custom Fields, Custom Events, Lobbies, Quick Reports) lösen ließen. Ein gesundes Verhältnis liegt bei 1:8 oder besser, also acht Konfigurationslösungen auf eine Erweiterung. Es gehört in jede Sitzung des Lenkungsausschusses und in den Bericht an die Finanzleitung.

Das Reifegradmodell mit vier Stufen entstand aus Mustern, die ich in Produktivumgebungen aus Fertigung, Logistik und Energie beobachtet habe, und dient als Maßstab für Ihre IFS-Cloud-Umgebung.

Der Aufstieg auf Stufe 3 oder höher rechnet sich: Mit jeder Stufe sinken die jährlichen Update-Kosten um etwa 40 % und das Ausfallrisiko um eine Größenordnung.

Der ROI zeigt sich beim ersten Release Update, nicht beim Go-live. Wer nicht kontrolliert, was Entwickler in die Umgebung einbringen, endet in der Updatelähmung. Beratung heißt, den Kunden davor zu bewahren, das System zu beschädigen, statt jedem Wunsch von Einkauf oder Logistik zu folgen. Dieser Ablauf hält eine IFS-Cloud-Umgebung updatefähig:

1. Quartalsprüfung der Erweiterungen. Alle 90 Tage gleicht ein Senior-Architekt sämtliche CRIMS und jeden eigenen Code mit den Notes des kommenden Release Updates ab. Als gefährdet markierte Änderungen gehen ans CAB zur Ablösung oder zum Umbau auf API-Basis.
2. Vorprüfung in der Sandbox. Bevor ein Release Update die Testumgebung erreicht, spielt eine Sandbox-Kopie es isoliert ein. Automatisierte Regressionstests laufen über alle kritischen Geschäftsabläufe: Beschaffung bis Zahlung, Auftrag bis Zahlungseingang und der Lebenszyklus des Wartungsauftrags.
3. UAT mit fachlicher Freigabe. Die Key-User führen vordefinierte Testskripte für ihr Tagesgeschäft aus. Ohne dokumentierte Freigabe jedes Fachbereichsverantwortlichen geht kein Update in Produktion. Das entspricht dem PRINCE2®-Prinzip „Management by Exception“.
4. Produktivgang und Rückblick. Das Update wird in einem geplanten Wartungsfenster mit dokumentiertem Rücksetzplan eingespielt. Innerhalb von 5 Arbeitstagen hält ein Rückblick die Erkenntnisse fest und führt sie in das Governance-Modell zurück.

Eigene Logik gehört nicht in das PL/SQL im IFS Application Server, sondern in externe Dienste, die über stabile Schnittstellen mit IFS Cloud sprechen. Der Zugriff läuft über drei Wege:

• OData-Projektionen - strukturierte Geschäftsdaten lesen und schreiben, mit allen CRUD-Operationen über Standard-HTTP-Verben.
• IFS Connect - ereignisgesteuerte Architektur: Das System veröffentlicht ein Ereignis, wenn ein Geschäftsobjekt seinen Status ändert, und externe Systeme abonnieren es.
• REST-API-Endpunkte - eigene Geschäftslogik als zustandslose Dienste, die IFS Cloud über Custom Events oder Workflow-Automatisierung aufruft.

Dieses Muster entkoppelt Ihre Logik vom IFS-Kern. Kommt das Release Update 26R1, laufen Ihre Integrationen weiter, weil sie auf stabilen API-Verträgen aufsetzen und nicht auf internen Datenbankschemata, die IFS ändern darf. Den Aufbau einer solchen Schnittstelle beschreibt der Artikel IFS Cloud API Integration mit OData und OAuth 2.0.

Ein Berechtigungskonzept, das am Tag vor dem Go-live nachgeholt wird, kostet später Geld. Ein sauberes rollenbasiertes Zugriffsmodell (RBAC) mit Funktionstrennung (Separation of Duties, SoD) trägt direkt zum ROI bei:

• Vermiedene Prüfungsbefunde - ein Befund kostet 50.000–200.000 € an Behebung und Beratung.
• Permission Sets um bis zu 60 % reduziert - durch Context Substitution: Derselbe Benutzer erbt je nach aktivem Unternehmen oder Standort andere Rechte.
• Schnellere Updates - ein gut entworfenes Sicherheitsmodell braucht bei Release Updates keine Neukonfiguration.

Zu großzügige Rechte führen zu gescheiterten Prüfungen, zu knappe Rechte zu Umgehungslösungen in der Schatten-IT. Beides beseitigt nur eine eigens entworfene RBAC-Matrix.

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.