Napisz ten dokument po okresie wsparcia go-live, gdy rozwiązanie działa zgodnie z ustaleniami, a przekazanie do wsparcia jest zakończone.
Piszą go razem obaj kierownicy projektu. Komitet sterujący go zatwierdza. Po tym projekt przestaje istnieć, więc wszystko, co pozostaje otwarte, potrzebuje wskazanego właściciela w organizacji liniowej.
Zbieraj wnioski od całego zespołu, nie tylko od kierowników projektu. Przeprowadź sesję z sekcji 7, zanim ludzie zostaną zwolnieni z projektu.
Wiersze oznaczone Przykład: pokazują oczekiwany poziom szczegółowości. Usuń je z roboczej kopii.
Bądź rzeczowy. Raport zamknięcia, który ukrywa to, co poszło nie tak, nie ma wartości dla kolejnego projektu.
Metadane szablonu
Field
Value
ID szablonu
IDK-24
Faza
Go Live
Właściciel
Kierownik projektu po stronie klienta
Zatwierdzający
Komitet sterujący
Bramka kwalifikacyjna
Go Live Complete
Wersja
1.0
Kontrola dokumentu
Pole
Wartość
Projekt
[nazwa projektu]
Klient
[podmiot prawny]
Data(-y) go-live
[data per lokalizacja lub moduł]
Proponowana data zamknięcia
[YYYY-MM-DD]
Właściciel dokumentu
[imię i nazwisko, kierownik projektu po stronie klienta]
Współautor
[imię i nazwisko, kierownik projektu po stronie dostawcy]
Status
[Szkic / Przekazany / Uzgodniony]
Wersja
[x.y]
Lokalizacja
[link]
Dokumenty powiązane
[Zakres projektu, plan zarządzania projektem, uzasadnienie biznesowe, przekazanie do wsparcia (szablon IDK-22), strategia aktualizacji (szablon IDK-23)]
Wersja
Data
Autor
Zmiana
[0.1]
[YYYY-MM-DD]
[imię i nazwisko]
[Pierwszy szkic]
1. Dowody dla bramki: Go Live Complete
#
Kryterium
Dowód
Status
1
Cutover zakończony
[Zamknięta checklista cutover]
[Spełnione / Niespełnione]
2
Rozwiązanie działa zgodnie z ustaleniami
[Log problemów z okresu go-live; potwierdzenia właścicieli procesów]
[Spełniony / Częściowo spełniony / Niespełniony / Za wcześnie, żeby ocenić]
[tekst]
Przykład: 2
Przykład: Zastąpienie systemu legacy zaopatrzenia standardowym zaopatrzeniem IFS Cloud we wszystkich lokalizacjach w zakresie
Przykład: Wszystkie zamówienia zakupu tworzone w IFS Cloud; legacy tylko do odczytu
Przykład: Na produkcji we wszystkich lokalizacjach w zakresie; legacy tylko do odczytu od cutover
Przykład: Spełniony
Przykład: Potwierdzenie zamówień przez dostawcę nadal obsługiwane e-mailem, zgodnie z projektem
2.2 Linie bazowe
Linia bazowa
Zatwierdzona linia bazowa
Zatwierdzone zmiany
Finalna
Wyjaśnienie odchylenia
Zakres rozwiązania
[ref]
[ID wniosków o zmianę]
[ref]
[tekst]
Zakres projektu
[ref]
[ID wniosków o zmianę]
[ref]
[tekst]
Harmonogram
[Data go-live w linii bazowej]
[ID wniosków o zmianę]
[Rzeczywista data]
[tekst]
Koszt
[ref do budżetu]
[ID wniosków o zmianę]
[ref do finalnych liczb]
[tekst]
2.3 Wynik dostosowań
Typ CRIM
Zidentyfikowane w Confirm Prototype
Dostarczone
Uniknięte dzięki standardowi
Komentarz
Konfiguracje
[n]
[n]
[n]
Raporty
[n]
[n]
[n]
Integracje
[n]
[n]
[n]
Modyfikacje
[n]
[n]
[n]
Celem było zaspokojenie potrzeb procesowych najpierw standardową funkcjonalnością. Napisz wprost, czy się to udało: [tekst].
3. Przekazanie śledzenia korzyści do sponsora
Projekt dostarcza zdolność. Biznes dostarcza korzyści. Sponsor jest właścicielem uzasadnienia biznesowego i pozostaje odpowiedzialny za realizację korzyści po zamknięciu projektu.
#
Korzyść z uzasadnienia biznesowego
Miara
Wartość bazowa
Cel i data
Status przy zamknięciu
Właściciel korzyści
Kolejny przegląd
[n]
[tekst]
[jak mierzone, źródło danych]
[wartość, data]
[wartość, data]
[tekst]
[imię i nazwisko, rola liniowa]
[data, forum]
Przykład: 1
Przykład: Mniej opóźnionych dostaw od dostawców wykrywanych dopiero przy rozładunku
Przykład: Udział linii zamówień zakupu odebranych po potwierdzonej dacie, z lobby dotyczącego odbiorów zamówień zakupu
[wartość, data]
[wartość, data]
Przykład: Pomiar prowadzony od go-live; za wcześnie na porównanie
Przykład: Kierownik zaopatrzenia
[data, spotkanie kierownictwa]
Pozycja przekazania
Wartość
Forum przeglądu korzyści po zamknięciu
[Które stałe spotkanie przejmuje rolę komitetu sterującego]
Częstotliwość
[uzgodnić w projekcie]
Akceptacja śledzenia korzyści przez sponsora
[imię i nazwisko, data]
4. Pozostałe problemy z właścicielami
Wszystko, co pozostaje otwarte na dzień zamknięcia. Każda pozycja potrzebuje właściciela spoza projektu.
ID
Opis
Typ
Wpływ
Obejście
Właściciel po zamknięciu
Termin docelowy
Śledzone gdzie
[ID]
[tekst]
[Defekt / Dane / Szkolenie / Proces / Odroczony zakres / Dane podstawowe do korekty]
[tekst]
[tekst]
[imię i nazwisko, rola liniowa]
[YYYY-MM-DD]
[Zgłoszenie wsparcia / Backlog IT / Projekt wdrożenia]
Przykład: R-006
Przykład: Raport zamówienia do dostawcy pokazuje niestandardowy kod projektu tylko na pierwszej stronie
Przykład: Defekt
Przykład: Niski; dotyczy zamówień wielostronicowych
Przykład: Kod dopisywany w notatce do zamówienia
Przykład: Właściciel systemu po stronie klienta, poprawka przez wsparcie dostawcy
[YYYY-MM-DD]
Przykład: Zgłoszenie [ref]
Zakres odroczony, uzgodniony jako niedostarczany w tym projekcie:
Pozycja
Powód odroczenia
Odniesienie do decyzji
Proponowane miejsce
[tekst]
[tekst]
[Wniosek o zmianę lub protokół komitetu sterującego]
[Kolejna faza / Wdrożenie / Porzucone]
5. Zamknięcie rejestru ryzyk i dziennika problemów
Rejestr
Otwarte przy zamknięciu
Działanie
Nowy właściciel
Potwierdzone
Rejestr ryzyk
[n]
[Każde otwarte ryzyko: zamknięte jako już nieistotne albo przekazane]
[Właściciel systemu po stronie klienta / rejestr ryzyk IT]
[ ]
Dziennik problemów
[n]
[Każdy otwarty problem: zamknięty albo przeniesiony do sekcji 4]
[Patrz sekcja 4]
[ ]
Log wniosków o zmianę
[n]
[Każdy otwarty wniosek: zatwierdzony i dostarczony, odrzucony albo przeniesiony do zakresu odroczonego]
[Właściciel systemu po stronie klienta]
[ ]
Log defektów
[n]
[Otwarte pozycje przeniesione do zgłoszeń wsparcia]
[Wsparcie]
[ ]
Listy działań z protokołów komitetu sterującego
[n]
[Zamknięte lub przekazane]
[imiona i nazwiska]
[ ]
Ryzyka przekazane do eksploatacji:
Ryzyko
Dlaczego pozostaje
Właściciel
Wdrożona mitygacja
[tekst]
[tekst]
[imię i nazwisko]
[tekst]
Przykład: Wiedza o rozwiązaniu skoncentrowana u kilku członków zespołu kluczowego
Przykład: Zespół kluczowy wraca do ról liniowych
Przykład: Właściciel systemu po stronie klienta
Przykład: Zespół kluczowy tworzy stały zespół systemów biznesowych; instrukcje i model procesów utrzymywane na bieżąco
Rejestry zarchiwizowane tylko do odczytu w dniu [YYYY-MM-DD] w [lokalizacja].
6. Inwentarz dokumentacji
Dokument
Wersja finalna
Właściciel po zamknięciu
Lokalizacja
Utrzymywany na bieżąco po zamknięciu
Zakres projektu i wnioski o zmianę
[x.y]
[imię i nazwisko]
[link]
Nie, archiwum
Plan zarządzania projektem
[x.y]
[imię i nazwisko]
[link]
Nie, archiwum
Dokumenty Księgi reguł
[x.y]
[Właściciele procesów]
[link]
Tak
Model procesów
[ref]
[Właściciel systemu po stronie klienta]
[Projekt w IFS Scope Tool lub eksport: link]
Tak
Log decyzji z uzasadnieniem
[x.y]
[Właściciel systemu po stronie klienta]
[link]
Tak
Log CRIM ze specyfikacjami funkcjonalnymi i testowymi
[x.y]
[Właściciel systemu po stronie klienta, wsparcie]
[link]
Tak
Rejestr interfejsów
[x.y]
[Lider integracji]
[link]
Tak
Macierz ról i dokumentacja zestawów uprawnień
[x.y]
[Lider bezpieczeństwa]
[link]
Tak
Plan migracji danych, mapowania, podpisy walidacji
[x.y]
[imię i nazwisko]
[link]
Nie, archiwum. Zachować do audytu: [okres retencji wg polityki firmy]
Strategia testów, skrypty i odbiory SAT i ORT
[x.y]
[Właściciel systemu po stronie klienta]
[link]
Tak, skrypty stają się pakietem regresyjnym
Plan szkoleń, materiały kursowe, instrukcje krok po kroku
[x.y]
[Lider szkoleń]
[link]
Tak
Plan cutover, checklista, dzienniki prób generalnych
[x.y]
[imię i nazwisko]
[link]
Nie, archiwum. Wykorzystać ponownie przy wdrożeniach
Decyzja o gotowości do startu
[x.y]
[imię i nazwisko]
[link]
Nie, archiwum
Przekazanie do wsparcia
[x.y]
[Kierownik wsparcia]
[link]
Tak
Strategia aktualizacji
[x.y]
[Właściciel systemu po stronie klienta]
[link]
Tak
Materiały i protokoły komitetu sterującego
[imię i nazwisko]
[link]
Nie, archiwum
Dostęp do archiwum po zamknięciu: [kto, jak]. Kopie dokumentów klienta u dostawcy: [zachowane / zwrócone / usunięte, zgodnie z umową].
Szablon IDK-23, wersja 1.0. Faza: Initiate Project (pierwsza decyzja), utrzymywana po Go Live.
Jak korzystać z tego szablonu
Zacznij ten dokument na początku projektu, nie po go-live. Kadencja wybrana tutaj kształtuje decyzje projektowe od pierwszego warsztatu.
Aktualizacje serwisowe i aktualizacje wydania to jedyna droga, którą poprawki rdzenia i nowe funkcje trafiają do Twojego systemu. Planuj je jako powtarzalną rutynę z kalendarzem, nie jako osobne projekty.
Sekcje 1-3 i 7 to decyzje. Sekcje 4-6 to metoda pracy. Sekcja 5 jest kopiowana raz na każdą aktualizację.
Wiersze oznaczone Przykład: pokazują oczekiwany poziom szczegółowości. Usuń je z roboczej kopii.
Wszystkie wartości kadencji ustalacie sami, w granicach dozwolonych przez waszą opcję wdrożenia i umowę. Sprawdźcie te warunki przed wypełnieniem sekcji 1.
Metadane szablonu
Field
Value
ID szablonu
IDK-23
Faza
Initiate Project (pierwsza decyzja), utrzymywana po Go Live
Właściciel
Właściciel systemu po stronie klienta
Zatwierdzający
Komitet sterujący w trakcie projektu, governance IT klienta po zamknięciu
Bramka kwalifikacyjna
Project Initiated (kadencja ustalona), Go Live Complete (model operacyjny potwierdzony)
Wersja
1.0
Kontrola dokumentu
Pole
Wartość
Klient
[podmiot prawny]
Rozwiązanie
[IFS Cloud, firmy i lokalizacje w zakresie]
Właściciel dokumentu
[imię i nazwisko, właściciel systemu po stronie klienta]
Status
[Szkic / Zatwierdzony / W eksploatacji]
Wersja
[x.y]
Lokalizacja
[link]
Dokumenty powiązane
[Log CRIM, rejestr interfejsów, przekazanie do wsparcia (szablon IDK-22), skrypty SAT (szablon IDK-18), umowa wsparcia]
Wersja
Data
Autor
Zmiana
[0.1]
[YYYY-MM-DD]
[imię i nazwisko]
[Pierwszy szkic]
1. Decyzja o kadencji aktualizacji
Pytanie
Decyzja
Powód
Zdecydował, data
Opcja wdrożenia i co oznacza dla aktualizacji
[Cloud service / Remote deployment; warunki umowne: link]
Jak często przyjmujemy aktualizacje serwisowe?
[uzgodnić w projekcie]
[tekst]
[imię i nazwisko, data]
Jak szybko po wydaniu przyjmujemy aktualizację serwisową?
[uzgodnić w projekcie]
[tekst]
[imię i nazwisko, data]
Które aktualizacje wydania przyjmujemy?
[uzgodnić w projekcie]
[tekst]
[imię i nazwisko, data]
O ile najwyżej możemy być w tyle za bieżącym wydaniem?
[uzgodnić w projekcie, w granicach polityki wsparcia dostawcy]
[tekst]
[imię i nazwisko, data]
Okresy zamrożenia bez aktualizacji
[Go-live, zamknięcie okresu i roku, szczyty biznesowe: daty]
[tekst]
[imię i nazwisko, data]
Kto może zatwierdzić wyjątek od tej kadencji?
[rola]
Dlaczego utrzymywanie aktualności ma znaczenie dla [Klient], własnymi słowami: [Pozostawanie w tyle zwiększa ekspozycję na zagrożenia bezpieczeństwa, podnosi koszt operacyjny, bo każdy kolejny skok jest większy, i zawęża dostępne wsparcie. Napisz, co to oznacza dla tego biznesu.]
Przegląd tej decyzji: [kiedy i przez kogo; co najmniej po pierwszej aktualizacji wydania przyjętej w eksploatacji].
2. Role
Rola
Imię i nazwisko
Odpowiedzialność w trakcie aktualizacji
Właściciel systemu
[imię i nazwisko]
Odpowiada za tę strategię i kalendarz. Zatwierdza każdą aktualizację na produkcję.
Koordynator aktualizacji
[imię i nazwisko]
Prowadzi ocenę wpływu, rezerwuje środowiska i testerów, śledzi checklistę.
Właściciele procesów
[imiona i nazwiska per obszar]
Przeglądają release notes dla swojego obszaru. Decydują, które nowe funkcje wdrożyć. Podpisują wyniki regresji.
Użytkownicy eksperci
[imiona i nazwiska]
Uruchamiają skrypty regresyjne. Informują kolegów, co się zmienia.
Lider techniczny
[imię i nazwisko]
Środowiska, droga dostawy, prace w Build Place, sprawdzenie projekcji i integracji.
Właściciele integracji
[imiona i nazwiska per interfejs]
Potwierdzają każdy interfejs po aktualizacji, w razie potrzeby ze stroną zewnętrzną.
Lider bezpieczeństwa
[imię i nazwisko]
Przegląda nowe i zmienione projekcje oraz wpływ na zestawy uprawnień.
Partner wdrożeniowy / wsparcie
[imię i nazwisko, umowa]
[Uplift modyfikacji, doradztwo, uzgodniony udział w testowaniu]
Dostawcy zewnętrzni
[lista]
Potwierdzają zgodność swojego rozszerzenia lub usługi z docelowym poziomem.
3. Kalendarz
Aktualizacja
Typ
Dostępna od
Ocena wpływu
W środowisku testowym
Okno testów regresyjnych
Produkcja
Sprawdzone konflikty z zamrożeniem
[identyfikator]
[Aktualizacja serwisowa / Aktualizacja wydania]
[YYYY-MM-DD]
[YYYY-MM-DD]
[YYYY-MM-DD]
[od, do]
[YYYY-MM-DD]
[Tak / Nie]
Przykład: [identyfikator wydania]
Przykład: Aktualizacja wydania
[YYYY-MM-DD]
[YYYY-MM-DD]
[YYYY-MM-DD]
[od, do]
[YYYY-MM-DD]
Przykład: Tak, omija zamknięcie roku i jesienny szczyt
[Odświeżone z produkcji przed zastosowaniem aktualizacji: Tak / Nie]
Test regresyjny i integracyjny
[nazwa]
Use Place
[Dane zbliżone do produkcyjnych; integracje skierowane na punkty testowe]
Szkolenie ze zmian, jeśli potrzebne
[nazwa]
Use Place
[tekst]
Produkcja
[nazwa]
Use Place
[Zastosowane w uzgodnionym oknie; kopia zapasowa potwierdzona wcześniej]
Droga dostawy i zatwierdzenia między środowiskami: [tekst lub link do szablonu IDK-22, sekcja 5].
5. Ocena wpływu per aktualizacja
Skopiuj tę sekcję dla każdej aktualizacji. Przechowuj wypełnioną kopię razem z logiem decyzji.
5.1 Nagłówek aktualizacji
Pole
Wartość
Aktualizacja
[identyfikator, typ]
Aktualny poziom na produkcji
[poziom]
Poziom docelowy
[poziom]
Koordynator
[imię i nazwisko]
Data oceny
[YYYY-MM-DD]
5.2 Przegląd release notes
Obszar
Recenzent
Zmiana istotna dla nas
Efekt
Działanie
Wdrożenie nowej funkcji
[obszar]
[właściciel procesu]
[tekst]
[Brak / Zmiana procedury / Zmiana instrukcji / Wymagana konfiguracja / Wymagane szkolenie]
[tekst, właściciel]
[Tak / Nie / Później]
Przykład: Zaopatrzenie
[imię i nazwisko]
Przykład: Zmieniony layout strony używanej codziennie przez zaopatrzeniowców
Przykład: Zmiana instrukcji
Przykład: Aktualizacja instrukcji "Zamiana na zamówienie"; poinformowanie zaopatrzeniowców przez użytkowników ekspertów
Przykład: Nie dotyczy
Sprawdź też: informacje o wycofywanych i przestarzałych elementach, uwagi dotyczące bezpieczeństwa, zmiany wymagań technicznych. Recenzent: [lider techniczny].
5.3 Lista ponownej weryfikacji CRIM
Źródło: log CRIM (szablon IDK-10), notatka o wpływie aktualizacji per wiersz oraz lista CRIM w przekazaniu do wsparcia (szablon IDK-22, sekcja 6).
ID CRIM
Typ
Dotyczy zmienionego obszaru
Działanie
Specyfikacja testowa do uruchomienia
Właściciel
Wynik
[ID]
[C / R / I / M]
[Tak / Nie / Nieznane]
[Brak / Retest / Korekta / Uplift w Build Place / Wycofanie, standard już to pokrywa]
[link, wersja]
[imię i nazwisko]
[Zaliczone / Niezaliczone / Otwarte]
Przykład: CRIM-017
Przykład: Konfiguracja
Przykład: Tak, linia zamówienia zakupu
Przykład: Retest: pole niestandardowe widoczne na stronie i na raporcie zamówienia do dostawcy
[link, x.y]
[imię i nazwisko]
Przy każdej aktualizacji wydania zadaj pytanie o każdy obiekt: czy standard może go teraz zastąpić? Każdy wycofany obiekt sprawia, że kolejna aktualizacja jest lżejsza.
5.4 Sprawdzenie projekcji i integracji
Interfejs / konsument
Wykorzystywane projekcje lub API
Zmienione lub wycofane w tej aktualizacji
Wykonany test
Wymagane potwierdzenie strony zewnętrznej
Właściciel
Wynik
[nazwa]
[lista]
[Tak / Nie: szczegóły]
[tekst]
[Tak / Nie]
[imię i nazwisko]
Przykład: Zewnętrzna usługa monitorująca tylko do odczytu
Przykład: Projekcje zamówień zakupu i dostawców, czytane przez OData
[Tak / Nie]
Przykład: Konto serwisowe nadal może czytać projekcje; wykorzystywane pola nadal zwracane; testowe uruchomienie daje oczekiwany wynik
Przykład: Dostawca potwierdza zgodność z poziomem docelowym
[imię i nazwisko]
Sprawdź też: konta serwisowe i zestawy uprawnień nadal ważne; certyfikaty i poświadczenia nie wygasają w tym oknie; routing, zaplanowane zadania i workflow działają po aktualizacji.
5.5 Skrypty regresyjne do uruchomienia
Wykorzystaj ponownie skrypty SAT (szablon IDK-18). Utrzymuj je aktualne; to one są pakietem regresyjnym klienta.
ID scenariusza
Proces
Dlaczego wybrany
Tester
Środowisko
Wynik
ID defektu
[ID]
[proces]
[Główny przepływ / Dotknięty przez release notes / Dotyczy obiektu CRIM / Integracja]
[imię i nazwisko]
[nazwa]
[Zaliczone / Niezaliczone]
Przykład: P2P-01
Przykład: Procure to pay, przypadek standardowy
Przykład: Główny przepływ, uruchamiany zawsze
[użytkownik ekspert]
[nazwa]
Minimalny zakres regresji dla aktualizacji serwisowej: [uzgodnić w projekcie]. Dla aktualizacji wydania: [uzgodnić w projekcie].
5.6 Decyzja o wdrożeniu na produkcję
Pole
Wartość
Otwarte defekty
[lista z klasyfikacją jak w szablonie IDK-17, sekcja 9]
Decyzja
[Zastosować w planowanym terminie / Zastosować z warunkami / Przesunąć do: data]
Kopia zapasowa potwierdzona przed aktualizacją
[Tak / Nie]
Droga powrotna, jeśli aktualizacja się nie powiedzie
[tekst]
Zdecydował
[właściciel systemu, data]
6. Polityka dostosowań i jej wpływ na kadencję
Zasada: najpierw zaspokój potrzebę procesową standardową funkcjonalnością. Trzymaj liczbę konfiguracji, raportów, integracji i modyfikacji na jak najniższym poziomie. Ilość dostosowań i to, jak głęboko sięgają w rdzeń, wyznaczają sufit tego, jak często [Klient] może aktualizować system.
Typ dostosowania
Polityka
Wymagane zatwierdzenie
Koszt ponoszony przy każdej aktualizacji
Standardowa funkcjonalność ze zmienioną procedurą biznesową
Preferowane
Właściciel procesu
Brak
Konfiguracja w kliencie webowym (pola niestandardowe, strony, lobby, events, workflow)
Dozwolone ze specyfikacją
[Kierownik projektu klienta / właściciel systemu]
Retest
Raporty
Dozwolone ze specyfikacją; preferuj standardowe raporty i lobby
[Kierownik projektu klienta / właściciel systemu]
Retest, sprawdzenie layoutu
Integracje
Dozwolone z zatwierdzoną specyfikacją funkcjonalną; wykorzystuj projekcje i standardowe API
[Komitet sterujący / governance IT]
Test interfejsu, często ze stroną zewnętrzną
Modyfikacje
Tylko wyjątkowo, z pisemnym uzasadnieniem biznesowym
[Komitet sterujący / governance IT]
Uplift w Build Place, przebudowa, dostawa, pełny retest
Zasady:
Każdy nowy wniosek CRIM podaje swój powtarzalny koszt aktualizacji przed zatwierdzeniem: [kto szacuje].
Żadnych dostosowań bez specyfikacji funkcjonalnej i specyfikacji testowej. Bez obu obiekt nie może zostać ponownie zweryfikowany.
Log CRIM jest jedyną listą. Obiekt, którego nie ma w logu, nie jest objęty wsparciem.
Wnioski o modyfikację systemu, żeby uniknąć zmiany praktyki pracy, trafiają do [zatwierdzający] i z założenia są odrzucane.
[Zasada specyficzna dla projektu]
Aktualny poziom dostosowań: [liczby per typ CRIM z logu, YYYY-MM-DD]. Cel trendu: [uzgodnić w projekcie].
7. Komunikacja i szkolenia w związku ze zmianami
Odbiorca
Co otrzymuje
Od kogo
Kiedy
Kanał
Wszyscy użytkownicy
[Data aktualizacji, przestój, widoczne zmiany prostym językiem]
[Właściciel systemu]
[uzgodnić w projekcie]
[kanał]
Użytkownicy zmienionych procesów
[Zaktualizowana instrukcja krok po kroku, krótki briefing lub nagranie]
[Użytkownicy eksperci]
[Przed datą na produkcji]
[kanał]
Użytkownicy eksperci
[Przegląd istotnych zmian w środowisku testowym]
[Właściciele procesów]
[W trakcie okna regresji]
[sesja]
Service desk
[Znane zmiany, znane problemy, do kogo eskalować]
[Koordynator aktualizacji]
[Przed datą na produkcji]
[kanał]
Strony zewnętrzne
[Daty testów interfejsów, oczekiwane zmiany]
[Właściciele integracji]
[uzgodnić w projekcie]
[kanał]
Kierownictwo
[Kalendarz, wynik, wyjątki od kadencji]
[Właściciel systemu]
[uzgodnić w projekcie]
[raport]
Instrukcje i materiały szkoleniowe są aktualizowane w tym samym cyklu co system. Właściciel biblioteki instrukcji: [imię i nazwisko].
8. Log decyzji
#
Data
Decyzja
Powód
Zdecydował
Data przeglądu
[n]
[YYYY-MM-DD]
[tekst]
[tekst]
[imię i nazwisko, rola]
[YYYY-MM-DD]
Przykład: 1
[YYYY-MM-DD]
Przykład: Przesunięcie aktualizacji serwisowej [identyfikator] na po zamknięciu okresu
Przykład: Okno regresji koliduje z czynnościami zamknięciowymi w finansach
Przykład: Właściciel systemu
[YYYY-MM-DD]
Zatwierdzenie
Rola
Imię i nazwisko
Decyzja
Data
Podpis
Właściciel systemu po stronie klienta (właściciel)
[imię i nazwisko]
[Przekazano]
[YYYY-MM-DD]
Lider IT po stronie klienta
[imię i nazwisko]
[Zatwierdzono / Odrzucono]
[YYYY-MM-DD]
Kierownik projektu po stronie klienta
[imię i nazwisko]
[Zatwierdzono / Odrzucono]
[YYYY-MM-DD]
Kierownik projektu po stronie dostawcy lub architekt rozwiązania
[imię i nazwisko]
[Zweryfikowano]
[YYYY-MM-DD]
Przewodniczący komitetu sterującego / przewodniczący governance IT
[imię i nazwisko]
[Zatwierdzono / Odrzucono]
[YYYY-MM-DD]
Niezależny szablon zgodny z metodyką wdrożeniową IFS. Nie jest oficjalnym dokumentem IFS. IFS jest zastrzeżonym znakiem towarowym IFS AB.
Przekazanie inicjuje kierownik projektu, a płaci za nie budżet projektu. Planuj je jako zadanie projektowe z datą, nie jako coś, co dzieje się, gdy ludzie mają czas.
Warunki wstępne: klient jest na produkcji (możliwe jest przekazanie częściowe per lokalizacja lub moduł), rozwiązanie jest odebrane, a dokumentacja jest w języku angielskim.
Pisz z myślą o konsultancie wsparcia, który nigdy nie spotkał tego klienta. Jeśli ta osoba nie potrafi znaleźć specyfikacji ani odtworzyć testu na podstawie tego dokumentu, przekazanie nie jest zakończone.
Wiersze oznaczone Przykład: pokazują oczekiwany poziom szczegółowości. Usuń je z roboczej kopii.
Zamknij nagranym spotkaniem przekazania między zespołem projektowym a wsparciem (sekcja 12). Bez tego spotkania przekazanie się nie odbyło.
Metadane szablonu
Field
Value
ID szablonu
IDK-22
Faza
Go Live
Właściciel
Kierownik projektu po stronie dostawcy
Zatwierdzający
Kierownik wsparcia i kierownik projektu po stronie klienta
Bramka kwalifikacyjna
Go Live Complete
Wersja
1.0
Kontrola dokumentu
Pole
Wartość
Projekt
[nazwa projektu]
Klient
[podmiot prawny]
Zakres przekazania
[Pełny / Częściowy: lokalizacje, moduły]
Właściciel dokumentu
[imię i nazwisko, kierownik projektu po stronie dostawcy]
Organizacja wsparcia przejmująca
[nazwa, zespół]
Status
[Szkic / Przejrzany przez wsparcie / Zaakceptowany]
Wydanie IFS Cloud i poziom aktualizacji serwisowej przy przekazaniu
[wydanie, aktualizacja]
Data(-y) go-live
[data per lokalizacja lub moduł]
Baza użytkowników
[Nazwani użytkownicy wg typu: link do zapisu licencji]
Okresy krytyczne dla biznesu
[Zamknięcie okresu, szczyty sezonowe, systemy zmianowe]
Odniesienie do umowy wsparcia
[Kontrakt, godziny obsługi, zobowiązania czasu reakcji: link]
Planowane dalsze wdrożenia
[Lokalizacje, moduły, daty]
2. Kontakty projektowe
Rola
Imię i nazwisko
Organizacja
Kontakt
Dostępny po przekazaniu do
Sponsor po stronie klienta
[imię i nazwisko]
[Klient]
[e-mail, telefon]
[YYYY-MM-DD]
Kierownik projektu po stronie klienta
[imię i nazwisko]
[Klient]
[e-mail, telefon]
[YYYY-MM-DD]
Właściciel systemu po stronie klienta po go-live
[imię i nazwisko]
[Klient]
[e-mail, telefon]
Stale
Lider IT po stronie klienta
[imię i nazwisko]
[Klient]
[e-mail, telefon]
Stale
Użytkownicy eksperci per obszar
[link do listy]
[Klient]
Stale
Kierownik projektu po stronie dostawcy
[imię i nazwisko]
[Dostawca]
[e-mail, telefon]
[YYYY-MM-DD]
Architekt rozwiązania
[imię i nazwisko]
[Dostawca]
[e-mail, telefon]
[YYYY-MM-DD]
Kierownik rozwiązania technicznego
[imię i nazwisko]
[Dostawca]
[e-mail, telefon]
[YYYY-MM-DD]
Konsultanci aplikacyjni per obszar
[imiona i nazwiska]
[Dostawca]
[e-mail]
[YYYY-MM-DD]
Opiekun handlowy
[imię i nazwisko]
[Dostawca]
[e-mail, telefon]
Stale
Kto po stronie klienta może zgłaszać sprawy wsparcia: [imiona lub zasada]. Kto może zatwierdzać prace odpłatne: [imiona].
3. Checklista przekazania
#
Pozycja
Zrobione
Dowód / link
Komentarz
1
Klient jest na produkcji w zakresie przekazania
[ ]
[Potwierdzenie go-live]
2
Rozwiązanie odebrane przez klienta
[ ]
[Odbiór SAT i ORT]
3
Dokumentacja jest w języku angielskim
[ ]
4
Model procesów jest aktualny i dostępny dla wsparcia
[ ]
[link]
5
Log CRIM kompletny, z najnowszymi specyfikacjami funkcjonalnymi i testowymi
[ ]
[Sekcja 6]
6
Integracje ze stronami trzecimi wymienione z właścicielami i kontami
[ ]
[Sekcja 7]
7
Rozszerzenia i lokalizacje wymienione
[ ]
[Sekcja 8]
8
Środowiska udokumentowane; wsparcie ma potrzebny dostęp
[ ]
[Sekcja 5]
9
Harmonogram dostaw i gotowość przejrzane
[ ]
[Sekcja 9]
10
Dane podstawowe do korekty po go-live wymienione z właścicielami
[ ]
[Sekcja 10]
11
Znane problemy i obejścia wymienione; otwarte zgłoszenia przekazane
[ ]
[Sekcja 11]
12
Konta projektowe i podwyższony dostęp usunięte lub mają datę końcową
[ ]
[Lista kont]
13
Spotkanie przekazania odbyte i nagrane
[ ]
[Sekcja 12]
4. Przegląd rozwiązania
Pozycja
Wartość
Model procesów
[Link do projektu w IFS Scope Tool lub wyeksportowany model]
Procesy end-to-end w użyciu
[lista]
Podsumowanie modelu operacyjnego
[Link do zatwierdzonych dokumentów Księgi reguł]
Kluczowe decyzje projektowe
[Link do logu decyzji. Uwzględnij uzasadnienie, nie tylko wynik.]
Instrukcje krok po kroku
[Link do biblioteki]
Role i zestawy uprawnień
[Link do macierzy ról]
Lobby w codziennym użyciu
[lista z właścicielem]
Workflow i event actions w użyciu
[lista z celem i właścicielem]
Podsumowanie w prostym języku, jak ten klient korzysta z IFS Cloud i co jest w tym nietypowego: [krótki tekst. To jest akapit, który nowy konsultant wsparcia czyta jako pierwszy.]
5. Środowiska
Środowisko
Miejsce
Cel
Poziom wydania i aktualizacji
Odświeżane z / kiedy
Dostęp dla wsparcia
Właściciel
[nazwa]
[Build Place / Use Place]
[cel]
[poziom]
[źródło, data]
[Tak / Nie, jak]
[imię i nazwisko]
Przykład: PROD
Przykład: Use Place
Przykład: Produkcja
[poziom]
Nie dotyczy
Przykład: Na żądanie przez lidera IT po stronie klienta, ograniczony czasowo
Przykład: Lider IT po stronie klienta
Przykład: [nazwa]
Przykład: Build Place
Przykład: Rozwój i dostarczanie modyfikacji
[poziom]
[YYYY-MM-DD]
Przykład: Zespół techniczny dostawcy
Przykład: Kierownik rozwiązania technicznego
Droga dostawy z Build Place na produkcję w Use Place: [kroki, osoba zatwierdzająca, kto stosuje dostawy]. Repozytorium kodu i zasady branchowania: [link, tekst]. Konfiguracja dostawcy tożsamości i single sign-on: [podsumowanie, właściciel].
6. Przekazane obiekty CRIM
Każda konfiguracja, raport, integracja i modyfikacja dostarczone przez projekt. Poprawki nie da się zweryfikować bez specyfikacji testowej, więc brakujący link w tej tabeli jest otwartą pozycją przekazania.
ID CRIM
Typ
Nazwa i cel
Proces
Specyfikacja funkcjonalna (link, wersja)
Specyfikacja testowa (link, wersja)
Wersja na produkcji
Zbudowane przez
Do ponownej weryfikacji przy każdej aktualizacji
[ID]
[C / R / I / M]
[tekst]
[proces]
[link, x.y]
[link, x.y]
[x.y]
[imię i nazwisko]
[Tak / Nie]
Przykład: CRIM-017
Przykład: Konfiguracja
Przykład: Pole niestandardowe "Wewnętrzny kod projektu" na linii zamówienia zakupu, pokazywane na raporcie zamówienia do dostawcy
Przykład: Procure to pay
[link, x.y]
[link, x.y]
[x.y]
[imię i nazwisko]
Tak
Przykład: CRIM-003
Przykład: Integracja
Przykład: Wychodzący plik płatności do banku w uzgodnionym formacie
Przykład: Procure to pay, płatności dla dostawców
[link, x.y]
[link, x.y]
[x.y]
[imię i nazwisko]
Tak
Potwierdzenie: specyfikacje powyżej są najnowszymi wersjami i są zgodne z tym, co działa na produkcji. Potwierdzone przez [kierownik rozwiązania technicznego] w dniu [YYYY-MM-DD].
7. Integracje ze stronami trzecimi
Uwzględnij wszystko, co czyta z IFS Cloud lub zapisuje do IFS Cloud, także usługi, których projekt nie budował.
#
System / usługa
Cel
Kierunek
Wykorzystane projekcje / interfejs
Konto i zestaw uprawnień
Uwierzytelnianie
Właściciel po stronie klienta
Kontakt u dostawcy
Do sprawdzenia po każdej aktualizacji
Jak usunąć
[n]
[nazwa]
[cel]
[Przychodzący / Wychodzący / Tylko do odczytu]
[lista]
[konto, zestaw uprawnień]
[metoda]
[imię i nazwisko]
[kontakt]
[co zweryfikować]
[kroki]
Przykład: 1
Przykład: Zewnętrzna usługa monitorująca wyjątki zakupowe, dostarczona przez stronę trzecią, działająca w sieci klienta
Przykład: Powiadamia zaopatrzeniowców o zamówieniach niepotwierdzonych przez dostawcę i o opóźnionych dostawach
Przykład: Tylko do odczytu. Czyta przez OData. Nic nie zapisuje do IFS Cloud i niczego w nim nie instaluje.
Przykład: Projekcje zamówień zakupu i dostawców: [nazwy projekcji]
Przykład: Dedykowane konto serwisowe [nazwa konta] z jednym zestawem uprawnień tylko do odczytu [nazwa zestawu uprawnień]. Żadne zestawy uprawnień użytkownika końcowego nie są przyznane.
Przykład: [klient IAM / metoda wg konfiguracji]
Przykład: Kierownik zaopatrzenia (biznes), lider IT po stronie klienta (konto)
[kontakt]
Przykład: Projekcje nadal istnieją i zwracają wykorzystywane pola; konto serwisowe nadal aktywne
Przykład: Odebranie zestawu uprawnień, dezaktywacja konta, zatrzymanie usługi. Nic do odinstalowania w IFS Cloud.
Przykład: Format pliku niezmieniony; plik testowy zaakceptowany
[kroki]
Interfejsy legacy zatrzymane przy go-live: [link do zamkniętej części rejestru interfejsów].
8. Rozszerzenia i lokalizacje
Pozycja
Typ
Dostawca / źródło
Wersja
Cel
Odniesienie do licencji lub umowy
Zależność od aktualizacji
[nazwa]
[Rozszerzenie / Lokalizacja / Produkt partnerski]
[nazwa]
[x.y]
[tekst]
[ref]
[Musi być aktualizowane przy każdej aktualizacji wydania: Tak / Nie]
Przykład: Lokalizacja krajowa dla [kraj]
Przykład: Lokalizacja
[źródło]
[x.y]
Przykład: Raportowanie statutowe i obsługa podatkowa dla podmiotu prawnego w [kraj]
[ref]
[Tak / Nie]
9. Harmonogram dostaw i gotowość
Dostawa
Zawartość
Planowane
Status
Gotowość dla wsparcia
Właściciel
[Zakres go-live per lokalizacja lub moduł, dalsze wdrożenia, otwarte dostawy CRIM]
[tekst]
[YYYY-MM-DD]
[Na produkcji / Planowane / W budowie]
[Przekazane / Pozostaje przy projekcie do: data]
[imię i nazwisko]
Przykład: Lokalizacja [lokalizacja], dystrybucja i zaopatrzenie
Przykład: Wszystkie procesy w zakresie
[YYYY-MM-DD]
Na produkcji
Przekazane
Kierownik projektu dostawcy
Praca, która pozostaje przy zespole projektowym po tym przekazaniu: [lista z datami zakończenia]. Zasada kierowania zgłoszeń w okresie nakładania się: [tekst].
10. Dane podstawowe do korekty po go-live
Ustawienia celowo ustawione na potrzeby cutover lub pierwszego okresu użytkowania, które ktoś musi później zmienić. Jeśli nikt ich nie posiada, pozostaną błędne.
#
Dane podstawowe / ustawienie
Aktualna wartość i powód
Docelowa wartość
Kiedy
Właściciel
Zrobione
[n]
[ustawienie]
[tekst]
[tekst]
[data lub wyzwalacz]
[imię i nazwisko]
[ ]
Przykład: 1
Przykład: Limity autoryzacyjne dla zamówień zakupu
Przykład: Ustawione wysoko na pierwszy okres, żeby zatwierdzenia nie wstrzymywały zakupów, dopóki osoby zatwierdzające uczą się procesu
Przykład: Limity z zatwierdzonej polityki zaopatrzenia
[YYYY-MM-DD]
Przykład: Kierownik zaopatrzenia
[ ]
Przykład: 2
Przykład: Użytkownicy z tymczasowymi dodatkowymi zestawami uprawnień przyznanymi na wsparcie go-live
Przykład: Użytkownicy eksperci mają szerszy dostęp w okresie wsparcia
Przykład: Tylko zestawy uprawnień oparte na roli
[YYYY-MM-DD]
Przykład: Lider bezpieczeństwa
[ ]
11. Znane problemy i obejścia
ID
Opis
Obszar
Stosowane obejście
Odniesienie do zgłoszenia
Właściciel
Planowana poprawka
[ID]
[tekst]
[obszar]
[tekst]
[ref]
[imię i nazwisko]
[Dostawa, aktualizacja serwisowa lub data]
Przykład: R-006
Przykład: Raport zamówienia do dostawcy pokazuje niestandardowy kod projektu tylko na pierwszej stronie
Przykład: Zaopatrzenie
Przykład: Zaopatrzeniowcy dopisują kod w notatce do zamówienia przy zamówieniach wielostronicowych
[ref]
[imię i nazwisko]
[dostawa]
Otwarte zgłoszenia u dostawcy oprogramowania przy przekazaniu: [lista lub link]. Pozostałe problemy z dokumentu zamknięcia: [link do szablonu IDK-24, sekcja 4].
12. Zapis spotkania przekazania
Pole
Wartość
Data
[YYYY-MM-DD]
Uczestnicy, zespół projektowy
[imiona i nazwiska]
Uczestnicy, wsparcie
[imiona i nazwiska]
Uczestnicy, klient
[imiona i nazwiska]
Nagranie
[link]
Agenda
[Przegląd klienta i rozwiązania; przegląd obiektów CRIM; integracje; środowiska i droga dostawy; znane problemy; dane podstawowe do korekty; pytania od wsparcia]
#
Pytanie lub działanie ze spotkania
Właściciel
Termin
Zamknięte
[n]
[tekst]
[imię i nazwisko]
[YYYY-MM-DD]
[ ]
Data rozpoczęcia wsparcia: [YYYY-MM-DD]. Od tej daty zgłoszenia trafiają do: [kanał].
Zatwierdzenie
Rola
Imię i nazwisko
Decyzja
Data
Podpis
Kierownik projektu po stronie dostawcy (właściciel)
[imię i nazwisko]
[Przekazano]
[YYYY-MM-DD]
Kierownik rozwiązania technicznego
[imię i nazwisko]
[Potwierdza sekcje 5-8]
[YYYY-MM-DD]
Kierownik wsparcia
[imię i nazwisko]
[Zaakceptowano / Zaakceptowano z otwartymi pozycjami / Odrzucono]
[YYYY-MM-DD]
Kierownik projektu po stronie klienta
[imię i nazwisko]
[Zaakceptowano / Odrzucono]
[YYYY-MM-DD]
Właściciel systemu po stronie klienta
[imię i nazwisko]
[Zaakceptowano / Odrzucono]
[YYYY-MM-DD]
Niezależny szablon zgodny z metodyką wdrożeniową IFS. Nie jest oficjalnym dokumentem IFS. IFS jest zastrzeżonym znakiem towarowym IFS AB.
Szablon IDK-21, wersja 1.0. Faza: Implement Solution.
Jak korzystać z tego szablonu
To dokument, który komitet sterujący czyta przed autoryzacją go-live. Wyślij go z wyprzedzeniem, nie w dniu spotkania.
Każde kryterium wymaga dowodu, który można otworzyć i przeczytać: podpisany raport, log, lista. "Wydaje nam się, że tak" nie jest dowodem.
Właściciele obszarów wypełniają własny status. Kierownicy projektu go kwestionują. Komitet sterujący decyduje.
Wiersze oznaczone Przykład: pokazują oczekiwany poziom szczegółowości. Usuń je z roboczej kopii.
Możliwe są trzy wyniki: go, go z warunkami, no-go. No-go podjęte na podstawie dowodów jest decyzją słuszną. Zapisz je z taką samą starannością jak go.
Metadane szablonu
Field
Value
ID szablonu
IDK-21
Faza
Implement Solution
Właściciel
Kierownik projektu po stronie klienta
Zatwierdzający
Komitet sterujący
Bramka kwalifikacyjna
Go Live Authorised
Wersja
1.0
Kontrola dokumentu
Pole
Wartość
Projekt
[nazwa projektu]
Klient
[podmiot prawny]
Zakres go-live
[Firmy, lokalizacje, procesy]
Proponowana data go-live
[YYYY-MM-DD]
Data spotkania decyzyjnego
[YYYY-MM-DD]
Właściciel dokumentu
[imię i nazwisko, kierownik projektu po stronie klienta]
Status
[Szkic / Przekazany / Zdecydowany]
Wersja
[x.y]
Lokalizacja
[link]
Dokumenty powiązane
[Odbiór SAT i ORT (szablon IDK-18), rejestr szkoleń (szablon IDK-19), plan cutover (szablon IDK-20), przekazanie do wsparcia (szablon IDK-22)]
Wersja
Data
Autor
Zmiana
[0.1]
[YYYY-MM-DD]
[imię i nazwisko]
[Pierwszy szkic]
1. Podsumowanie dla komitetu sterującego
Pozycja
Wartość
Rekomendacja kierowników projektu
[Go / Go z warunkami / No-go]
Obszary gotowe
[lista]
Obszary gotowe z warunkami
[lista]
Obszary niegotowe
[lista]
Główne pozostałe ryzyko
[Jedno zdanie]
Decyzja potrzebna do
[data, powód]
Legenda statusów użyta niżej: Gotowy / Gotowy z warunkami / Niegotowy / Nie dotyczy.
2. Kryteria gotowości per obszar
2.1 Rozwiązanie
#
Kryterium
Dowód
Właściciel
Status
S1
SAT zakończony, udokumentowany i zatwierdzony przez komitet sterujący
[Link do raportu zakończenia SAT]
[Lider testów]
S2
Wszystkie obiekty CRIM dostarczone na produkcję i przetestowane
[Log CRIM ze statusem]
[Kierownik projektu dostawcy]
S3
Brak otwartego defektu blokującego wdrożenie
[Filtr logu defektów]
[Lider testów]
S4
Konfiguracja funkcjonalna i techniczna na produkcji kompletna i zgodna z zaakceptowaną bazową wersją
[Checklista konfiguracji]
[Architekt rozwiązania]
S5
Test obciążeniowy odebrany, jeśli wymagany przez strategię testów
[Raport lub decyzja "Niewymagane"]
[Lider IT po stronie klienta]
Przykład: S2
Przykład: Pola niestandardowe na linii zamówienia zakupu, layout raportu zamówienia do dostawcy i format pliku płatności bankowych są na produkcji w wersji przetestowanej w SAT
Przykład: Przekazanie do wsparcia (szablon IDK-22), sekcja 6, wersja produkcyjna per obiekt CRIM
Przykład: Kierownik projektu dostawcy
Przykład: Gotowy
2.2 Dane
#
Kryterium
Dowód
Właściciel
Status
D1
Rutyny migracji zwalidowane na pełnych wolumenach
[Dziennik próby generalnej]
[Lider migracji danych]
D2
Każdy zestaw danych zwalidowany i podpisany przez właściciela danych w ostatnim load
[Podpisy walidacji]
[Właściciele danych]
D3
Czyszczenie danych legacy zakończone lub pozostała praca zaakceptowana
[Tracker czyszczenia]
[Właściciele danych]
D4
Metoda uzgadniania sald uzgodniona z finansami
[Procedura uzgadniania]
[Lider finansów]
D5
Zadania ręcznego wprowadzania danych zaplanowane z właścicielami i czasem
[Checklista cutover]
[Kierownik cutover]
2.3 Użytkownicy i szkolenia
#
Kryterium
Dowód
Właściciel
Status
U1
ORT zakończony; użytkownicy eksperci podpisali oświadczenie potwierdzające
[Link do oświadczenia ORT]
[Lider testów]
U2
Szkolenia użytkowników końcowych zrealizowane; nieobecni mają datę sesji uzupełniającej przed go-live
[Rejestr obecności]
[Lider szkoleń]
U3
Instrukcje krok po kroku finalne i dostępne dla wszystkich użytkowników
[Link do biblioteki instrukcji]
[Lider szkoleń]
U4
Użytkownicy eksperci wskazani per lokalizacja i obszar, znani użytkownikom
[Lista użytkowników ekspertów]
[Kierownik projektu klienta]
2.4 Bezpieczeństwo
#
Kryterium
Dowód
Właściciel
Status
X1
Role i zestawy uprawnień zbudowane i przetestowane loginami opartymi na roli
[Macierz ról, dowód z SAT]
[Lider bezpieczeństwa]
X2
Użytkownicy przypisani do ról na produkcji
[Eksport użytkowników i zestawów uprawnień]
[Lider bezpieczeństwa]
X3
Konflikty rozdzielenia obowiązków przejrzane i zaakceptowane
[Zapis przeglądu]
[Lider finansów, kontakt audytora]
X4
Konta projektowe i konsultanckie przejrzane; podwyższony dostęp ma datę końcową
[Lista kont]
[Lider IT po stronie klienta]
X5
Konta integracyjne i serwisowe mają wyłącznie dostęp, którego potrzebują
[Lista kont z zestawami uprawnień]
[Lider integracji]
2.5 Infrastruktura i środowiska
#
Kryterium
Dowód
Właściciel
Status
I1
Środowisko produkcyjne na uzgodnionym poziomie wydania i aktualizacji serwisowej
[Zapis środowiska]
[Lider IT po stronie klienta]
I2
Dostęp sieciowy, single sign-on i dostawca tożsamości przetestowane z każdej lokalizacji
[Zapis testu per lokalizacja]
[Lider IT po stronie klienta]
I3
Drukarki, drukarki etykiet, skanery i urządzenia mobilne przetestowane w każdej lokalizacji
[Checklista urządzeń]
[Liderzy lokalizacji]
I4
Kopia zapasowa przed udostępnieniem systemu użytkownikom zorganizowana i potwierdzona
Każdy interfejs z rejestru interfejsów przetestowany end-to-end ze stroną zewnętrzną
[Rejestr interfejsów ze statusem testów]
[Lider integracji]
N2
Punkty produkcyjne, certyfikaty i poświadczenia na miejscu i zweryfikowane
[Checklista]
[Lider integracji]
N3
Monitoring i obsługa błędów dla każdego interfejsu mają wskazanego właściciela
[Rejestr interfejsów]
[Lider integracji]
N4
Interfejsy legacy do zatrzymania są wymienione w checkliście cutover
[Checklista cutover]
[Kierownik cutover]
Przykład: N1
Przykład: Plik płatności bankowych zaakceptowany przez bank w kanale testowym; wysyłka zamówień do dostawców odebrana i potwierdzona przez dostawców pilotażowych
Szablon IDK-20, wersja 1.0. Faza: Implement Solution (przygotowany i przećwiczony), Go Live (wykonany).
Jak korzystać z tego szablonu
To jeden dokument z dwoma poziomami szczegółowości. Sekcja 2 planuje okres wokół go-live z dokładnością do dnia. Sekcja 3 planuje dni wokół go-live z dokładnością do godziny.
Przygotuj szkice obu sekcji przed pierwszą próbą generalną. Czasy trwania w sekcjach 3 i 5 muszą pochodzić z próby generalnej na pełnych wolumenach danych, nigdy z szacunku. Przeprowadź więcej niż jedną próbę.
W trakcie cutover to jest dokument żywy. Kierownik cutover aktualizuje rzeczywiste czasy w miarę kończenia zadań i przegląda status na krótkich, częstych spotkaniach.
Wiersze oznaczone Przykład: pokazują oczekiwany poziom szczegółowości. Usuń je z roboczej kopii.
Plan awaryjny (sekcja 9) jest zatwierdzany razem z planem. Cutover bez spisanej drogi powrotnej nie jest gotowy do bramki.
Metadane szablonu
Field
Value
ID szablonu
IDK-20
Faza
Implement Solution (przygotowany i przećwiczony), Go Live (wykonany)
Właściciel
Kierownik cutover
Zatwierdzający
Komitet sterujący
Bramka kwalifikacyjna
Go Live Authorised
Wersja
1.0
Kontrola dokumentu
Pole
Wartość
Projekt
[nazwa projektu]
Klient
[podmiot prawny]
Zakres go-live
[Firmy, lokalizacje, procesy]
Planowana data go-live
[YYYY-MM-DD]
Właściciel dokumentu
[imię i nazwisko, kierownik cutover]
Status
[Szkic / Przećwiczony / Zatwierdzony / W trakcie realizacji / Zamknięty]
Wersja
[x.y]
Lokalizacja
[Link. W trakcie cutover trzymaj też kopię offline.]
Dokumenty powiązane
[Plan migracji danych, decyzja o gotowości do startu (szablon IDK-21), plan komunikacji, strategia wycofania systemu legacy, przekazanie do wsparcia (szablon IDK-22)]
Wersja
Data
Autor
Zmiana
[0.1]
[YYYY-MM-DD]
[imię i nazwisko]
[Pierwszy szkic]
1. Organizacja cutover
Rola
Imię i nazwisko
Kontakt w trakcie cutover
Zastępstwo
Kierownik cutover
[imię i nazwisko]
[telefon]
[imię i nazwisko]
Kierownik projektu po stronie klienta
[imię i nazwisko]
[telefon]
[imię i nazwisko]
Kierownik projektu po stronie dostawcy
[imię i nazwisko]
[telefon]
[imię i nazwisko]
Lider migracji danych
[imię i nazwisko]
[telefon]
[imię i nazwisko]
Lider techniczny, środowiska
[imię i nazwisko]
[telefon]
[imię i nazwisko]
Lider integracji
[imię i nazwisko]
[telefon]
[imię i nazwisko]
Liderzy walidacji biznesowej per obszar
[imiona i nazwiska]
[telefon]
[imiona i nazwiska]
Decydent go / rollback
[imię i nazwisko, rola]
[telefon]
[imię i nazwisko]
Przeglądy statusu w trakcie cutover: [godziny, kanał, uczestnicy]. Zasada decyzyjna, gdy decydent jest nieosiągalny: [tekst].
[Nierozpoczęte / W trakcie / Zakończone / Opóźnione]
Przykład: C-012
[YYYY-MM-DD]
Przykład: Przygotowanie biznesowe
Przykład: Wstrzymanie tworzenia nowych zamówień zakupu w legacy; pilne zakupy rejestrowane na uzgodnionym formularzu ręcznym do wprowadzenia po go-live
Przykład: Kierownik zaopatrzenia
Przykład: C-008 wysłane powiadomienie do dostawców
[YYYY-MM-DD]
Nierozpoczęte
Przykład: C-015
[YYYY-MM-DD]
Przykład: Migracja danych
Przykład: Finalny wyciąg danych podstawowych dostawców, klientów i części z legacy; zarejestrowane sumy kontrolne
Przykład: Lider migracji danych
Przykład: C-012, C-013
[YYYY-MM-DD]
Nierozpoczęte
Okresy zamrożenia biznesowego:
Proces
Zamrożenie od
Zamrożenie do
Procedura ręczna w okresie zamrożenia
Właściciel
[Proces]
[data, godzina]
[data, godzina]
[tekst lub link]
[imię i nazwisko]
3. Checklista cutover (z dokładnością do godziny)
Lp.
Planowany start
Planowany koniec
Zadanie
Właściciel
Poprzednik
Punkt kontrolny
Rzeczywisty start
Rzeczywisty koniec
Status
[n]
[dzień, gg:mm]
[dzień, gg:mm]
[zadanie]
[imię i nazwisko]
[Lp.]
[Brak / Go-no-go / Punkt bez odwrotu]
Przykład: 14
[dzień, gg:mm]
[dzień, gg:mm]
Przykład: Przełączenie legacy w tryb tylko do odczytu dla wprowadzania zamówień, zakupów i transakcji magazynowych
Przykład: Administrator systemu legacy
Przykład: 13
Brak
Przykład: 15
[dzień, gg:mm]
[dzień, gg:mm]
Przykład: Uruchomienie zadań Data Migration Manager dla otwartych zamówień zakupu; porównanie liczby i wartości załadowanych linii z sumami kontrolnymi wyciągu
Każde zadanie ma jednego wskazanego właściciela, obecnego lub osiągalnego w planowanym czasie.
Każdy planowany czas trwania to najdłuższy czas zaobserwowany w próbie generalnej, plus bufor uzgodniony w projekcie: [uzgodnić w projekcie].
Zadanie jest zakończone, gdy jego właściciel zgłosi to kierownikowi cutover. Nie wcześniej.
4. Przełączniki konfiguracyjne krytyczne czasowo
Ustawienia, które muszą pozostać wyłączone do precyzyjnego momentu albo zostać zmienione w precyzyjnym momencie.
#
Przełącznik
Środowisko
Z
Na
Kiedy (lp. checklisty)
Właściciel
Zweryfikowane przez
[n]
[ustawienie]
[Produkcja]
[stan]
[stan]
[Lp.]
[imię i nazwisko]
[imię i nazwisko]
Przykład: 1
Przykład: Zaplanowane zadania w tle dla przetwarzania zamówień i planowania
Produkcja
Przykład: Nieaktywne
Przykład: Aktywne z harmonogramem produkcyjnym
[Lp.]
Przykład: Lider techniczny
Przykład: Lider łańcucha dostaw
Przykład: 2
Przykład: Routing integracji do stron zewnętrznych (wysyłka zamówień do dostawców, pliki bankowe)
Produkcja
Przykład: Punkty testowe lub wyłączone
Przykład: Punkty produkcyjne
[Lp.]
Przykład: Lider integracji
Przykład: Lider finansów
[n]
[Workflow i event actions wysyłające e-mail do dostawców lub klientów]
[n]
[Wartości startowe serii numeracyjnych]
[n]
[Okresy księgowe otwarte dla grup użytkowników]
[n]
[Użytkownicy końcowi aktywowani i przypisani do produkcyjnych zestawów uprawnień]
5. Kolejność migracji danych
Data Migration Manager ładuje dane przez standardową logikę biznesową. Rekordy nieprawidłowe są odrzucane przy ładowaniu, więc kolejność ma znaczenie, a każde ładowanie wymaga sprawdzenia odrzuceń.
[Sumy kontrolne, liczba rekordów, kontrola wyrywkowa]
[imię i nazwisko]
Przykład: 3
Przykład: Dostawcy z adresami, warunkami płatności i powiązaniami części zakupowych
Przykład: Data Migration Manager
Przykład: Plik wyciągu z legacy [nazwa]
Przykład: 1 dane podstawowe, 2 części
[z dziennika próby]
[z dziennika próby plus bufor]
Przykład: Liczba rekordów równa wyciągowi; lista odrzuceń pusta lub każde odrzucenie wyjaśnione; kontrola wyrywkowa przez zaopatrzeniowców
Przykład: Lider zaopatrzenia
Przykład: 7
Przykład: Stan magazynowy per lokalizacja
Przykład: Data Migration Manager
Przykład: Wyciąg z inwentaryzacji legacy po finalnym spisie
Przykład: 2 części, 5 lokalizacji
[z dziennika próby]
[z dziennika próby plus bufor]
Przykład: Ilość i wartość per lokalizacja równa raportowi magazynowemu legacy
Przykład: Lider magazynu, lider finansów
Obsługa odrzuceń: [kto przegląda odrzucenia, kto poprawia dane źródłowe, jak zatwierdzany jest ponowny load].
6. Komunikacja
Odbiorca
Wiadomość
Nadawca
Kanał
Kiedy
Kanał zwrotny
Zrobione
Zespół projektowy
[Harmonogram cutover, role, godziny spotkań statusowych, lista kontaktów]
[Kierownik cutover]
[kanał]
[YYYY-MM-DD]
[kanał]
[ ]
Użytkownicy
[Daty zamrożenia, instrukcja pierwszego logowania, gdzie szukać pomocy, gdzie są instrukcje]
[Kierownik projektu klienta]
[kanał]
[YYYY-MM-DD]
[Użytkownicy eksperci]
[ ]
Biznes i kierownictwo
[Decyzja go-live, oczekiwane zakłócenia, aktualizacje statusu w trakcie cutover, potwierdzenie go-live]
[Sponsor]
[kanał]
[YYYY-MM-DD]
[Komitet sterujący]
[ ]
Dostawcy
[Nowe layouty dokumentów, zmienione numery zamówień, przerwa w zamawianiu, kontakt w sprawie pytań]
[Kierownik zaopatrzenia]
[kanał]
[YYYY-MM-DD]
[skrzynka]
[ ]
Klienci
[Przerwa w dostawach i fakturowaniu, zmienione layouty dokumentów, kontakt w sprawie pytań]
[Kierownik sprzedaży]
[kanał]
[YYYY-MM-DD]
[skrzynka]
[ ]
Przykład: Dostawcy
Przykład: Żadne zamówienia zakupu nie zostaną wystawione między [YYYY-MM-DD] a [YYYY-MM-DD]. Zamówienia po tym terminie mają nowy format numeru. Potwierdzenia proszę kierować na [adres].
Przykład: Kierownik zaopatrzenia
Przykład: E-mail do kontaktów dostawców z migrowanego rejestru dostawców
[YYYY-MM-DD]
Przykład: Skrzynka zaopatrzenia
[ ]
7. Wycofanie systemu legacy
System / interfejs
Działanie przy go-live
Działanie później
Potrzeba retencji danych
Właściciel
Data
[system]
[Tylko do odczytu / Zatrzymany / Działa równolegle z powodu: przyczyna]
[Archiwizacja / Wyłączenie / Koniec umowy]
[Wymóg prawny lub audytowy]
[imię i nazwisko]
[YYYY-MM-DD]
Przykład: Legacy ERP
Przykład: Tylko do odczytu dla wszystkich użytkowników od lp. checklisty [n]
Przykład: Archiwizacja i wyłączenie po okresie ze strategii wycofania
Przykład: Zapisy finansowe wg przepisów lokalnych
Przykład: Kierownik IT
[YYYY-MM-DD]
Interfejsy legacy do zatrzymania: [lista z rejestru interfejsów, z właścicielem i lp. checklisty].
8. Ustalenia dotyczące wsparcia
Pozycja
Ustalenie
Kontakt pierwszej linii
Użytkownicy eksperci per lokalizacja i obszar: [link do listy]
Druga linia
[Zespół kluczowy, lokalizacja, godziny]
Wsparcie dostawcy przy go-live
[Kto, na miejscu czy zdalnie, okres: uzgodnić w projekcie]
Rejestrowanie zgłoszeń
[Narzędzie, kto może zgłaszać, czas triage]
Floor walking
[Harmonogram per lokalizacja]
Service desk
[Przeszkolony w podstawowej administracji: Tak / Nie. Zakres: hasła, aktywacja użytkownika, routing drukarek.]
Spotkania statusowe po go-live
[Częstotliwość i długość: uzgodnić w projekcie]
Przejście do wsparcia standardowego
[Data, patrz przekazanie do wsparcia (szablon IDK-22)]
9. Plan awaryjny
9.1 Wyzwalacze
Wyzwalacz
Jak mierzone
Decyzja
[Warunek, który sprawia, że kontynuowanie jest niebezpieczne]
[dowód]
[Wstrzymanie / Rollback / Kontynuacja z obejściem]
Przykład: Salda magazynowe nie zgadzają się z legacy po ponownym załadowaniu
Przykład: Wartość per lokalizacja względem raportu magazynowego legacy
Przykład: Wstrzymanie na punkcie kontrolnym go-no-go; rollback, jeśli nie rozwiązane przed punktem bez odwrotu
9.2 Punkt bez odwrotu
Pozycja
Wartość
Definicja
[Krok checklisty, po którym legacy nie może już zostać przywrócony bez utraty lub ponownego wprowadzenia transakcji biznesowych]
Część A to plan szkoleń: jeden na projekt. Część B to opis kursu: kopiujesz ją raz na każdy kurs w katalogu.
Najpierw napisz podsumowanie strategii szkoleniowej. Materiały buduje się dopiero po uzgodnieniu strategii.
Buduj kursy wokół ról biznesowych, nie wokół modułów. Kurs oparty na roli da się wykorzystać ponownie przy nowych pracownikach i kolejnych wdrożeniach.
Wiersze oznaczone Przykład: pokazują oczekiwany poziom szczegółowości. Usuń je z roboczej kopii.
Celem jest, żeby [Klient] mógł szkolić własnych ludzi bez pomocy z zewnątrz. Każdą decyzję w tym dokumencie sprawdzaj pod kątem tego celu.
Solution Established (plan zatwierdzony), Go Live Authorised (szkolenia zrealizowane)
Wersja
1.0
Kontrola dokumentu
Pole
Wartość
Projekt
[nazwa projektu]
Klient
[podmiot prawny]
Właściciel dokumentu
[imię i nazwisko, lider szkoleń po stronie klienta]
Status
[Szkic / W przeglądzie / Zatwierdzony]
Wersja
[x.y]
Lokalizacja
[link]
Dokumenty powiązane
[Strategia szkoleniowa, macierz ról, instrukcje krok po kroku, strategia testów (szablon IDK-17), plan cutover (szablon IDK-20)]
Wersja
Data
Autor
Zmiana
[0.1]
[YYYY-MM-DD]
[imię i nazwisko]
[Pierwszy szkic]
Część A. Plan szkoleń
1. Podsumowanie strategii szkoleniowej
Pytanie
Odpowiedź
Jaki jest cel szkoleń?
[Samodzielność klienta: wewnętrzni trenerzy, materiały wielokrotnego użytku, użytkownicy eksperci jako pierwszy punkt kontaktu]
Kto szkoli zespół kluczowy?
[Konsultanci aplikacyjni dostawcy]
Kto szkoli użytkowników ekspertów?
[Członkowie zespołu kluczowego, którzy przeszli train-the-trainer]
Kto szkoli użytkowników końcowych?
[Wewnętrzni użytkownicy eksperci]
Kiedy szkoleni są użytkownicy końcowi?
[Możliwie blisko go-live; okno: uzgodnić w projekcie]
W jakim środowisku?
[Nazwa środowiska szkoleniowego, zestaw danych, zasada odświeżania]
W jakich językach?
[lista]
Jak egzekwowana jest obecność?
[Zobowiązanie przełożonego liniowego; dostęp do produkcji dopiero po odbyciu szkolenia: Tak / Nie]
Jak sprawdzana jest skuteczność?
[Ocena po każdym kursie; potwierdzenie ORT przez użytkowników ekspertów]
2. Odbiorcy i role
Odbiorca
Kim są
Czego potrzebują
Szkoleni przez
Kiedy
Zespół kluczowy
[Członkowie zespołu funkcjonalnego]
Szeroki obraz rozwiązania i tego, jak integrują się obszary; głębia we własnym obszarze
Konsultanci dostawcy
[Establish Solution]
Zespół techniczny
[Analitycy techniczni, administratorzy]
[Administracja i konfiguracja, zestawy uprawnień, Data Migration Manager, konfiguracja lobby, obiekty niestandardowe, Business Process Automation, projektowanie raportów, konfiguracja integracji, Build Place]
Zasoby techniczne dostawcy
[Establish Solution]
Użytkownicy eksperci
[Wskazani per lokalizacja i obszar]
Pełne kursy oparte na roli plus umiejętności wsparcia
Trenerzy z zespołu kluczowego
[Implement Solution, przed ORT]
Użytkownicy końcowi
[Wg roli biznesowej]
Tylko to, co dotyczy ich roli, w ich własnych słowach
Użytkownicy eksperci
[Implement Solution, blisko go-live]
Kierownicy
[Przełożeni liniowi, osoby zatwierdzające]
Zatwierdzenia, lobby, co zmienia się dla ich zespołów
[Zespół kluczowy]
[uzgodnić w projekcie]
Service desk
[imiona i nazwiska]
Podstawowa administracja, obsługa użytkowników i zestawów uprawnień, gdzie znaleźć instrukcje
[Zespół techniczny]
[Przed go-live]
Zasada dla zespołu kluczowego: uczestniczcie w kursach spoza własnego obszaru. Ktoś z zespołu technicznego uczestniczy w kursach funkcjonalnych, żeby jedna osoba rozumiała obie strony.
Mapowanie roli biznesowej na kursy:
Rola biznesowa
Zestaw(y) uprawnień
Wymagane kursy
Liczba osób
Lokalizacje
[Rola]
[nazwy]
[ID kursów]
[n]
[lokalizacje]
Przykład: Zaopatrzeniowiec
Przykład: [PS_PURCHASER]
Przykład: GEN-01, PUR-01, PUR-02
[n]
[lokalizacje]
3. Metody prowadzenia
Metoda
Stosowana do
Uwagi
Sala szkoleniowa, praktyka w środowisku szkoleniowym
[Kursy dla użytkowników końcowych oparte na roli]
Krótkie sesje, małe grupy: [wielkość grupy i długość sesji: uzgodnić w projekcie]
Sesja zdalna na żywo
[Lokalizacje bez lokalnego trenera]
[Narzędzie, zasada nagrywania]
Nagranie
[Wprowadzenie do koncepcji, przypomnienia, nowi pracownicy]
[Lokalizacja przechowywania]
Instrukcja krok po kroku, samodzielna nauka
[Zadania wykonywane rzadko]
[Link do biblioteki instrukcji]
Floor walking po go-live
[Wszystkie lokalizacje]
[Użytkownicy eksperci, harmonogram w planie cutover]
4. Train-the-trainer
Pozycja
Ustalenie
Kto zostaje trenerem
[Imiona i nazwiska, obszar, lokalizacja]
Sesja train-the-trainer
[Data, prowadzący, zakres: podstawy nauczania dorosłych, przejście przez scenariusz instruktora, obsługa pytań, resetowanie zestawów danych]
Zasada
Nikt nie prowadzi kursu przed odbyciem train-the-trainer i wcześniejszym udziałem w kursie jako uczestnik.
Podejście wielolokalizacyjne
[Które lokalizacje szkolone są najpierw; wpływowe lokalizacje angażowane są wcześnie, żeby przekazały wiadomość dalej]
Zastępstwo trenera
[Drugi trener na kurs]
5. Katalog kursów
ID kursu
Nazwa kursu
Odbiorca / rola
Format
Długość
Trener
Wykorzystane instrukcje
Status materiału
[ID]
[nazwa]
[rola]
[metoda]
[uzgodnić w projekcie]
[imię i nazwisko]
[nazwy instrukcji]
[Nierozpoczęty / Szkic / Przetestowany z użytkownikami ekspertami / Finalny]
Przykład: GEN-01
Przykład: Poruszanie się w IFS Cloud: nawigacja, wyszukiwanie, lobby, zapisane wyszukiwania, załączniki
Przykład: Wszyscy użytkownicy
Przykład: Sala szkoleniowa
[uzgodnić w projekcie]
[imię i nazwisko]
Przykład: Podstawy nawigacji
Szkic
Przykład: PUR-01
Przykład: Od zapotrzebowania do zwolnionego zamówienia zakupu
Przykład: Zaopatrzeniowiec
Przykład: Sala szkoleniowa, praktyka
[uzgodnić w projekcie]
[imię i nazwisko]
Przykład: Utworzenie zapotrzebowania; Zamiana na zamówienie; Wysłanie zamówienia
Szkic
6. Harmonogram z uczestnikami
ID sesji
ID kursu
Data i godzina
Miejsce / link
Trener
Uczestnicy
Przełożony liniowy poinformowany
Środowisko zarezerwowane
[ID]
[ID]
[data, godzina]
[sala / link]
[imię i nazwisko]
[imiona i nazwiska lub link do listy]
[Tak / Nie]
[Tak / Nie]
Przykład: S-031
Przykład: PUR-01
[data, godzina]
[sala]
[imię i nazwisko]
[imiona i nazwiska]
Tak
Tak
Zasady planowania:
Użytkownicy eksperci są szkoleni jako pierwsi. Ich sesje są jednocześnie testem materiału. Poprawki wprowadza się przed rozpoczęciem sesji dla użytkowników końcowych.
Sesje dla użytkowników końcowych odbywają się [możliwie blisko go-live; okno: uzgodnić w projekcie].
Sesje uzupełniające dla nieobecnych: [daty].
Środowisko szkoleniowe jest odświeżane zestawem danych w dniach [daty], przez [imię i nazwisko].
7. Ryzyka
Ryzyko
Mitygacja
Właściciel
Użytkownicy niezwolnieni na szkolenie
[Sesje uzgodnione z przełożonymi liniowymi; obecność raportowana do komitetu sterującego]
[Kierownik projektu klienta]
Szkolenie zbyt wcześnie, wiedza zanika przed go-live
[Nagrania przypominające; floor walking]
[Lider szkoleń]
[Ryzyko]
[Mitygacja]
[imię i nazwisko]
Część B. Opis kursu
B1. Nagłówek kursu
Pole
Wartość
ID i nazwa kursu
[ID, nazwa]
Wersja
[x.y]
Właściciel kursu
[imię i nazwisko]
Cel
[Po tym kursie uczestnik potrafi ..., bez pomocy, korzystając z instrukcji krok po kroku]
Odbiorca
[Rola(-e) biznesowa(-e)]
Warunki wstępne
[Odbyte kursy; aktywne konto użytkownika i zestaw uprawnień w środowisku szkoleniowym]
Długość
[uzgodnić w projekcie]
Wielkość grupy
[uzgodnić w projekcie]
Format
[Sala szkoleniowa / zdalny / mieszany]
Przykładowy cel: Po tym kursie zaopatrzeniowiec potrafi utworzyć zapotrzebowanie, zamienić je na zamówienie zakupu, wysłać je do dostawcy i zarejestrować potwierdzenie dostawcy, w tym zmienioną datę dostawy.
Przykład: Dlaczego proces się zmienia i co to oznacza dla zaopatrzeniowca
Przykład: Koncepcja
Brak
Przykład: 2
Przykład: Utworzenie i zwolnienie zapotrzebowania zakupu
Przykład: Demonstracja, potem ćwiczenie
Przykład: Utworzenie zapotrzebowania
Każdy kurs zaczynaj od tego, co zmienia się dla danej roli i co uczestnik zyskuje. Ekrany są na drugim miejscu.
B3. Scenariusz instruktora
#
Co robi trener
Co mówi trener (kluczowe punkty)
Co robią uczestnicy
Na co uważać
1
[działanie]
[punkty]
[działanie]
[typowy błąd, typowe pytanie]
Przykład: 2
Przykład: Pokazuje stronę Zapotrzebowanie zakupu, tworzy jedną linię, zwalnia ją
Przykład: Dostawca i cena pochodzą z rekordu dostawcy dla części zakupowej. Jeśli ich brakuje, to problem z danymi do zgłoszenia, a nie coś do ręcznego wpisania.
Przykład: Powtarzają z własną częścią z arkusza zestawu danych
Przykład: Użytkownicy wybierają złą lokalizację. Poproś, żeby najpierw sprawdzili pole lokalizacji.
B4. Zestaw danych
Pozycja
Wartość
Środowisko szkoleniowe
[nazwa]
Nazwa i wersja zestawu danych
[nazwa]
Dane na uczestnika
[Własne części, dostawcy, klienci, żeby ćwiczenia się nie zderzały]
Procedura resetowania
[Jak zestaw danych jest przywracany między sesjami, przez kogo]
Loginy
[Użytkownicy szkoleniowi oparci na roli, z produkcyjnymi zestawami uprawnień]
Nr uczestnika
Login
Część
Dostawca
Lokalizacja
Przykład: P01
Przykład: [TRN_PUR_01]
[nr części]
[ID dostawcy]
[lokalizacja]
B5. Wykorzystane instrukcje krok po kroku
Instrukcja
Wersja
Zweryfikowana w SAT
Lokalizacja
[nazwa]
[x.y]
[Tak / Nie]
[link]
Instrukcje są pisane w języku użytkownika końcowego. Jeśli instrukcja zawiera błąd, trener zgłasza go do [imię i nazwisko] tego samego dnia.
B6. Zadanie domowe
Zadanie
Gdzie wykonywane
Sprawdzane przez
[Zadanie, które uczestnik powtarza samodzielnie po sesji]
[Środowisko szkoleniowe]
[Użytkownik ekspert]
Przykład: Utwórz i zwolnij zamówienie na części, które kupujecie najczęściej, korzystając wyłącznie z instrukcji
Środowisko szkoleniowe
Użytkownik ekspert ds. zaopatrzenia
B7. Ocena
Pytanie
Jak mierzone
Czy uczestnik potrafi wykonać zadanie samodzielnie?
[Sprawdzenie praktyczne na koniec sesji: zadanie, zasada zaliczenia]
Czy kurs był przydatny?
[Formularz opinii: link]
Co musi się zmienić w materiale?
[Notatki trenera po każdej sesji]
Część C. Rejestr obecności i oceny
ID sesji
Uczestnik
Rola
Obecny
Sprawdzenie praktyczne
Wymagane działanie uzupełniające
Trener
[ID]
[imię i nazwisko]
[rola]
[Tak / Nie]
[Zaliczone / Do powtórzenia]
[Brak / tekst]
[imię i nazwisko]
Przykład: S-031
[imię i nazwisko]
Zaopatrzeniowiec
Tak
Zaliczone
Brak
[imię i nazwisko]
Podsumowanie dla bramki:
Miara
Wartość
Użytkownicy zaplanowani do szkolenia
[n]
Użytkownicy przeszkoleni
[n]
Użytkownicy pozostali, z datą sesji uzupełniającej
[n, data]
Użytkownicy przypisani do ról na produkcji
[Tak / Nie]
Otwarte poprawki materiału
[n, właściciel]
Zatwierdzenie
Rola
Imię i nazwisko
Decyzja
Data
Podpis
Lider szkoleń po stronie klienta (właściciel)
[imię i nazwisko]
[Przekazano]
[YYYY-MM-DD]
Kierownik projektu po stronie klienta
[imię i nazwisko]
[Zatwierdzono / Odrzucono]
[YYYY-MM-DD]
Kierownik projektu po stronie dostawcy
[imię i nazwisko]
[Zweryfikowano]
[YYYY-MM-DD]
Przewodniczący komitetu sterującego (szkolenia użytkowników końcowych zakończone)
[imię i nazwisko]
[Potwierdzono]
[YYYY-MM-DD]
Niezależny szablon zgodny z metodyką wdrożeniową IFS. Nie jest oficjalnym dokumentem IFS. IFS jest zastrzeżonym znakiem towarowym IFS AB.
Deutsch (Deutschland) 
English (United Kingdom) 
