Blog

• Beim nächsten Pflicht-Release scheitern Eigenentwicklungen und OData-Integrationen dort, wo niemand sie getestet hat. Ein Testkonzept fängt das ab, bevor das Release die Produktion erreicht.
• Drei Probemigrationen im IFS Data Migration Manager (DMM) prüfen nacheinander Struktur, Volumen und den minutengenauen Ablauf des Wochenendes.
• TSAK (IFS Cloud Test Automation Tool) deckt mindestens 80 % der Kerntransaktionen ab. Das Team prüft von Hand nur die restlichen 20 %, die für Ihr Unternehmen einmalig sind.
• Der Mock Cutover läuft von Freitag bis Sonntag. Braucht das Laden der Daten 48 Stunden, das Geschäft erlaubt aber nur 24, liegt ein Strukturproblem vor, das vor dem Termin sichtbar sein muss.
• Hypercare dauert mindestens eine volle Finanzperiode, damit der erste Monatsabschluss im neuen System gelingt.

Ein Testkonzept in IFS Cloud muss verhindern, dass Ihre Erweiterungen und OData-Integrationen beim nächsten verpflichtenden Service-Update zusammenbrechen. Die Gewohnheiten aus Apps 9 oder 10 tragen dafür nicht: Dort wurde einmal getestet und dann jahrelang betrieben, hier ändert sich die Plattform halbjährlich.

Die Folge ist die Updatelähmung. Eine Organisation traut sich das nächste Release nicht zu, weil ihre Anpassungen zu fragil sind, um den Wechsel zu überstehen. Ein Team, das jedes Release von Hand testet, lässt irgendwann Releases aus und bleibt auf einer nicht länger unterstützten Version zurück. Diese Lage vermeidet, wer die Testautomatisierung von Beginn an einplant.

Das Testen beginnt in der Entwurfsphase, mit dem Nein der Design Authority. Eine Anforderung, die sich weder auf einen Standardprozess noch auf einen Low-Code-Workflow abbilden lässt, ist eine künftige Fehlerquelle. Mit konsequenter Standardisierung schrumpft die Testoberfläche um 40–60 %.

Clean Core heißt: Der Standard bleibt unverändert, Änderungen laufen über den IFS Cloud Workflow Designer oder externe Integrationen. Jede Anforderung muss sich gegen die Standardfunktion behaupten. Lässt sie sich durch einen geänderten Prozess erfüllen, wird der Prozess geändert.

Technische Infrastruktur

IFS Cloud ist kein Monolith, sondern eine Sammlung von Microservices, die über die Aurena-Oberfläche erreichbar sind. Direkter Datenbankzugriff entfällt, und wer seine Integration auf SQL oder Tabellenzugriff stützt, besteht das erste Security-Audit nicht. Sicherheit läuft über OAuth 2.0, der Datenaustausch über OData-Projektionen. Die Testsuite muss diese Endpunkte unter Last prüfen.

• IAM-Konfiguration - Identity and Access Management mit Single Sign-On (SSO) als Grundlage der Anwenderakzeptanz.
• Umgebungsstufen - Build, Development, Test (UAT) und Produktion, jede mit eigenem Zweck auf dem Weg zum Go-live.
• Konnektivität - native Projektionen oder Werkzeuge wie n8n für die Orchestrierung.

Ein Prozess, den Sie nicht zeichnen können, lässt sich in IFS Cloud nicht konfigurieren. BPMN 2.0 ist die Sprache des Workflow Designers, und im Test dient das Diagramm als Referenz: Weicht das Systemverhalten vom Modell ab, ist das ein Fehler.

Logik, die in PL/SQL-Code vergraben liegt, ist für Analysewerkzeuge unsichtbar. Die Fachberater sehen sie im Modell, bevor die erste Zeile Konfiguration entsteht.

Die Datenmigration ist das größte Risiko für den Go-live-Termin. Excel-Uploads und das alte Werkzeug FndMig laden ungeprüfte Daten in ein System, das Altlasten nicht verzeiht. Der IFS Data Migration Manager (DMM) bietet eine strukturierte Umgebung, in der Daten bereinigt, transformiert und validiert werden, bevor sie die Zielumgebung berühren.

