Polski (PL) 
English (United Kingdom) 
Unabhängige IFS-Cloud-Beratung · Einführung
Fit to Standard in IFS Cloud: Design-Workshops, die mit Entscheidungen enden
Fit to Standard in IFS Cloud ist ein Workshop-Format für die Design-Phase: Das Team spielt jeden Geschäftsablauf zuerst im Standardsystem durch und ordnet jede Abweichung sofort ein. Entscheidungen fallen einmal, im Raum, mit benanntem Verantwortlichen. So erreichen nur die Lücken den Build, die im Workshop nicht geschlossen wurden, und die Design-Phase wiederholt dieselben Diskussionen nicht.
Auf einen Blick
- „Fit to Standard“ ist der Name meiner eigenen Arbeitsweise, keine IFS-Methodik. Das Implementation Docs Kit gliedert Projektarbeit in die Phasen Initiate Project, Confirm Prototype, Establish Solution, Implement Solution und Go Live. Ich führe dieses Workshop-Format in Confirm Prototype durch.
- Der Workshop beginnt im System, nicht bei einer Anforderungsliste. Ein Key User führt den Ablauf in einer Demo-Umgebung aus, und das Team ordnet jede Abweichung ein: Konfiguration, Erweiterung, Änderung am Kern oder Änderung der Arbeitsweise.
- Ergebnis eines Workshops ist eine Gap-Liste, in der jede Zeile eine Entscheidung, einen Verantwortlichen, die Kosten für Bau und Betrieb und ein Datum trägt. Eine Zeile ohne diese vier Angaben ist ein offener Punkt, keine Entscheidung.
- Die Zeit pro Ablauf ist begrenzt. Eine Entscheidung, die am Tag nicht reif ist, kommt mit Verantwortlichem und Datum auf die Parkliste, statt erzwungen zu werden.
- Jede Lücke, die per Änderung am Kern geschlossen wird, kostet bei jedem Release Update erneut, das das Unternehmen übernimmt (IFS veröffentlicht zwei im Jahr). Deshalb fällt die Einordnung im Workshop und nicht erst im Build.
Ein Key User sieht eine Folie zum Order-to-Cash-Prozess, der Berater fragt, was fehlt. Niemand berührt das System, und nach drei Stunden ist die Wunschliste länger als zu Beginn. Dieser Artikel beschreibt, wie Sie Design-Workshops vorbereiten, durchführen und abschließen, damit das nicht passiert: die Vorbereitung, die Reihenfolge im Raum, das Ergebnis, das der Build wirklich nutzt, und die Arten, wie das Format scheitert. Zum Umfang der Anforderungen und zum Begriff „Standard“ gibt es eigene Artikel: Anforderungen vor dem Build klären und Standard in IFS Cloud: Was Kunde und Berater meinen.
1.Warum zieht sich die Design-Phase eines IFS-Cloud-Projekts?
Die Design-Phase zieht sich, wenn Workshops bei einem leeren Blatt beginnen, denn dann wird jede Abweichung vom Standard von null an diskutiert, und die Diskutierenden haben das System noch nicht gesehen. Key User beschreiben, wie sie heute arbeiten, der Berater notiert eine Anforderung, und dasselbe Thema kommt zwei Wochen später mit einem anderen Verantwortlichen zurück. Die Entscheidung wandert in eine spätere Phase, in der sie teurer wird.
Die Phase Confirm Prototype soll genau das verhindern. Ein Prototyp auf Standard-IFS-Cloud wird gegen die Prozesse des Kunden bestätigt und nicht aus dem Nichts gebaut. Die Tabelle stellt beide Arten gegenüber, denselben Workshop zu führen.
| Workshop | Ausgangspunkt | Wer führt | Ergebnis | Was offen bleibt |
|---|---|---|---|---|
| Von den Anforderungen aus | Eine Wunschliste je Modul oder Abteilung | Der Berater fragt, der Raum antwortet | Eine längere Anforderungsliste | Welche Punkte der Standard schon abdeckt |
| Vom Standard aus | Ein Geschäftsablauf, im System mit repräsentativen Daten ausgeführt | Ein Key User an der Tastatur, der Berater erklärt, was das System tut | Eine Gap-Liste mit Einordnung, Entscheidung, Verantwortlichem und Kosten je Zeile | Nur geparkte Punkte, jeder mit Verantwortlichem und Datum |
2.Was muss vor dem ersten Workshop bereitstehen?
Fünf Dinge müssen vor dem ersten Workshop vorhanden sein, sonst wird er zur Präsentation.
- Umfang nach Geschäftsablauf, nicht nach Modul. Der Umfang ist eine Liste von Abläufen wie Order-to-Cash oder Procure-to-Pay. Jeder Ablauf hat eine benannte Person, die die Entscheidungen dafür über alle Module hinweg verantwortet.
- Eine Demo-Umgebung mit repräsentativen Daten. Nehmen Sie Daten des Kunden oder einen glaubwürdigen Ersatz, damit der Key User Kunden, Artikel und Preise wiedererkennt. Die Datenvorbereitung beschreibt IFS Cloud Einführung: Datenqualität vor dem Go-live.
- Key User, die die Bildschirme gesehen haben. Eine kurze Einführung vor dem Workshop sorgt dafür, dass die Workshop-Zeit in Entscheidungen fließt und nicht in die Suche nach dem Menü.
- Ein benannter Entscheider je Ablauf. Wenn der Raum uneins ist, entscheidet eine Person, und sie steht vor dem Termin fest.
- Eine Parkregel. Jedes Thema, das am Tag nicht abschließend geklärt werden kann, kommt auf die Parkliste und erhält dort immer einen Verantwortlichen und ein Datum.
3.Wie führen Sie den Workshop selbst?
Führen Sie den Workshop, indem Sie einen Ablauf durch das Standardsystem spielen, ein Key User die Schritte ausführt und jede Abweichung eingeordnet wird, sobald sie auftaucht. Die Einordnung nutzt die drei Türen aus Anforderungen vor dem Build klären plus die Änderung der Arbeitsweise: Konfiguration, eine update-sichere Erweiterung, eine Änderung am Kern oder eine Änderung daran, wie das Unternehmen arbeitet. Der Workshop wendet die Definition von Standard an, die in Standard in IFS Cloud: Was Kunde und Berater meinen beschrieben ist, und verhandelt sie nicht neu.
- Zuerst der Standard. Das System wird gezeigt, bevor eine Änderung gefordert wird. Eine Abweichung wird erst benannt, nachdem das Team gesehen hat, was der Standard an dieser Stelle tut.
- Sofort einordnen. Jede Abweichung bekommt eines der vier Ergebnisse, bevor der nächste Schritt beginnt. Lautet das Ergebnis Änderung am Kern, stehen die Kosten für Bau und Betrieb in derselben Sitzung daneben.
- Ein Zeitlimit je Ablauf. Das Limit schützt die Tagesordnung. Es ist kein Grund, eine Entscheidung zu überstürzen, denn ein Punkt, der nicht reif ist, geht auf die Parkliste.
- Eine feste Regel für Dissens. Der Entscheider des Ablaufs entscheidet, und die abweichende Meinung steht in der Gap-Liste.
Zwei Gewohnheiten zerstören das Format. Eine Vorführung ohne Entscheidungen bringt den Teilnehmern das System bei und lässt das Design unverändert. Eine Diskussion über das Layout von Bildschirmen verbraucht die Zeit, die die Einordnung braucht, obwohl sich das Layout später mit den Werkzeugen der Plattform ändern lässt.
4.Was soll ein Workshop für den Build hinterlassen?
Ein Workshop hinterlässt zwei Listen, die das Build-Team direkt nutzt: eine Gap-Liste mit Entscheidungen und eine Liste offener Punkte mit Terminen. Eine Gap-Zeile ist vollständig, wenn sie den Ablauf, die Abweichung, ihre Einordnung, die Entscheidung, den Verantwortlichen für diese Entscheidung sowie die Kosten für Bau und Betrieb nennt.
Die Liste offener Punkte enthält alles, was geparkt wurde, jeweils mit einer Person und einem Datum, an dem der Punkt wieder auf die Tagesordnung kommt. Dieser Artikel endet dort, wo eine Entscheidung mit Verantwortlichem und Datum aufgeschrieben ist. Wie ein Entscheidungsregister aufgebaut ist und nach dem Go-live gepflegt wird, ist ein eigenes Thema. Das Implementation Docs Kit enthält Vorlagen für diese Phase, darunter das Risk Register and Issue Log (IDK-04) und das CRIM Log (IDK-10).
5.Woher kommt die kürzere Design-Phase, und woran scheitert das Format?
Die Design-Phase wird kürzer, weil drei Arten von Wiederholungsarbeit wegfallen, nicht weil die Workshops gehetzt werden. Entscheidungen fallen einmal und werden festgehalten, deshalb kehren Themen nicht zurück. Die Gap-Liste ist kleiner, weil der Standard gesehen wurde, bevor eine Änderung verlangt wurde. Und jede verbleibende Lücke kommt mit Einordnung und Kosten im Build an, sodass niemand sie neu entdecken muss. Eine Prozentzahl nenne ich nicht: Die Dauer einer Design-Phase hängt von Umfang und Organisation ab, und ich habe für eine solche Zahl keine Quelle, die einer Prüfung standhielte.
Das Format scheitert auf fünf erkennbare Arten:
- Der Workshop wird zur Präsentation. Der Berater klickt, der Raum schaut zu, keine Abweichung wird eingeordnet.
- Die Key User fehlen. Ihre Vertreter können nicht entscheiden, also endet jeder Ablauf mit geparkten Punkten und ohne Entscheidungen.
- Der Umfang folgt den Modulen. Die Übergaben zwischen Modulen fallen zwischen zwei Workshops und tauchen erst im Test auf.
- Lücken sind gelistet, aber nicht bepreist. Eine Lücke ohne Kosten für Bau und Betrieb liest sich wie ein Muss, und die Diskussion beginnt im Build von vorn.
- Die Parkliste wächst unbetreut. Geparkte Punkte ohne Verantwortlichen und Datum werden nie entschieden, und die Liste wird von Workshop zu Workshop länger.
6.Warum ist eine Änderung am Kern in IFS Cloud teurer, als sie im Workshop wirkt?
Eine Änderung am Kern von IFS Cloud ist teurer, als sie im Workshop wirkt, denn IFS veröffentlicht zwei Release Updates im Jahr, und jede Modifikation, die in den Kern eingreift, muss bei jedem Update, das das Unternehmen übernimmt, neu eingespielt und neu getestet werden. Eine so geschlossene Lücke ist ein wiederkehrender Kostenposten, solange sie besteht. Die Folgen beschreibt IFS Cloud Upgrade-Aufwand: Warum Erweiterungen brechen, die Kosten rechnet IFS Cloud Anpassungen: Was Modifikationen wirklich kosten durch.
Deshalb sollte der Workshop zuerst zu den Erweiterungswerkzeugen greifen, bevor er eine Änderung am Kern erwägt: Page Designer, Custom Fields, Custom Events und das Extensibility Framework. IFS Cloud Extensibility: Update-Safe ohne Nacharbeit erklärt, was jedes davon kann und was nicht. Im Workshop genügt es dann, das passende Werkzeug für eine Lücke zu benennen.
7.Wie prüfen Sie Ihren eigenen Workshop-Plan?
Prüfen Sie einen Workshop-Plan mit drei Fragen, und behandeln Sie jeden Plan, der sie nicht beantwortet, als nicht fertig. Erstens: Deckt jede Sitzung genau einen Geschäftsablauf ab, und hat dieser Ablauf einen benannten Entscheider? Zweitens: Führt der Key User die Schritte in einer Demo-Umgebung mit repräsentativen Daten aus? Drittens: Verlässt jede Lücke den Raum mit Einordnung, Kosten für Bau und Betrieb, Verantwortlichem und Datum?
Eine externe Prüfung des Workshop-Plans vor Beginn der Design-Phase lässt sich in einem technischen 30-Minuten-Gespräch mit dem Berater klären, der sie auch durchführen würde.
Prüfung der Design-Phase buchen Implementation Docs Kit ansehen
8.Fragen und Antworten zu Fit to Standard
Was ist ein Fit-to-Standard-Workshop in IFS Cloud, und wie unterscheidet er sich von einer Fit-Gap-Sitzung?
Ein Fit-to-Standard-Workshop ist eine Design-Sitzung, in der ein Geschäftsablauf zuerst im Standardsystem von IFS Cloud ausgeführt und jede Abweichung sofort eingeordnet wird. Eine Fit-Gap-Sitzung gleicht Anforderungen mit dem System ab und listet die Lücken. Der Unterschied liegt im Ausgangspunkt: Der Workshop beginnt im System und entscheidet am selben Tag, die Fit-Gap-Sitzung beginnt bei einer Anforderungsliste. Der Name beschreibt meine eigene Arbeitsweise und ist keine IFS-Methodik. Ich führe den Workshop in der Phase Confirm Prototype durch, einer von fünf Phasen des Implementation Docs Kit: Initiate Project, Confirm Prototype, Establish Solution, Implement Solution und Go Live.
Wer muss im Raum sein, und wer entscheidet bei Uneinigkeit?
Der Key User des Ablaufs muss im Raum und an der Tastatur sein, zusammen mit dem Berater und der Person, die die Entscheidungen für diesen Ablauf verantwortet. Bei Uneinigkeit entscheidet der benannte Entscheider des Ablaufs, und die abweichende Meinung steht in der Gap-Liste. Der Entscheider wird vor dem Workshop festgelegt, damit niemand während des Workshops um Befugnisse verhandelt.
Wie begrenze ich die Zeit eines Workshops, ohne Entscheidungen zu überstürzen?
Setzen Sie ein Zeitlimit je Geschäftsablauf und geben Sie dem Workshop eine Parkliste für Punkte, die nicht reif sind. Wenn die Zeit für einen Ablauf endet, ist jeder offene Punkt entweder entschieden oder mit Verantwortlichem und Datum geparkt. Das Zeitlimit schützt die Tagesordnung, und die Parkliste nimmt den Druck, vor Vorliegen der Fakten zu entscheiden.
Was tun wir mit einer Lücke, die am Workshop-Tag niemand entscheiden kann?
Eine Lücke, die am Tag nicht entschieden werden kann, kommt mit benanntem Verantwortlichen und einem Datum, an dem sie wieder auf die Tagesordnung kommt, auf die Liste offener Punkte. Sie behält ihre Einordnung, falls es eine gibt, und ihre Kosten für Bau und Betrieb, falls sich diese schätzen lassen. Eine geparkte Lücke ohne Verantwortlichen und Datum gilt als unentschieden und erreicht den Build als Change Request.
Bedeutet Fit to Standard, dass es gar keine Anpassungen gibt?
Nein. Fit to Standard heißt, dass zuerst das Standardsystem gesehen wird und jede Abweichung davon eine bewusste Entscheidung mit Preis ist. Konfiguration und update-sichere Erweiterungen wie Custom Fields oder das Extensibility Framework bleiben möglich. Auch eine Änderung am Kern ist möglich, wird aber mit aufgeschriebenen Kosten für Bau und Betrieb entschieden, weil sie bei jedem Release Update, das das Unternehmen übernimmt, neu eingespielt und neu getestet werden muss (IFS veröffentlicht zwei im Jahr).
9.Über den Autor
Dariusz Myśliwiec: unabhängiger IFS-Berater mit 18 Jahren Praxis mit IFS, heute auf IFS Cloud. Ich bin IFS Certified Associate Consultant und nach PRINCE2® 7 zertifiziert. Die Beratung sitzt in Krakau und arbeitet remote in Europa und weltweit. Sie sprechen direkt mit dem Berater, der die Arbeit ausführt.
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.
Die Design-Phase steht an, und für die Workshops fehlt ein Plan?
Bringen Sie Ihre Liste der Geschäftsabläufe und den Workshop-Terminplan mit. Im technischen 30-Minuten-Gespräch sprechen Sie direkt mit dem Berater, der die Prüfung durchführen würde, und erhalten eine Liste dessen, was vor der ersten Sitzung zu ändern ist.
