Vorlage IDK-01, Version 1.0. Phase: Initiate Project.
So verwenden Sie diese Vorlage
Schreiben Sie den Plan in der Phase Initiate Project, bevor ein Design-Workshop gebucht ist. Er ist die Vereinbarung zwischen den beiden Projektleitungen darüber, wie das Projekt geführt wird.
Die Projektleitung des Auftragnehmers entwirft ihn. Die Projektleitung des Auftraggebers prüft jeden Abschnitt und liefert die Namen, Kalender und Randbedingungen auf Seiten des Auftraggebers.
Ersetzen Sie jedes [Feld in eckigen Klammern]. Löschen Sie die mit Beispiel: markierten Zeilen, sobald Sie eigene Inhalte haben.
Fertig ist der Plan, wenn der Lenkungsausschuss ihn freigegeben hat und jede Baseline (Termine, Kosten, Lösungsumfang, Projektumfang) eine Version und ein Datum trägt.
Nach der Freigabe ändert sich in den Abschnitten 3 bis 6 nichts ohne das Verfahren aus Abschnitt 6.4.
Metadaten der Vorlage
Feld
Wert
Vorlagen-ID
IDK-01
Phase
Initiate Project
Verantwortlich
Projektleitung des Auftragnehmers (mit Unterstützung der Projektleitung des Auftraggebers)
Freigabe
Lenkungsausschuss
Qualification Gate
Project Initiated
Version
1.0
Dokumentenlenkung
Version
Datum
Autor
Änderung
Freigegeben von
0.1
[JJJJ-MM-TT]
[Name, Rolle]
Erster Entwurf
1.0
[JJJJ-MM-TT]
[Name, Rolle]
Baseline für das Gate Project Initiated
[Vorsitz des Lenkungsausschusses]
1. Projektübersicht
Punkt
Wert
Auftraggeber
[Name der rechtlichen Einheit]
Auftragnehmer
[Einführungspartner oder Berater]
Projektname und Projektkürzel
[Name] / [Kürzel]
Verweis auf Vertrag oder Leistungsbeschreibung
[Verweis, Datum]
Geschäftsleitender Sponsor (Auftraggeber)
[Name]
Sponsor (Auftragnehmer)
[Name]
Projektleitungen
Auftraggeber: [Name]. Auftragnehmer: [Name]
Betriebsmodell
[IFS Cloud, von IFS betrieben / Remote Deployment beim Auftraggeber]
Standorte und Unternehmen im Umfang
[Liste]
Ziel-Go-live
[Datum oder Zeitraum, im Projekt vereinbart]
Zweck in einem Satz
[Warum das Unternehmen dieses Projekt durchführt]
Zweck, Ziele und Nutzen stehen ausführlich im Projektumfang (Vorlage IDK-02). Dieser Plan beschreibt, wie die Arbeit gesteuert wird.
2. Vorgehensweise der Einführung
Das Projekt folgt fünf Phasen. Jede Phase endet mit einem Qualification Gate, an dem der Lenkungsausschuss die vereinbarten Liefergegenstände bestätigt und die nächste Phase freigibt.
Phase
Was die Phase erreicht
Abschließendes Gate
Initiate Project
Beide Teams aufgestellt, Plan und Umfang festgelegt, Steuerung eingerichtet
Project Initiated
Confirm Prototype
Erster Prototyp ausgewählter durchgängiger Prozesse mit Beispieldaten des Auftraggebers, Lösungsumfang bestätigt
Solution Confirmed
Establish Solution
Design, Aufbau und Test abgeschlossen, endend mit dem Solution Acceptance Test
Solution Established
Implement Solution
Cutover vorbereitet und geprobt, Benutzer geschult, Operational Readiness Test bestanden
Go Live Authorised
Go Live
Cutover durchgeführt, Altsystem abgelöst, Übergabe an den Support, Projekt abgeschlossen
Go Live Complete
Leitprinzip für die Lösung: Decken Sie jeden Prozessbedarf zuerst mit Standardfunktionen ab. Konfigurationen, Berichte, Schnittstellen und Modifikationen (CRIM) bleiben auf die kleinste Menge begrenzt, die der Fachbereich begründen kann, denn jedes angepasste Objekt muss jedes Service Update und Release Update überstehen.
3. Terminbaseline
Baseline-Version: [n.n], datiert [JJJJ-MM-TT]. Der laufende Terminplan liegt in [Planungswerkzeug]. Diese Tabelle ist die freigegebene Referenz, gegen die der Fortschritt berichtet wird.
3.1 Phasen und Gates
Phase
Geplanter Beginn
Geplantes Ende
Gate
Geplanter Gate-Termin
Sitzung des Lenkungsausschusses gebucht
Initiate Project
[JJJJ-MM-TT]
[JJJJ-MM-TT]
Project Initiated
[JJJJ-MM-TT]
[ja/nein]
Confirm Prototype
[JJJJ-MM-TT]
[JJJJ-MM-TT]
Solution Confirmed
[JJJJ-MM-TT]
[ja/nein]
Establish Solution
[JJJJ-MM-TT]
[JJJJ-MM-TT]
Solution Established
[JJJJ-MM-TT]
[ja/nein]
Implement Solution
[JJJJ-MM-TT]
[JJJJ-MM-TT]
Go Live Authorised
[JJJJ-MM-TT]
[ja/nein]
Go Live
[JJJJ-MM-TT]
[JJJJ-MM-TT]
Go Live Complete
[JJJJ-MM-TT]
[ja/nein]
Buchen Sie alle Termine des Lenkungsausschusses jetzt. Die Kalender der Führungskräfte sind die erste Einschränkung, auf die ein Projekt trifft.
3.2 Meilensteine
ID
Meilenstein
Phase
Verantwortlicher
Baseline-Termin
Nachweis, dass er erreicht ist
Beispiel: M-03
Build Place steht dem Projektteam zur Verfügung, Umgebungen im Use Place sind für das vereinbarte Betriebsmodell angelegt
Initiate Project
Systemingenieur des Auftragnehmers
[JJJJ-MM-TT]
Teammitglieder melden sich mit namentlichen Konten an; Umgebungsliste in Abschnitt 9 aktualisiert
Beispiel: M-11
Prototyp für Einkauf und Lager mit Beispieldaten des Auftraggebers vorgeführt
Confirm Prototype
Fachlicher Leiter des Auftraggebers, Supply Chain
[JJJJ-MM-TT]
Vorführung durchgeführt, Teilnehmerliste und offene Punkte festgehalten, Prototyp-Abnahme unterzeichnet
[ID]
[Meilenstein]
[Phase]
[Rolle oder Name]
[JJJJ-MM-TT]
[Nachweis]
3.3 Randbedingungen im Kalender
Randbedingung
Zeitraum
Auswirkung auf den Plan
Beispiel: Geschäftsjahresende und Jahresinventur
[Zeitraum]
Kein Cutover, keine Workshops, für die Leitungen aus Finanzen oder Lager nötig sind
Arbeit außerhalb der Leistungsbeschreibung beginnt erst nach einem genehmigten Änderungsantrag (Vorlage IDK-07).
Der Budgetstatus wird berichtet als: Baseline, genehmigte Änderungen, Ist bis heute, Prognose bis zum Ende, Abweichung.
5. Baseline des Lösungsumfangs
Baseline-Version: [n.n], datiert [JJJJ-MM-TT]. Das Prozessmodell wird in [IFS Scope Tool oder vereinbartem Repository] gepflegt. Die folgende Tabelle fasst zusammen, das Modell enthält die Details.
Prozessbereich
Durchgängige Prozesse im Umfang
Standorte und Unternehmen
Abnahmekriterium
Abnehmende Rolle
Beispiel: Einkauf
Von der Bestellanforderung bis zum Abgleich der Lieferantenrechnung, einschließlich der Freigabe von Bestellanforderungen
[Standorte]
Die Szenarioskripte des Prozesses bestehen den Solution Acceptance Test, ausgeführt mit Permission Sets für Endbenutzer und migrierten Lieferanten- und Artikeldaten, ohne offene betriebskritische Fehler
Fachlicher Leiter des Auftraggebers, Einkauf
Beispiel: Lager
Wareneingang, Einlagerung, interne Lagerbewegung, Zählung und Korrektur
[Standorte]
Wie oben, einschließlich Scannen mit Handterminals im physischen Lager
Fachlicher Leiter des Auftraggebers, Lager
[Bereich]
[Prozesse]
[Standorte]
[Kriterium]
[Rolle]
Bekannte CRIM-Punkte zum Zeitpunkt der Baseline:
ID
Typ (C/R/I/M)
Beschreibung
Fachlicher Grund
Status
Beispiel: CRIM-004
I
Ausgehende Bestelldaten an das Transportplanungssystem, über eine Standard-Projection per OData gelesen
Die Buchung des Frachtführers setzt bestätigte Bestellpositionen voraus
Erfasst, noch nicht spezifiziert
[ID]
[Typ]
[Beschreibung]
[Grund]
[Status]
6. Baseline des Projektumfangs
6.1 Annahmen und Voraussetzungen der Leistung
#
Annahme oder Voraussetzung
Verantwortlich
Benötigt bis
Folge bei Nichterfüllung
Beispiel: A-02
Die Kernteam-Mitglieder sind für den vereinbarten Anteil ihrer Zeit vom Tagesgeschäft freigestellt, und ihre Vorgesetzten haben die Vertretung bestätigt
Geschäftsleitender Sponsor
Beginn von Confirm Prototype
Workshops verschieben sich; die Terminbaseline wird über die Änderungssteuerung neu geplant
Beispiel: A-07
Der Auftraggeber extrahiert die Altdaten für jeden Ladezyklus im vereinbarten Format
Datenverantwortlicher des Auftraggebers
Jeder Termin eines Ladezyklus im Migrationsplan
Der Ladezyklus entfällt, er wird nicht gekürzt; die Zeit für die Validierung bleibt geschützt
[ID]
[Annahme]
[Rolle]
[Datum oder Meilenstein]
[Folge]
6.2 Rollen und RACI-Verweis
Rollenbeschreibungen, benannte Personen, Zeitzusage und die RACI-Matrix je Liefergegenstand stehen in der Projektorganisation mit RACI (Vorlage IDK-03), Version [n.n]. Dieses Dokument gehört zu dieser Baseline.
Standardzuständigkeit für Projektdokumente:
Dokumentengruppe
Verantwortlicher
Unterstützt von
Projektmanagementplan, Projektumfang, Masterplan der Einführung, Workshop- und Aktivitätenplan
Projektleitung des Auftragnehmers
Projektleitung des Auftraggebers
Risikoregister, Issue-Log, Kommunikationsplan, Strategien (Test, Schulung, Daten, Infrastruktur, Business Change, Stilllegung des Altsystems)
Projektleitung des Auftraggebers
Projektleitung des Auftragnehmers
6.3 Test- und Abnahmeverfahren
Punkt
Vereinbarung
Wer die Tests steuert
Der Auftraggeber steuert alle Tests außer dem Unit-Test entwickelter Objekte. Der Auftragnehmer unterstützt.
Dokument zur Teststrategie
Verantwortlich: [Rolle]. Fällig: [JJJJ-MM-TT]. Enthält Methode, Skriptvorlage, Testplan, Skriptautoren, Kennzahlen, Tester, Eingangs- und Ausgangskriterien je Zyklus, Umgebung je Zyklus, Werkzeuge.
Testzyklen
Verifizierung der Anwendungslösung; Verifizierung mit Sicherheitskonfiguration und migrierten Daten; Solution Acceptance Test; Cutover-Probelauf; Operational Readiness Test
Klassifizierung von Fehlern
Ursache (Daten, Bedienfehler, Anwendungsfehler, falsche Lösung), blockiert die Auslieferung (ja/nein), vertraglich relevant (ja/nein), Seite des Verantwortlichen, Zieltermin für die Schließung
Triage von Fehlern
[Turnus, im Projekt vereinbaren], Vorsitz [Rolle]
Abnahme eines Liefergegenstands
Der Prüfer antwortet innerhalb von [im Projekt vereinbaren]. Schweigen gilt nicht als Zustimmung. Die Abnahme wird in [Werkzeug oder unterzeichnetes Formular] festgehalten.
Abnahme von CRIM-Spezifikationen
Schnittstellen und Modifikationen: Funktionsspezifikation vom Auftraggeber freigegeben, dazu die kaufmännische Vereinbarung, vor der Entwicklung. Konfigurationen und Berichte: Spezifikation von der Projektleitung des Auftraggebers vor dem Aufbau freigegeben.
6.4 Verfahren zur Änderung der Baseline
Jedes Teammitglied kann eine Änderung einbringen. Sie wird auf dem Formular für Änderungsanträge (IDK-07) schriftlich festgehalten, bevor sie in einer Besprechung diskutiert wird.
Beide Projektleitungen bewerten die Auswirkung auf alle vier Baselines.
Entscheidungsbefugnis: [Schwellenwerte und Rollen, im Projekt vereinbaren]. Alles, was Umfang, Go-live-Termin, Budget oder eine Modifikation berührt, geht an den Lenkungsausschuss.
Genehmigte Änderungen erzeugen eine neue Version der Baseline. Das Änderungslog führt auf, was sich verschoben hat und warum.
Die Arbeit an einer Änderung beginnt nicht vor der Genehmigung.
7. Planungswerkzeuge und Ablauf
Zweck
Werkzeug
Gepflegt von
Aktualisierungsrhythmus
Masterplan der Einführung
[Werkzeug]
Projektleitung des Auftragnehmers
[im Projekt vereinbaren]
Workshop- und Aktivitätenplan
[Werkzeug]
Projektleitung des Auftragnehmers mit den fachlichen Leitern
[im Projekt vereinbaren]
Projekt-Tracker (Fortschritt und Kennzahlen je Arbeitsstrang)
[Werkzeug]
Beide Projektleitungen
[im Projekt vereinbaren]
Risikoregister und Issue-Log
[Werkzeug]
Projektleitung des Auftraggebers
Geprüft in jeder Sitzung des Projektteams
Prozessmodell und Umfang
[IFS Scope Tool oder vereinbartes Repository]
Lösungsarchitekt
Nach jedem Workshop
Testskripte und Fehler
[Werkzeug]
Testleitung des Auftraggebers
Täglich während der Testzyklen
Dokumentenablage
[Ablageort]
[Rolle]
Laufend
Planungsablauf: Jede Leitung eines Arbeitspakets plant den kommenden Zeitraum, berichtet, was abgeschlossen wurde, und bespricht die Lücke mit den Projektleitungen. Der Zyklus lautet Planen, Umsetzen, Prüfen. Jede Aufgabe hat einen benannten Verantwortlichen und ein Datum. Aufgaben des Auftraggebers (Tests, Datenbereinigung, Entscheidungen) stehen im selben Plan wie die Aufgaben des Auftragnehmers.
8. Verfahren der Statusberichte
Bericht
Autor
Adressaten
Turnus
Inhalt
Kanal
Status je Arbeitspaket
Leitung des Arbeitspakets
Beide Projektleitungen
[im Projekt vereinbaren]
Erledigt, als Nächstes, blockiert, nötige Entscheidungen
[Kanal]
Projektstatusbericht
Beide Projektleitungen
Sponsoren, Lenkungsausschuss
[im Projekt vereinbaren]
Fortschritt gegen Plan, Meilensteine, Budget, wichtigste Risiken und Issues, nötige Entscheidungen, Gate-Bereitschaft (Format aus IDK-06)
[Kanal]
Abstimmung der Projektleitungen
Beide Projektleitungen
Intern
Wöchentlich
Plan, Ressourcen, Risiken, anstehende Aufgaben des Auftraggebers
Besprechung
Die Statusfarben sind einmal definiert: Grün bedeutet auf der Baseline, Gelb bedeutet außerhalb der Baseline mit einem Plan zur Gegensteuerung in Verantwortung der Projektleitungen, Rot bedeutet außerhalb der Baseline und braucht eine Entscheidung des Lenkungsausschusses.
9. Umgebungen
Umgebung
Place
Zweck
Daten
Regel zur Auffrischung
Zugriff verwaltet von
Beispiel: Entwicklung und Konfiguration
Build Place
Konfigurationen und entwickelte Objekte vor der Auslieferung aufbauen und per Unit-Test prüfen
Testdaten des Auftragnehmers
[im Projekt vereinbaren]
Technischer Lösungsverantwortlicher des Auftragnehmers
Beispiel: Konfiguration und Test
Use Place
Workshops, Prototyp, Testzyklen
Beispieldaten des Auftraggebers, danach migrierte Daten
Vor jedem Testzyklus aus [Quelle] aufgefrischt
IT-Leitung des Auftraggebers
Beispiel: Produktion
Use Place
Erhält verifizierte Konfiguration, sobald sie freigegeben ist; wird nach dem Laden der statischen Daten und der Definition der Sicherheit zur Baseline
Produktionsdaten
Nicht aufgefrischt
IT-Leitung des Auftraggebers
[Umgebung]
[Place]
[Zweck]
[Daten]
[Regel]
[Rolle]
Update-Taktung: Das Vorgehen bei Service Updates und Release Updates während des Projekts ist [im Projekt vereinbaren]. Freeze-Fenster vor dem Go-live: [im Projekt vereinbaren]. Anpassungsstrategie und Update-Taktung werden gemeinsam überprüft, denn der Umfang der Anpassungen begrenzt, in welchem Takt der Auftraggeber Updates einspielen kann.
10. Dokumentenliste
Vereinbaren Sie diese Liste jetzt und zeigen Sie ein Beispiel für jeden Dokumententyp. Später angeforderte Dokumente sind ein Änderungsantrag.
10.1 Dokumente, die der Auftragnehmer schreibt
Dokument
Vereinbarte Detailtiefe
Dem Auftraggeber gezeigtes Beispiel
Fällig
Beispiel: Funktionsspezifikation je Schnittstelle und Modifikation
Zweck, Auslöser, Datenzuordnung je Feld, Fehlerbehandlung, Testfälle
[ja/nein, Datum]
Vor der Entwicklung jedes Objekts
[Dokument]
[Detailtiefe]
[ja/nein]
[Datum oder Meilenstein]
10.2 Dokumente, die der Auftragnehmer nicht schreibt
Dokument
Geschrieben von
Beitrag des Auftragnehmers
Beispiel: Schritt-für-Schritt-Anleitungen in der Sprache der Anwender
Fachteams des Auftraggebers
Prüfung auf Richtigkeit in den Lösungsworkshops
Beispiel: Testskripte für Abnahme- und Bereitschaftstests
Polski (PL) 
English (United Kingdom) 