Diese Bereinigung verhindert Differenzen in der Summen- und Saldenliste. Wer Daten nicht sauber aufbereitet, lässt automatisierte Workflows scheitern und erzeugt Berichtssilos, die das Unternehmen über Jahre begleiten.

Testen ist unter Evergreen eine laufende Aufgabe, keine Projektphase, daher gehört die Regressionssuite automatisiert. Das IFS Cloud Test Automation Tool (TSAK) oder ein vergleichbares Framework deckt mindestens 80 % Ihrer Kerntransaktionen ab. Das Team prüft von Hand nur die 20 % der Logik, die für Ihr Unternehmen einmalig sind. Für jeden eigenen BPMN-Workflow gibt es ein zugehöriges automatisiertes Skript. Die laufenden Wartungskosten sinken dadurch um 40–60 %.

• Unit-Test - jede Konfiguration und jeder Workflow wird einzeln geprüft.
• Integrationstest - Daten fließen zwischen IFS und externen Systemen wie CRM oder MES.
• UAT (Abnahmetest) - Endabnahme durch die Fachanwender in einer eigenen Umgebung.
• Rollenprüfung - das Modell der minimalen Rechte stellt sicher, dass Anwender nur auf die nötigen Projektionen zugreifen.

Wurde das UAT mit Super-User-Konten durchgeführt, scheitert der Go-live am Montagmorgen: Echte Anwender melden sich an und stellen fest, dass ihnen Rechte für einfache Aufgaben fehlen. Die Sicherheitsprüfung ist daher eine eigene Phase, in der jede Fachrolle gegen die Dokumente der Prozessmodellierung validiert wird.

Ein Workflow, der zehn Sekunden für die Prüfung einer Transaktion braucht, wirkt im Test mit einem Anwender akzeptabel. Mit fünfhundert Anwendern in Produktion legt derselbe Workflow das Lager lahm. Simulieren Sie Spitzentage wie den Monatsabschluss, damit die Serviceschicht reaktionsfähig bleibt.

Der Mock Cutover ist die Generalprobe im vollen Umfang, von Freitag bis Sonntag. Sie simulieren die Datenextraktion, die Transformation im DMM und das finale Laden in eine saubere, produktionsnahe Umgebung. Jeder manuelle Schritt, der länger dauert als geplant, wird optimiert oder automatisiert.

Zeigt die Probe, dass das Laden der Daten 48 Stunden braucht, das Geschäft aber nur ein Fenster von 24 Stunden erlaubt, liegt ein Strukturproblem vor. Die Probe prüft auch das Zusammenspiel der Menschen: Hält das technische Team ein Fenster von 36 Stunden durch, und antworten die n8n-Endpunkte unter hoher Synchronisationslast korrekt? Wer den Cutover nicht geprobt hat, übt am laufenden Geschäft.

Das Wochenende selbst: Leitstand und No-Go

Der echte Cutover folgt einem minutengenauen Plan, und ein gelungener verläuft unspektakulär, weil jeder Schritt in Mock 3 geprobt wurde. Ein Leitstand (Command Centre) meldet alle dreißig Minuten den Stand. Dauert ein Schritt 10 % länger als geplant, greift sofort der Ausweichplan.

Die Kriterien für den Abbruch legen Sie vorher fest. Gleicht sich die Summen- und Saldenliste bis zu einem festen Termin nicht innerhalb der Toleranz ab, wird zurückgerollt. Wie solche Schwellen aussehen, zeigt der Artikel zu den Go/No-Go-Kriterien.

Hypercare dauert mindestens eine volle Finanzperiode, damit der erste Monatsabschluss gelingt und kleine Störungen behoben sind, bevor das Projektteam aufgelöst wird. Gemessen wird sie am sinkenden Aufkommen von Support-Tickets und an der Stabilität der OData-Serviceschicht.

In dieser Zeit wird auch die Workflow-Automatisierung nachjustiert. Weichen Anwender mit Workarounds vom Standardprozess ab, lagen Entwurf oder Schulung daneben. Nutzen Sie die Phase, um die Clean-Core-Regeln zu festigen, bevor das erste Evergreen-Update kommt. Wie die vorangehenden Phasen aussehen, steht in der Checkliste für ein Clean-Core-Projekt.

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.