Polski (PL) 
English (United Kingdom) 
IFS Cloud Einführung · Anforderungen · Fit-Gap · Konfiguration, Erweiterung, Modifikation
Anforderungen, die die Abnahme überstehen, weil jede Lücke einen Preis und einen Verantwortlichen hat
Der Build setzt die Anforderungen treu um; ein ERP-Projekt scheitert deshalb an Anforderungen, die Monate zuvor weich geworden sind.
1.Auf einen Blick
- Im Monat elf steht der Status seit Wochen auf Grün, der Lenkungskreis nickt, und das Projekt ist trotzdem verloren, weil niemand die Frage gestellt hat, die den Status auf Gelb gedreht hätte. Der Build ist treu gegenüber Anforderungen, die nie ganz real waren.
- Eine Anforderungsliste nach Modulen deckt Übergaben zwischen Teilprojekten nicht ab. Eine Beschreibung als Prozesskette (Order-to-Cash, Procure-to-Pay, Plan-to-Produce) mit einem durchgängigen Verantwortlichen schon.
- Der Standard von IFS deckt nahezu alles ab. Der interessante Rest von 10 bis 20 Prozent entscheidet das Projekt. Jede Lücke hat zwei Preise: das Schließen und das Offenlassen.
- Eine Lücke lässt sich auf drei Wegen schließen: Konfiguration, upgradefähige Erweiterung über das Extensibility Framework oder Modifikation am Core. Wer den Weg im Build zufällig wählt, wählt auch den Verantwortlichen für jedes Upgrade zufällig.
- Zwei Stühle bleiben in der Anforderungsphase leer: der Verantwortliche für die Daten und die Prozessverantwortlichen, die das Fit-Gap-Dokument unterschreiben.
2.Eine Einkaufsliste ist kein Umfang
Anforderungen nach Modulen zu sortieren (Finanzen, Fertigung, Supply Chain, Instandhaltung) wirkt geordnet und vollständig, verfehlt aber die Realität, denn im Unternehmen erlebt niemand ein Modul. Man erlebt einen Kundenauftrag, und ein einzelner Auftrag läuft durch die Hälfte der Module.
Als Module geschrieben
Die Liste enthält Funktionen, die man einschaltet. Jede Übergabe (Auftrag an Fertigung, Lieferung an Rechnung, Rechnung an Hauptbuch) fällt in die Lücke zwischen zwei Teilprojekten, und genau dort brechen Go-lives auseinander.
Als Prozessketten geschrieben
Order-to-Cash, Procure-to-Pay, Plan-to-Produce: Eine Person verantwortet jede Kette über alle Module hinweg. Die Nahtstelle zwischen Fertigung und Finanzen hat damit einen Namen, bevor sie zum Fehler wird.
Prüfen Sie jede Anforderung mit einer Frage: Welcher Kette dient sie, und wer verantwortet diese Kette von Anfang bis Ende? Lautet die ehrliche Antwort „ein Modulname“, ist es noch keine Anforderung, sondern ein Wunsch, alphabetisch abgelegt.
3.„Muss“ ist keine Entscheidung
Der IFS-Standard deckt nahezu alles ab, was ein Unternehmen braucht, bevor jemand etwas anpasst. Die verbleibenden 10 bis 20 Prozent entscheiden das Projekt, und sie werden üblicherweise erledigt, indem man in einer Spalte „Muss“ einträgt und weitergeht. Das fühlt sich wie eine Entscheidung an, ist aber keine.
Jede Lücke hat zwei Preise, und beide gehören auf den Tisch. Der erste ist der Aufwand zum Schließen: Konfiguration, eine Erweiterung oder eine Änderung der Arbeitsweise. Der zweite ist der Aufwand beim Offenlassen: ein Workaround, eine Stunde pro Woche, ein stilles Risiko. Steht in einer Zeile „40.000 für den Bau plus laufende Jahreskosten, um ihn upgradefähig zu halten, gegenüber 20 Minuten pro Woche in einer Tabelle“, erledigt sich der Streit von selbst. Die Hälfte der Muss-Anforderungen erweist sich als Wunsch, den niemand laut so nennen wollte. Was nie bewertet wurde, verschwindet nicht, sondern kommt später als Change Request im ungünstigsten Moment zurück.
4.Jede Lücke hat einen künftigen Eigentümer
Wer eine Lücke im System schließt, entscheidet damit auch, wer sie erbt, denn die Bauweise legt fest, wer bei jedem Upgrade der nächsten zehn Jahre zahlt. IFS bietet drei Wege, die im Workshop ähnlich aussehen und es nicht sind.
| So schließen Sie die Lücke | Was es tatsächlich ist | Wer beim nächsten Release zahlt |
|---|---|---|
| Konfiguration: ein Workflow, eine Regel, ein auf einer Maske gepflegter Wert | Standard | Niemand. Das Upgrade nimmt es mit. |
| Upgradefähige Erweiterung: ein Custom Field oder Logik über das Extensibility Framework | Ergänzung | Wenig, solange sie im Framework bleibt. Sie braucht aber einen Eigentümer und eine Notiz. |
| Eine Modifikation, die in den Core eingreift | Änderung | Jemand wendet sie alle sechs Monate neu an und testet sie neu, solange sie existiert. |
Keiner der drei Wege ist falsch. Der Fehler liegt darin, im Build zufällig zu wählen, an dem Schreibtisch, auf dem das Ticket gelandet ist. Die Wahl gehört in die Anforderungsphase, mit der Person am Tisch, die das Upgrade-Budget unterschreibt.
5.Die Menschen, die nicht im Raum waren
Zwei Stühle bleiben in der Anforderungsphase leer, und beide Rechnungen kommen später mit Zinsen.
Der Verantwortliche für die Daten
Die Datenmigration gilt als technische Aufgabe für das Projektende. Welche Kunden noch aktiv sind, welche Artikel tot sind, welche Kalkulationsmethode je Standort gilt und was „sauber“ für den Artikelstamm überhaupt bedeutet, kann ein Berater nicht beantworten. Erscheint der Datenverantwortliche oder der Controller erst im Monat fünf, entdeckt er, dass hundert kleine Annahmen in seinem Namen getroffen wurden. Ein Teil davon war falsch, und Sie bemerken es beim ersten Monatsabschluss nach dem Go-live.
Die Prozessverantwortlichen
Das Fit-Gap-Dokument ist kein Papier, sondern der Vertrag zwischen dem, was das Unternehmen zu bekommen glaubt, und dem, was gebaut wird. Bleibt es ungezeichnet, driftet es: Jedes „wir sind auch davon ausgegangen“ ist eine stille Änderung, und keine davon verkleinert den Umfang. Lassen Sie es von den Prozessverantwortlichen unterschreiben, nicht von der IT. Mit der Unterschrift wird aus einem Zuschauer ein Mitautor, und der Build wird zu seiner Lösung. Wer die Unterschrift überspringt, vermeidet sie nicht, sondern verschiebt dasselbe Gespräch auf das Go-live-Wochenende, wo es kritischer Fehler heißt und das Zehnfache kostet.
Entscheiden, solange Entscheiden billig ist: In den Anforderungen kostet ein Meinungswechsel eine E-Mail, im Build einen Tag, im Test eine Woche und beim Go-live das ganze Quartal. Alle Schwachstellen oben sind dieselbe: eine Entscheidung, die in eine Phase verschoben wurde, in der sie das Hundertfache kostet.
6.Zurück im Lenkungskreis
Das Projekt im Monat elf war nicht plötzlich krank geworden. Es driftete seit dem Workshop, in dem alle genickt hatten, eine Einkaufsliste einen Umfang ersetzte, „Muss“ eine Entscheidung ersetzte und zwei Stühle leer blieben. Der Bericht war grün, weil noch niemand die Fragen gestellt hatte, die ihn gelb gefärbt hätten.
Stellen Sie die drei Fragen früh, solange die Antwort noch wenig kostet. Erstens: Welcher Prozesskette dient die Anforderung, und wer verantwortet sie? Zweitens: Was kostet es, die Lücke zu schließen, und was kostet es, die Lösung zu pflegen? Drittens: Hat die Person, der die zugrunde liegenden Daten gehören, die Annahme gesehen? Eine Anforderung, die nicht alle drei beantwortet, ist keine Anforderung, sondern ein Change Request, der sich noch nicht vorgestellt hat.
7.FAQ
Warum sollten Anforderungen in IFS Cloud als Prozessketten statt als Modullisten geschrieben werden?
Anforderungen gehören als Prozessketten wie Order-to-Cash, Procure-to-Pay und Plan-to-Produce geschrieben, weil ein Kundenauftrag vom Vertrieb über Fertigung und Lager bis in die Finanzen läuft und die Übergaben zwischen den Modulen sonst in der Lücke zwischen zwei Teilprojekten landen. Eine Person verantwortet jede Kette durchgängig, sodass die Nahtstelle zwischen Fertigung und Finanzen einen Namen hat, bevor sie zum Fehler wird.
Welche drei Wege gibt es, eine Lücke im IFS-Cloud-Standard zu schließen?
Eine Lücke im IFS-Cloud-Standard lässt sich durch Konfiguration schließen (ein Workflow, eine Regel, ein Wert auf einer Maske), durch eine upgradefähige Erweiterung über das Extensibility Framework (Custom Field, Logik) oder durch eine Modifikation, die in den Core eingreift. Konfiguration kostet beim nächsten Release nichts, eine Erweiterung wenig, eine Modifikation muss bei jedem Release neu angewendet und getestet werden.
Wer sollte das Fit-Gap-Dokument in einem IFS-Cloud-Projekt unterschreiben?
Das Fit-Gap-Dokument sollten die Prozessverantwortlichen aus dem Fachbereich unterschreiben, nicht die IT. Die Unterschrift macht aus Zuschauern Mitautoren der Lösung und verhindert, dass stille Annahmen den Umfang unbemerkt verändern.
Was kostet eine Änderung an den Anforderungen in den einzelnen Projektphasen einer IFS-Cloud-Einführung?
Die Kosten einer Änderung steigen mit jeder Phase: In der Anforderungsphase kostet ein Meinungswechsel eine E-Mail, im Build einen Tag, im Test eine Woche und beim Go-live das ganze Quartal.
Ich bin Dariusz Myśliwiec. Ich habe 18 Jahre Praxis 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.
In den Anforderungen klären, nicht in der Hypercare
Ich führe IFS-Cloud-Projekte zum Festpreis nach PRINCE2 und werde dazugeholt, wenn ein Projekt zu lange auf Grün stand. Besteht Ihre Anforderungsphase die drei Fragen nicht, sprechen wir vor dem Build. Sie sprechen direkt mit dem Berater, der die Arbeit ausführt.
Anforderungs-Review buchen Weitere Fachartikel lesen
IFS ist eine eingetragene Marke der IFS AB. Diese Beratung steht in keiner Verbindung zur IFS AB.
