Szablon: Zakres projektu (IDK-02)

Szablon IDK-02, wersja 1.0. Faza: Initiate Project.

Jak korzystać z tego szablonu

Napisz go podczas fazy Initiate Project, równolegle z Planem zarządzania projektem (IDK-01). Plan mówi, jak projekt jest prowadzony. Ten dokument mówi, co projekt dostarcza.
Szkic przygotowuje kierownik projektu po stronie dostawcy na podstawie umowy i materiałów z fazy sprzedażowej. Kierownik projektu klienta i właściciele procesów poprawiają go, aż rozpoznają w nim swój biznes.
Zastąp każde pole [w nawiasie kwadratowym]. Usuń wiersze oznaczone jako Przykład:, gdy masz już własne.
Dokument jest gotowy, gdy komitet sterujący go podpisał, a każda pozycja w zakresie ma kryterium akceptacji i rolę akceptującą. Pozycja zakresu bez kryterium akceptacji to spór, który dopiero czeka, by się wydarzyć.
Jest potwierdzany po raz drugi na bramce Solution Confirmed, po prototypie. Zmiany w międzyczasie przechodzą przez kontrolę zmian (IDK-07).

Metadane szablonu
Field	Value
ID szablonu	IDK-02
Faza	Initiate Project
Właściciel	Kierownik projektu po stronie dostawcy (przy wsparciu kierownika projektu po stronie klienta)
Zatwierdzający	Komitet sterujący
Bramka kwalifikacyjna	Project Initiated
Wersja	1.0

Kontrola dokumentu

Wersja	Data	Autor	Zmiana	Zatwierdził
0.1	[YYYY-MM-DD]	[imię i nazwisko, rola]	Pierwszy szkic na podstawie umowy i statement of work
1.0	[YYYY-MM-DD]	[imię i nazwisko, rola]	Baseline dla bramki Project Initiated	[przewodniczący komitetu sterującego]
[n.n]	[YYYY-MM-DD]	[imię i nazwisko, rola]	Potwierdzone po prototypie, bramka Solution Confirmed	[przewodniczący komitetu sterującego]

1. Cel i kontekst

Pozycja	Treść
Dlaczego biznes realizuje ten projekt	[dwa lub trzy zdania w języku biznesowym, nie systemowym]
Co to teraz wywołało	[np.: koniec wsparcia systemu legacy, przejęcie, ograniczenie wzrostu]
Związek z celami korporacyjnymi	[który cel i jak ten projekt mu służy]
Umowa lub statement of work	[referencja, data]
Co ten dokument zastępuje	[prezentacje sprzedażowe, załączniki ofertowe, wcześniejsze listy zakresu]

2. Cele i mierzalne korzyści

Każda korzyść ma jednego właściciela po stronie biznesu, miernik i datę, do której jest oczekiwana. Sponsor wykonawczy odpowiada za realizację korzyści. Postęp przeglądany jest na każdym spotkaniu komitetu sterującego.

ID	Cel	Korzyść i sposób pomiaru	Dziś (wartość bazowa)	Cel docelowy	Oczekiwane do	Właściciel korzyści
Przykład: B-01	Jeden proces zakupowy we wszystkich lokalizacjach	Udział linii zamówień zakupu wystawionych z zatwierdzonego zapotrzebowania, odczytywany z elementu lobby na danych zamówień zakupu	[wartość dziś]	[uzgodnić w projekcie]	[YYYY-MM-DD]	Szef działu zakupów
Przykład: B-02	Wiarygodne stany magazynowe	Dokładność inwentaryzacji wg lokalizacji, na podstawie wyników spisów w systemie	[wartość dziś]	[uzgodnić w projekcie]	[YYYY-MM-DD]	Kierownik magazynu
[ID]	[cel]	[korzyść i miernik]	[wartość bazowa]	[cel]	[YYYY-MM-DD]	[rola, imię i nazwisko]

Cele, które nie są mierzalne, wymienione są tu jako zamierzenia, bez zobowiązania właściciela:

[zamierzenie]

3. Zakres oprogramowania

