Polski (PL) 
English (United Kingdom) 
IFS Cloud Projektrettung · Unabhängige IFS-Cloud-Beratung
Ein stehendes IFS-Cloud-Projekt braucht Diagnose, Entscheidung je Bereich und datierte Gates
Wer eine IFS Cloud Einführung retten will, beginnt mit einer Diagnose, die Sie selbst nachprüfen können. Darauf folgen eine Entscheidung je Bereich (behalten, reparieren oder neu aufbauen) und ein Wiederanlaufplan mit datierten Gates. Das Go-live ist zum zweiten Mal verschoben, das Projektteam ist erschöpft: Dort setze ich an.
Auf einen Blick
- Ein Projekt steht, wenn erledigte Aufgaben es dem Go-live nicht näherbringen: Der Termin rutscht, die Testzyklen finden dieselben Fehler wieder und die Liste offener Punkte schrumpft nicht.
- Die Rettung beginnt mit einer Diagnose in fünf Bereichen (Konfiguration, Modifikationen und Erweiterungen, Datenqualität, Schnittstellen, Governance und Akzeptanz). Jeder Befund verweist auf ein Dokument, das Sie selbst öffnen können.
- Die Entscheidung fällt je Bereich. Ein vollständiger Neustart ist nur gerechtfertigt, wenn das Fundament, etwa der Datenansatz oder das Prozessdesign, in allen Bereichen versagt.
- Der Wiederanlaufplan läuft über vier Gates: Scope-Freeze, Daten, Fachbereichstest und Go-live-Reife. Jedes Gate hat ein Datum, einen Verantwortlichen und eine Stopp-Regel.
Eine IFS-Cloud-Einführung bricht nicht mit einer Ankündigung ab. Sie bleibt stehen, wenn das Go-live-Datum zum zweiten Mal wandert und niemand sagen kann, welcher offene Punkt über den nächsten Termin entscheidet. Das Budget läuft weiter, und das Altsystem, das abgeschaltet werden sollte, bleibt in Betrieb. Starten Sie dagegen eine neue Einführung und keine Rettung, ist die Checkliste zur Einführungskrise der bessere Einstieg. Dieser Artikel richtet sich an das Projekt, das bereits in Schwierigkeiten steckt.
1.Warum Einführungen stehen bleiben: vier Ursachen
Zuerst wird die dominante Ursache des Stillstands benannt, denn sie entscheidet, ob das Projekt repariert oder neu aufgebaut wird. Die Diagnose ist um diese vier Gruppen herum aufgebaut.
Architektur und Prozesse, die nicht zum Geschäft passen
Ein Design, das einen Prozess der Einzelfertigung (engineer-to-order), der komplexen Fertigung oder einer verteilten Lieferkette in einen generischen Ablauf presst, erzeugt in jedem Testzyklus Workarounds. Erkennbar ist das am gleichen Fehler, der unter einer neuen Ticketnummer zurückkehrt. Zur Architektur siehe den Artikel Custom Events in IFS Cloud durch Workflows ersetzen.
Daten und Schnittstellen
Schwache Konvertierungsregeln, wiederholt gescheiterte Migrationsläufe und fragile Schnittstellen halten ein Projekt dauerhaft im Test, weil jeder Zyklus mit Daten beginnt, die sich nicht abstimmen lassen. Die technische Schuld aus Modifikationen verschärft das, denn jedes kundenspezifische Objekt muss nach einer Änderung des Datenmodells oder einer Schnittstelle erneut getestet werden. Die wiederkehrenden Muster beschreibt der Artikel zur Datenmigration in IFS Cloud.
Ressourcen und Governance
Ohne erfahrenen Solution Architect entscheidet über das Design, wer gerade im Raum sitzt, und später kann niemand erklären, warum ein Prozess so gebaut ist. Der Solution Architect verantwortet das Lösungsdesign durchgängig und entscheidet, ob eine Anforderung über IFS-Cloud-Standard, Konfiguration oder Erweiterung gelöst wird. Projektmüdigkeit sowie die Abhängigkeit von einer einzelnen Person oder einem Partner, der nicht zum Projekt passt, verschärfen die Lage. Das Wissensrisiko behandelt der Artikel zur ausgebliebenen Übergabe.
Change Management
Geringe Akzeptanz im Anwendertest (UAT) ist ein Projektproblem und kein Anwenderproblem. Eine allgemeine Schulung, die Masken erklärt statt die Arbeit eines Einkäufers, eines Lagermitarbeiters oder eines Disponenten, lässt die Anwender ihren Arbeitstag im System nicht bewältigen, und sie verlangen das alte System zurück.
2.Der Start einer Rettung: eine Diagnose, die Sie prüfen können
Die Diagnose ist eine Bestandsaufnahme in fünf Bereichen, und jeder Befund nennt das Dokument, aus dem er stammt. Sie können dieses Dokument öffnen und ohne mich zum selben Schluss kommen.
| Bereich | Was ich prüfe | Dokument, das Sie öffnen können |
|---|---|---|
| Konfiguration | Ob der Prozess bereichsweise im IFS-Cloud-Standard läuft oder über Workarounds | Konfigurationsexport, Prozessdiagramme, Liste offener Workarounds |
| Modifikationen und Erweiterungen | Jedes kundenspezifische Objekt, sein Verantwortlicher, sein fachlicher Grund und seine Wirkung auf Updates | Liste der Erweiterungen und Modifikationen mit Änderungshistorie |
| Datenqualität | Ob Probemigrationen mit der Quelle übereinstimmen und ob die Regeln schriftlich vorliegen | Protokolle der Probeladungen und Abstimmblätter |
| Schnittstellen | Fehlerbehandlung, Überwachung und Zuständigkeit je Schnittstelle | Schnittstellenverzeichnis und Fehlerprotokolle der letzten Testzyklen |
| Governance und Akzeptanz | Wer entscheidet, wie Änderungen gesteuert werden und ob Anwender im Test ihre Arbeit erledigen können | Protokolle des Lenkungsausschusses, Änderungsregister, UAT-Ergebnisse je Rolle |
Die acht Abweichungssignale und die Bewertung, die ich verwende, beschreibt der Artikel Is Your IFS Cloud Project Off Track? 8 Signals (englisch) auf meiner Beratungsseite, deshalb wiederhole ich sie hier nicht. Die Diagnose ist ein zweiwöchiger Health-Check, der mit einer Entscheidung für jeden Bereich endet: behalten, reparieren oder neu aufbauen.
Für jede Rettung gilt eine Regel: Der Partner, der das Projekt geliefert hat, prüft seine eigene Arbeit nicht. Der bisherige Partner wird befragt und übernimmt einen Teil der Reparaturen. Die Prüfung führt jemand durch, der am Ergebnis kein eigenes Interesse hat.
3.Behalten, reparieren oder neu aufbauen: die Entscheidung je Bereich
Jeder Fachbereich bekommt eine eigene Entscheidung, denn die Finanzen können tragfähig sein, während die Fertigung es nicht ist. Die Tabelle zeigt, wie die drei Ergebnisse für die Bereiche lauten, an denen sich entscheidet, ob ein Projekt live gehen kann.
| Bereich | Behalten, wenn | Reparieren, wenn | Neu aufbauen, wenn |
|---|---|---|---|
| Finanzen | Buchungen in Probeläufen abstimmen und der Kontenplan stabil ist | Die Abstimmung an einzelnen dokumentierten Zuordnungen scheitert | Konten- und Dimensionsdesign die Berichte, die das Unternehmen braucht, nicht liefern können |
| Einkauf und Vertrieb | Aufträge im Standard durchgängig laufen und jeder verbleibende Workaround dokumentiert ist | Der Ablauf funktioniert, aber Freigaben, Preisfindung oder kundenspezifische Regeln geflickt sind | Das Auftragsmodell dem widerspricht, wie das Unternehmen handelt |
| Lager | Wareneingang, Kommissionierung und Inventur die Fachbereichstests bestehen | Lagerorte oder Handhabungsregeln an einzelnen Stellen falsch sind | Die Lagerstruktur für jeden Standort geändert werden muss |
| Fertigung | Arbeitspläne, Stücklisten und die Betriebsdatenerfassung von Disponenten getestet sind | Die Stammdaten unvollständig sind, das Design aber trägt | Das Fertigungsmodell nicht zum Produkt passt, zum Beispiel bei Einzelfertigung (engineer-to-order) |
| Schnittstellen | Jede Schnittstelle einen Verantwortlichen, eine Überwachung und einen getesteten Fehlerpfad hat | Schnittstellen laufen, aber Fehler unbemerkt bleiben | Es sich um Punkt-zu-Punkt-Individualcode handelt, den niemand warten kann |
Die Belege für jede Zelle stammen aus den Dokumenten der Diagnose und nicht aus Meinungen.
An dieser Stelle wird auch die Architektur neu ausgerichtet. Individuallogik, die Standardverhalten doppelt, wird zurückgebaut, und der Bereich kehrt zu einem Clean Core zurück, wenn das günstiger ist, als die Logik durch jedes Release mitzuschleppen. IFS Cloud folgt einem Evergreen-Updatemodell, das auf docs.ifs.com beschrieben ist, deshalb erzeugt jede Modifikation bei jedem Update zusätzlichen Regressionstest. Ob sich eine Anpassung zu behalten lohnt, wird je Objekt entschieden. Die Überlegungen dazu stehen im Artikel Clean Core in IFS Cloud: Einkauf und Lagerbestand.
Ein vollständiger Neustart ist nur gerechtfertigt, wenn das Fundament in jedem Bereich versagt. Ein Datenansatz, der sich nicht abstimmen lässt, und ein Prozessdesign, das dem Geschäftsmodell über Abteilungen hinweg widerspricht, sind die beiden Fälle, die ich zuerst prüfen würde.
4.Der Wiederanlaufplan mit datierten Gates
Der Wiederanlaufplan besteht aus vier Gates, und jedes Gate hat ein Datum, einen benannten Verantwortlichen und eine Stopp-Regel, die festlegt, was bei einem verfehlten Gate geschieht. Die Reihenfolge ist fest. Die Termine der Gates werden aus der Diagnose und dem Stand Ihres Projekts abgeleitet.
- Scope-Freeze. Die Liste dessen, was live geht, wird geschlossen, und jede neue Anforderung läuft über die Änderungssteuerung. Ohne dieses Gate haben die anderen drei kein stabiles Ziel.
- Daten. Probemigrationen stimmen mit der Quelle überein, mit schriftlichen Regeln und einer vereinbarten Toleranz. Die Prüfungen im Einzelnen stehen in der Governance-Checkliste zur Datenmigration.
- Fachbereichstest. Prozessverantwortliche, nicht das Projektteam, spielen ihre eigenen Szenarien durchgängig durch und zeichnen das Ergebnis ab.
- Go-live-Reife. Die Go/No-Go-Entscheidung (die förmliche Freigabe des Lenkungsausschusses vor dem Go-live) fällt nach vorab vereinbarten Kriterien, nachdem der Cutover geprobt wurde.
Vor dem ersten Gate listet der Plan Quick Wins auf: offene Fehler, die bereichsübergreifend blockieren, eine Abstimmung, die an einer einzigen Zuordnung scheitert, oder ein Schnittstellenfehler ohne Verantwortlichen. Sie sind günstig zu beheben und zeigen dem Fachbereich, dass sich das Projekt wieder bewegt.
Der Plan baut auch die Governance neu auf. Er benennt den Solution Architect, richtet eine Design Authority mit protokolliertem Entscheidungslog ein (eine kleine Gruppe, die Designentscheidungen genehmigt oder ablehnt), stellt die Änderungssteuerung vor jede Modifikation und legt den Rhythmus des Lenkungsausschusses fest, damit Entscheidungen protokolliert und nachverfolgt werden.
Die Cutover-Strategie, also die geplante Abfolge der Schritte vom Altsystem in IFS Cloud, ist Teil des Plans und zielt darauf, die Ausfallzeit zu begrenzen. Der Cutover wird geprobt, bevor er zum Einsatz kommt. Die Gründe stehen im Artikel Go-live als Lasttest.
5.Hypercare und rollenbasierte Schulung
Hypercare ist die Phase nach dem Go-live, in der ein benanntes Team Probleme zügig löst, damit die Anwender mit dem neuen System nicht allein bleiben. In einer Rettung wird sie vor dem Start geplant und nicht nachträglich improvisiert. Der Plan legt fest, wer sie besetzt, wie Meldungen priorisiert werden und was sie beendet.
Die Schulung folgt derselben Logik. Jede Rolle wird an der eigenen Arbeit geschult: Der Einkäufer legt eine Bestellung an und gibt sie frei, der Lagermitarbeiter bucht den Wareneingang und kommissioniert, der Disponent fährt den Planungslauf. Allgemeine Maskenschulungen entfallen zugunsten dieser rollenbasierten Schulung. Für jeden Prozess wird ein Mitarbeiter des Fachbereichs als Prozessverantwortlicher benannt, damit Fragen auch nach dem Abzug des Projektteams einen Ansprechpartner haben.
6.Wie das Erstgespräch abläuft
Das Erstgespräch ist ein technisches Telefonat, in dem ich mir das Projekt so zeigen lasse, wie es ist, und nicht so, wie der Statusbericht es beschreibt. Bringen Sie diese vier Unterlagen mit, soweit vorhanden:
- Den Plan mit der Historie der Go-live-Termine, einschließlich jedes verschobenen Datums
- Das Änderungsregister oder die Liste der genehmigten Scope-Änderungen
- Die Protokolle der letzten Migrations-Probeladungen
- Die Liste der Erweiterungen und Modifikationen
Nach dem Gespräch wissen Sie, welche der vier Ursachen dominiert und was die Diagnose abdecken würde. Einen Preis nennt dieser Artikel nicht, weil der Umfang vom Projekt abhängt. Er wird im Gespräch besprochen und schriftlich festgehalten, bevor die Arbeit beginnt.
7.Fragen und Antworten
Was bedeutet es, wenn eine IFS-Cloud-Einführung steht?
Eine IFS-Cloud-Einführung steht, wenn Aufgaben abgeschlossen werden, das Projekt dem Go-live aber nicht näherkommt. Sichtbar wird das an einem wiederholt verschobenen Go-live-Termin, an Testzyklen, die dieselben Fehler wieder finden, an einer Migration, die sich nicht abstimmen lässt, und an einem Altsystem, das sich nicht abschalten lässt.
Sollen wir das IFS-Cloud-Projekt retten oder neu starten?
Ein IFS-Cloud-Projekt wird bereichsweise gerettet und nur dann neu gestartet, wenn das Fundament überall versagt. Jeder Bereich, etwa Finanzen, Einkauf, Lager oder Fertigung, wird anhand der Belege aus der Diagnose behalten, repariert oder neu aufgebaut. Ein vollständiger Neustart ist gerechtfertigt, wenn der Datenansatz oder das Prozessdesign in allen Bereichen versagt.
Wie lange dauert die Rettung eines IFS-Cloud-Projekts?
Die Dauer der Rettung eines IFS-Cloud-Projekts hängt von der Projektgröße und von den Bereichen ab, die repariert werden müssen, deshalb nenne ich keinen Richtwert. Die Diagnose ist ein zweiwöchiger Health-Check, der mit einer Entscheidung je Bereich endet: behalten, reparieren oder neu aufbauen. Danach enthält der Wiederanlaufplan datierte Gates.
Darf der ursprüngliche Einführungspartner die Diagnose seines eigenen Projekts durchführen?
Nein. Der ursprüngliche Einführungspartner sollte befragt werden und einen Teil der Reparaturen übernehmen, sein eigenes Projekt aber nicht prüfen, weil die Diagnose vom Ergebnis unabhängig sein muss. Jeder Befund ist an ein Dokument gebunden, sodass Sie ihn nachprüfen können, ohne einer der beiden Seiten glauben zu müssen.
Was geschieht bei einer Rettung mit unserem Individualcode und den Modifikationen?
Jedes kundenspezifische Objekt wird bei einer IFS-Cloud-Rettung einzeln geprüft. Es bleibt bestehen, wird durch Konfiguration oder Standardfunktion ersetzt oder als updatesichere Erweiterung neu gebaut. Die Entscheidung hängt vom fachlichen Grund des Objekts und vom Regressionstest ab, den es bei jedem Update auslöst. Das Vorgehen beschreibt der Artikel zu updatesicheren Erweiterungen für IFS Cloud.
Das Erweiterungsmodell hinter der letzten Antwort beschreibt der Artikel Updatesichere Erweiterungen in IFS Cloud.
8.Über den Autor
Dariusz Myśliwiec: 18 Jahre Praxis mit IFS. Ich bin IFS Certified Associate Consultant und nach PRINCE2® 7 zertifiziert. Unabhängige Beratung mit Sitz in Kraków, remote tätig in Europa und weltweit. Sie sprechen direkt mit dem Berater, der die Arbeit ausführt.
Ich führe eine unabhängige Beratung und biete Projektprüfungen und Projektrettungen an. Jeder Befund verweist auf ein Dokument, das Sie selbst öffnen können, und die Empfehlung kann lauten, beim bisherigen Partner zu bleiben.
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.
Das Projekt steht und niemand kann sagen, warum?
Bringen Sie den Plan mit seiner Terminhistorie, das Änderungsregister und die Protokolle der letzten Migrations-Probeläufe mit. In einem technischen Gespräch sage ich Ihnen, welche Ursache dominiert und was eine Diagnose abdecken würde.
