Blog

• Ein Readiness-Fragebogen mit subjektiven Antworten ersetzt keinen Messwert: Ein Lager, das nicht im vollen Volumen über OData-Projektionen getestet wurde, ist nicht „bereit“.
• Die Go/No-Go-Schwellen lauten: alle automatisierten Tests des kritischen Pfads erfolgreich, null offene Fehler hoher Priorität im UAT, Summen- und Saldenliste innerhalb 0,01 %.
• Testen mit Super-User-Konten verbirgt fehlende Rechte. Am Montagmorgen nach dem Go-live fällt das den echten Anwendern auf.
• Drei Probemigrationen im DMM decken Differenzen auf, bevor sie die Finanzbuchhaltung erreichen, etwa teilgelieferte Bestellungen im letzten Delta-Load.
• Der Mock Cutover von Freitag bis Sonntag macht einen zu knappen Zeitplan sichtbar, solange noch Zeit für Korrekturen ist.

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.

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.

Der Nutzen automatisierter Tests

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.

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.

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.