Pozycja	W zakresie
Produkt i wersja	IFS Cloud, wydanie [wydanie] na starcie projektu
Opcja wdrożenia	[hostowany przez IFS / wdrożenie zdalne u klienta]
Licencjonowane komponenty i moduły	[lista z umowy]
Komponenty licencjonowane, ale niewdrażane w tym projekcie	[lista, z uzasadnieniem]
Typy i liczba użytkowników	[z umowy; nie powtarzaj tu liczb, odnieś się do zapisu umowy]
Języki	Aplikacja: [języki]. Dokumentacja i przekazanie: angielski plus [język].
Lokalizacje i rozszerzenia krajowe	[lista]
Użycie mobilne i urządzenia	[np.: ręczne terminale magazynowe, mobilna aplikacja utrzymania ruchu]
Produkty firm trzecich w rozwiązaniu	[produkt, cel, kto go kontraktuje]
Podejście do aktualizacji	Service update i release update: [rytm uzgodniony w projekcie]; pierwsza aktualizacja po starcie produkcyjnym planowana na [okres]

4. Zakres rozwiązania wg obszaru procesowego

Szczegóły zawiera model procesów w [IFS Scope Tool lub uzgodnionym repozytorium]. Ta tabela jest podpisanym podsumowaniem. Jeden wiersz na proces end-to-end.

Obszar procesowy	Proces end-to-end	Lokalizacje i spółki	Właściciel procesu (klient)	Oczekiwana funkcjonalność standardowa	Znana potrzeba CRIM
Przykład: Zakupy	Zapotrzebowanie zakupowe do uzgodnienia z fakturą dostawcy	[lokalizacje]	Szef działu zakupów	Tak. Reguły autoryzacji konfigurowane osobno dla każdej spółki.	Jedna integracja: dane zamówień do systemu planowania transportu przez standardową projekcję
Przykład: Magazyn	Przyjęcie, składowanie, przesunięcie, inwentaryzacja, korekta	[lokalizacje]	Kierownik magazynu	Tak	Jedna konfiguracja: pole niestandardowe dla wewnętrznej klasy zagrożenia na karcie indeksu, widoczne przy przyjęciu
Przykład: Bezpieczeństwo	Role i zestawy uprawnień dla wszystkich procesów w zakresie	Wszystkie	Lider IT po stronie klienta z właścicielami procesów	Tak. Role funkcjonalne zbudowane z zestawów uprawnień użytkownika końcowego, rozdział obowiązków zweryfikowany przez finanse.	Brak
[obszar]	[proces]	[lokalizacje]	[rola, imię i nazwisko]	[tak / częściowo / nie, z uwagą]	[referencja CRIM lub brak]

4.1 Zakres danych

Zbiór danych	Źródło	W zakresie	Historia przenoszona	Metoda	Właściciel po stronie klienta
Przykład: Dostawcy i adresy dostawców	System legacy ERP	Tylko aktywni dostawcy; definicja "aktywny": [uzgodnić w projekcie]	Brak	Data Migration Manager	Steward danych zakupowych
Przykład: Salda magazynowe	System legacy ERP, spis końcowy	Wszystkie lokalizacje w zakresie	Tylko saldo otwarcia	Data Migration Manager	Kierownik magazynu
[zbiór danych]	[źródło]	[zasada]	[głębokość, uzgodnić w projekcie]	[narzędzie migracji / kopiuj-wklej / wprowadzanie ręczne]	[rola]

4.2 Zakres interfejsów

Wymieniony jest każdy interfejs, zarówno legacy, jak i nowy, w tym te, które zostaną wyłączone. Pełny rejestr interfejsów budowany jest przed rozpoczęciem budowy rozwiązania.

ID	Z	Do	Przepływające dane	Kierunek	Status w nowym rozwiązaniu
Przykład: INT-03	IFS Cloud	System planowania transportu	Potwierdzone linie zamówień zakupu, adres dostawy, oczekiwana data przyjęcia	Wyjściowy	Nowy, zastępuje eksport plikowy z systemu legacy
[ID]	[system]	[system]	[dane]	[wejściowy/wyjściowy/oba]	[nowy / zachowany / wyłączony]

5. Poza zakresem

Zapisanie, co jest wyłączone, zapobiega większej liczbie sporów niż zapisanie, co jest włączone. Każdy wiersz podaje przyczynę i gdzie potrzeba jest obsługiwana zamiast tego.

Pozycja	Przyczyna	Gdzie jest obsługiwana zamiast tego
Przykład: Migracja zamkniętych zamówień zakupu	Brak zastosowania operacyjnego po starcie produkcyjnym; wymóg retencji prawnej spełniony przez archiwum legacy	Archiwum legacy tylko do odczytu, prowadzone przez IT klienta
Przykład: Działania z zakresu zarządzania zmianą organizacyjną	Odpowiedzialność klienta	Lider zmiany po stronie klienta, referencja planu [referencja]
Przykład: Lokalizacje [lista lokalizacji]	Wdrożenie w kolejnym etapie	Osobny projekt, nieujęty w tym budżecie
[pozycja]	[przyczyna]	[właściciel lub projekt następczy]

6. Kryteria akceptacji

6.1 Akceptacja dostawy produktu

Produkt to to, czym klient będzie operacyjnie zarządzał: skonfigurowany IFS Cloud, obiekty CRIM, przeniesione dane, role i zestawy uprawnień.

#	Kryterium	Sposób udowodnienia	Rola akceptująca
1	Każdy proces w zakresie spełnia uzgodnione wymaganie	Skrypty testowe Solution Acceptance Test zaliczone, wyniki zapisane w trackerze testów	Właściciele procesów
2	Rozwiązanie działa z fizyczną operacją	Kroki testowe wykonane w rzeczywistym otoczeniu magazynu, hali produkcyjnej lub biura, z użyciem urządzeń i drukarek	Właściciele procesów
3	Zbudowane rozwiązanie, w tym CRIM, jest kompletne i nie zawiera błędów krytycznych dla działania	Lista błędów z klasyfikacją; żaden otwarty błąd nie blokuje wdrożenia	Kierownik projektu klienta
4	Przeniesione dane nadają się do użytku	Podpisanie walidacji funkcjonalnej dla każdego zbioru danych po ostatniej iteracji ładowania	Właściciele danych
5	Role odpowiadają rolom biznesowym	Test wykonany na loginach użytkowników końcowych i ich zestawach uprawnień, nie na dostępie administratora	Lider IT po stronie klienta i właściciele procesów
6	Instrukcje krok po kroku są poprawne	Instrukcje stosowane podczas testu akceptacyjnego bez korekty konsultanta	Liderzy funkcjonalni
[n]	[kryterium]	[dowód]	[rola]

Klasy błędów blokujące akceptację: [definicja uzgodniona w projekcie]. Błędy, które mogą zostać zamknięte po fazie: uzgadniane indywidualnie i wymienione z właścicielem i datą.

6.2 Akceptacja dostawy projektu

Dostawa projektu to praca: zakończone fazy, przekazane produkty, przygotowani ludzie.

#	Kryterium	Sposób udowodnienia	Rola akceptująca
1	Każda bramka kwalifikacyjna zaliczona	Zapis decyzji bramki podpisany przez komitet sterujący (IDK-08)	Komitet sterujący
2	Uzgodnione dokumenty dostawcy dostarczone	Lista dokumentów w IDK-01 sekcja 10 odhaczona, najnowsze wersje w repozytorium	Kierownik projektu klienta
3	Zespół podstawowy i użytkownicy eksperccy potrafią obsługiwać i wspierać rozwiązanie	Operational Readiness Test zakończony przez użytkowników eksperckich, zespół podstawowy tylko doradza	Sponsor wykonawczy
4	Przekazanie do wsparcia wykonane	Dokument przekazania kompletny, specyfikacje CRIM i specyfikacje testów w najnowszej wersji, spotkanie przekazania odbyte i udokumentowane	Obaj kierownicy projektu i lider wsparcia
5	Problemy pozostałe do rozwiązania mają właściciela	Dokument zamknięcia wymienia każdy pozostały problem z właścicielem i datą	Komitet sterujący
[n]	[kryterium]	[dowód]	[rola]

7. Struktura podziału prac i odpowiedzialności

Jeden wiersz na pakiet prac. R to strona wykonująca pracę, S to strona wspierająca.

Pakiet prac	Faza	Główny produkt	Klient	Dostawca
Inicjacja i planowanie projektu	Initiate Project	Zatwierdzony plan, karta zakresu, mechanizmy kontroli	S	R
Warsztaty modelu operacyjnego	Confirm Prototype	Dokumenty Book of Rules zatwierdzone przez klienta	R (decyzje i treść)	R (facylitacja i dokumentacja)
Budowa i demonstracja prototypu	Confirm Prototype	Zatwierdzony prototyp na przykładowych danych klienta	S	R
Czyszczenie danych	Od fazy Confirm Prototype	Oczyszczone dane źródłowe dla każdego zbioru	R	S
Mapowanie danych i iteracje ładowania	Establish Solution	Zwalidowane zadania migracji	R (ekstrakcja, walidacja)	R (mapowanie, wsparcie ładowania)
Warsztaty rozwiązania i konfiguracja	Establish Solution	Skonfigurowane procesy, zaktualizowany Book of Rules	R (decyzje, testy)	R (konfiguracja)
Role i zestawy uprawnień	Establish Solution	Zbudowane i przetestowane role funkcjonalne	R	S
Specyfikacja i budowa CRIM	Establish Solution	Zatwierdzone specyfikacje, dostarczone i przetestowane obiekty	R (zatwierdzanie, testy)	R (specyfikacja, budowa, testy jednostkowe)
Instrukcje krok po kroku i materiały szkoleniowe	Establish Solution	Finalne instrukcje i materiały kursowe	R	S
Solution Acceptance Test	Establish Solution	Udokumentowany i zatwierdzony wynik testu	R	S
Szkolenie użytkowników eksperckich i końcowych	Implement Solution	Przeszkoleni użytkownicy przypisani do ról	R	S
Operational Readiness Test	Implement Solution	Udokumentowany i zatwierdzony wynik testu	R	S
Planowanie i próba generalna cutover	Implement Solution	Przetestowany plan cutover, checklista i plan awaryjny	R (zadania biznesowe)	R (zadania techniczne, właściciel planu: [uzgodnić w projekcie])
Cutover i wsparcie startu produkcyjnego	Go Live	Rozwiązanie w eksploatacji	R	R
Przekazanie do wsparcia i zamknięcie	Go Live	Dokument przekazania, ewaluacja projektu, dokument zamknięcia	S	R
[pakiet prac]	[faza]	[produkt]	[R/S]	[R/S]

8. Kamienie milowe

Daty prowadzone są w baseline harmonogramu (IDK-01 sekcja 3). Wymienione tu, żeby zakres i kamienie milowe były podpisywane razem.

Kamień milowy	Faza	Data baseline
Bramka: Project Initiated	Initiate Project	[YYYY-MM-DD]
Kick-off odbyty	Confirm Prototype	[YYYY-MM-DD]
Prototyp zatwierdzony. Bramka: Solution Confirmed	Confirm Prototype	[YYYY-MM-DD]
Solution Acceptance Test zatwierdzony. Bramka: Solution Established	Establish Solution	[YYYY-MM-DD]
Próba generalna cutover zakończona	Implement Solution	[YYYY-MM-DD]
Operational Readiness Test zatwierdzony. Bramka: Go Live Authorised	Implement Solution	[YYYY-MM-DD]
Start produkcyjny	Go Live	[YYYY-MM-DD]
Bramka: Go Live Complete	Go Live	[YYYY-MM-DD]

9. Ograniczenia i zależności

Typ	Opis	Właściciel
Przykład: Zależność	Dostawca systemu planowania transportu musi dostarczyć swoją część INT-03 przed testami integracji	Lider IT po stronie klienta
Przykład: Ograniczenie	Start produkcyjny musi przypaść na granicę okresu finansowego i poza sezonowym szczytem	Dyrektor finansowy
[typ]	[opis]	[rola]

Zatwierdzenie

Imię i nazwisko	Rola	Data	Podpis
[imię i nazwisko]	Sponsor wykonawczy (klient)	[YYYY-MM-DD]	______________________
[imię i nazwisko]	Sponsor (dostawca)	[YYYY-MM-DD]	______________________
[imię i nazwisko]	Kierownik projektu klienta	[YYYY-MM-DD]	______________________
[imię i nazwisko]	Kierownik projektu dostawcy	[YYYY-MM-DD]	______________________
[imię i nazwisko]	Właściciel procesu, [obszar]	[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.

Marketplace