Szablon: Rejestr CRIM (IDK-10)

Szablon IDK-10, wersja 1.0. Faza: Confirm Prototype (potrzeby zidentyfikowane), Establish Solution (specyfikacja, budowa, testy).

Jak korzystać z tego szablonu

CRIM oznacza Konfiguracje, Raporty, Integracje i Modyfikacje (Configurations, Reports, Integrations, Modifications). Ten rejestr jest jedynym miejscem, w którym zapisuje się wszystko w rozwiązaniu, co nie jest zwykłą standardową funkcjonalnością.
Otwórz rejestr na pierwszym warsztacie. Podczas Confirm Prototype zapisujesz tylko potrzeby. Specyfikacja i budowa zaczynają się w Establish Solution, po wypełnieniu kolumny decyzji.
Każdy wiersz musi odpowiadać na pytanie w kolumnie „Rozważona alternatywa standardowa". Wiersz bez tej odpowiedzi nie jest gotowy do decyzji.
Rejestr jest podzielony na dwie tabele, które współdzielą ten sam ID: sekcja 5 obejmuje potrzebę i decyzję, sekcja 6 obejmuje dostawę i przekazanie. W arkuszu kalkulacyjnym mogą stanowić jedną szeroką tabelę.
Przeglądaj rejestr na każdym cotygodniowym spotkaniu kierowników projektu i przedstawiaj podsumowanie z sekcji 8 na każdym komitecie sterującym.
Usuń wiersze oznaczone Przykład:, gdy masz już własne.

Metadane szablonu
Field	Value
ID szablonu	IDK-10
Faza	Confirm Prototype (potrzeby zidentyfikowane), Establish Solution (specyfikacja, budowa, testy)
Właściciel	Kierownik projektu po stronie dostawcy, wspólnie z kierownikiem rozwiązania technicznego
Zatwierdzający	Kierownik projektu po stronie klienta dla konfiguracji i raportów, komitet sterujący dla integracji i modyfikacji
Bramka kwalifikacyjna	Solution Confirmed (potrzeby zidentyfikowane), Solution Established (obiekty dostarczone)
Wersja	1.0

Kontrola dokumentu

Pole	Wartość
Projekt	[nazwa projektu]
Właściciel rejestru	[imię i nazwisko, rola]
Kierownik rozwiązania technicznego	[imię i nazwisko]
Kierownik projektu po stronie klienta	[imię i nazwisko]
Lokalizacja przechowywania	[link]
Rytm przeglądu	Cotygodniowe spotkanie kierowników projektu, podsumowanie na każdym komitecie sterującym

Wersja	Data	Autor	Zmiana
0.1	[YYYY-MM-DD]	[imię i nazwisko]	Rejestr otwarty
[x.y]	[YYYY-MM-DD]	[imię i nazwisko]	[zmiana]

1. Cel i zasada „najpierw standard"

Celem projektu jest zaspokojenie każdej potrzeby procesowej standardową funkcjonalnością IFS Cloud i utrzymanie liczby modyfikacji, integracji i konfiguracji tak niskiej, jak biznes może zaakceptować. Każdy obiekt CRIM ma koszt w momencie budowy i ponownie przy każdej aktualizacji. Rejestr sprawia, że ten koszt jest widoczny, zanim ktokolwiek się na niego zdecyduje.

Zasada, stosowana do każdego wiersza:

Opisz potrzebę biznesową, nie wymarzone rozwiązanie.
Pokaż wnioskodawcy standardową funkcjonalność w systemie. Zapisz, co zostało pokazane.
Zapisz, dlaczego standard nie wystarcza, słowami wnioskodawcy i z konsekwencją dla biznesu.
Dopiero wtedy zaproponuj obiekt CRIM, na najniższym poziomie dostosowania, który zaspokaja potrzebę.
Jeśli uzasadnieniem jest „tak działa system legacy", wiersz jest odrzucany albo odsyłany do poprawy.

2. Definicje typów

Typ	Obejmuje	Potrzebna specyfikacja	Zatwierdzenie przed budową
C: Konfiguracja	Pola niestandardowe, Custom Events, konfiguracje stron, lobby, workflow (Business Process Automation), strony niestandardowe i podobne obiekty tworzone w kliencie webowym	Specyfikacja konfiguracji i raportu (szablon IDK-12)	Kierownik projektu po stronie klienta
R: Raport	Quick Reports, niestandardowe layouty raportów operacyjnych, modele analityczne i inne wyjścia wykraczające poza standard	Specyfikacja konfiguracji i raportu (szablon IDK-12)	Kierownik projektu po stronie klienta
I: Integracja	Każda wymiana danych z innym systemem, w dowolnym kierunku, włącznie z transferami plików. Wymieniona też w rejestrze interfejsów (szablon IDK-13)	Specyfikacja funkcjonalna (szablon IDK-11)	Zatwierdzenie klienta, porozumienie komercyjne, autoryzacja komitetu sterującego
M: Modyfikacja	Każda zmiana dostarczonej logiki aplikacji lub stron wykraczająca poza konfigurację	Specyfikacja funkcjonalna (szablon IDK-11)	Zatwierdzenie klienta, porozumienie komercyjne, autoryzacja komitetu sterującego

3. Poziomy dostosowania i wpływ na aktualizacje

Użyj tych poziomów w kolumnie „Poziom dostosowania". Dostosuj nazewnictwo do terminów uzgodnionych z partnerem wdrożeniowym.

W trzystopniowej skali używanej na ifs-erp.com: Standard odpowiada poziomowi Level 1 Core, Konfiguracja odpowiada Level 2 Configured, Modyfikacja odpowiada Level 3 Customized. Rozszerzenie interfejsowe nie instaluje niczego w tenancie, więc rdzeń pozostaje na Level 1, ale konsument przejmuje obowiązek ponownej weryfikacji pokazany poniżej.

Poziom	Znaczenie	Typowy wpływ na aktualizacje
Standard	Rozwiązane standardową funkcjonalnością i danymi podstawowymi. Zalogowane tylko, żeby zapisać decyzję.	Brak, poza zwykłymi testami regresji
Konfiguracja	Tworzona w kliencie webowym, przechowywana jako konfiguracja, przenoszona między środowiskami jako pakiety konfiguracji	Niski. Ponowna weryfikacja po każdym release update, zwłaszcza konfiguracji stron i obiektów opartych na konkretnych polach.
Rozszerzenie interfejsowe (opublikowane interfejsy)	Zewnętrzna logika lub integracja korzystająca z projekcji (REST/OData) albo IFS Connect, bez zmiany dostarczonego kodu	Średni. Ponowna weryfikacja użytych projekcji i encji przy każdym release update.
Modyfikacja	Zmieniony lub dodany kod aplikacji, budowany i dostarczany przez Build Place	Wysoki. Musi zostać podniesiony (uplift), przebudowany i przetestowany ponownie przy każdym release update. Ogranicza, jak często klient może aktualizować.

4. Wartości statusu

Status	Znaczenie
Zidentyfikowana	Potrzeba zalogowana podczas warsztatu. Jeszcze bez decyzji.
Przyjęto standard	Alternatywa standardowa zaakceptowana. Wiersz zamknięty na Standard.
Odrzucona	Potrzeba nieprzyjęta. Powód zapisany.
Zatwierdzona do specyfikacji	Podjęto decyzję o kontynuacji. Specyfikacja może się zacząć.
Wyspecyfikowana	Specyfikacja zatwierdzona przez właściwego zatwierdzającego (patrz sekcja 2).
W budowie	Budowa rozpoczęta. Dla I i M zatwierdzenie komercyjne jest na miejscu.
W testach	Dostarczona do środowiska testowego. Zbierane są dowody testów.
Zaakceptowana	Klient zaakceptował obiekt na podstawie dowodów testowych.
Przekazana	Najnowsza specyfikacja funkcjonalna i testowa dostarczona do wsparcia.

5. Rejestr, część A: potrzeba i decyzja

ID	Typ	Obszar rozwiązania i proces	Potrzeba biznesowa	Rozważona alternatywa standardowa (co pokazano, dlaczego nie wystarcza)	Decyzja	Zdecydował, data	Poziom dostosowania	Uwaga o wpływie na aktualizacje
Przykład: CRIM-001	C	Zakupy, od zakupu do przyjęcia	Kupcy potrzebują jednego widoku pozycji zamówień, których dostawca nie potwierdził	Pokazano standardowy przegląd pozycji zamówień zakupu z zapisanym wyszukiwaniem. Działa, ale kupcy chcą liczników i wieku pozycji na stronie startowej.	Zatwierdzono jako lobby	[kierownik projektu po stronie klienta], [YYYY-MM-DD]	Konfiguracja	Źródło danych lobby czyta dane pozycji zamówień zakupu. Ponowna weryfikacja elementów po każdym release update.
Przykład: CRIM-002	M	Zakupy, zatwierdzanie zapotrzebowań	Wnioskodawca poprosił o niestandardowy ekran zatwierdzania jak w systemie legacy	Pokazano standardowe reguły autoryzacji plus lobby zatwierdzającego. Pokrywają w pełni politykę delegowania uprawnień.	Odrzucono, przyjęto standard	[komitet sterujący], [YYYY-MM-DD]	Standard	Brak
Przykład: CRIM-003	I	Magazyn, widoczność zapasu	Sklep internetowy musi pokazywać dostępną ilość na indeks	Przejrzano standardową projekcję dostępności indeksu magazynowego. Nie istnieje standardowy konektor do sklepu internetowego.	Zatwierdzono do specyfikacji, tylko do odczytu	[komitet sterujący], [YYYY-MM-DD]	Rozszerzenie interfejsowe	Ponowna weryfikacja nazw projekcji i entity set przy każdym release update. Patrz rejestr interfejsów [ID].
[ID]	[C/R/I/M]	[obszar, proces]	[potrzeba]	[alternatywa i uzasadnienie]	[decyzja]	[imię i nazwisko, data]	[Standard / Konfiguracja / Rozszerzenie interfejsowe / Modyfikacja]	[uwaga]

6. Rejestr, część B: dostawa i przekazanie

ID	Link do specyfikacji i wersja	Wycena i zatwierdzenie komercyjne (I i M)	Wykonawca	Status	Dowód testowy (skrypt, wynik, tester, data)	Zaakceptował, data	Status przekazania
Przykład: CRIM-001	[link], v1.0	Nie dotyczy	[analityk techniczny klienta]	Zaakceptowana	Skrypt SAT [ID], zaliczony, [tester], [YYYY-MM-DD]	[właściciel procesu], [YYYY-MM-DD]	Specyfikacja i przypadek testowy dostarczone do wsparcia dnia [YYYY-MM-DD]
Przykład: CRIM-003	[link], v1.2	Wycena `[ustalić w projekcie]`, wniosek o zmianę [ID] zatwierdzony [YYYY-MM-DD]	[deweloper]	W testach	Test integracyjny [ID], otwarty defekt [ID]		Nierozpoczęty
[ID]	[link]	[odniesienie]	[imię i nazwisko]	[status]	[dowód]	[imię i nazwisko, data]	[status]

7. Uprawnienia decyzyjne i kontrola zmian

Sytuacja	Kto przygotowuje	Kto przegląda	Kto decyduje
Nowa potrzeba konfiguracji lub raportu	Zespół funkcjonalny: potrzeba, alternatywy z zaletami i wadami, propozycja	Architekt rozwiązania, kierownik rozwiązania technicznego	Kierownik projektu po stronie klienta
Nowa potrzeba integracji lub modyfikacji	Zespół funkcjonalny: potrzeba, alternatywy z zaletami i wadami, propozycja	Architekci rozwiązania, następnie obaj kierownicy projektu w sprawie kosztu	Sponsor zgadza się przedstawić na komitecie, komitet sterujący autoryzuje albo odrzuca
Zmiana do zatwierdzonej specyfikacji	Autor specyfikacji	Obaj kierownicy projektu	To samo uprawnienie co pierwotne zatwierdzenie, przez pisemny wniosek o zmianę
Potrzeba zgłoszona po Solution Confirmed	Jak wyżej	Jak wyżej	Zawsze przez kontrolę zmian względem linii bazowej zakresu

Zapisz niezgodę na piśmie. W wielu przypadkach spisanie alternatyw na papierze rozstrzyga pytanie, zanim dotrze ono do komitetu sterującego.

8. Podsumowanie dla komitetu sterującego

Typ	Zidentyfikowane	Przyjęto standard lub odrzucono	Zatwierdzone	Wyspecyfikowane	W budowie lub testach	Zaakceptowane	Przekazane
Konfiguracje	[liczba]	[liczba]	[liczba]	[liczba]	[liczba]	[liczba]	[liczba]
Raporty	[liczba]	[liczba]	[liczba]	[liczba]	[liczba]	[liczba]	[liczba]
Integracje	[liczba]	[liczba]	[liczba]	[liczba]	[liczba]	[liczba]	[liczba]
Modyfikacje	[liczba]	[liczba]	[liczba]	[liczba]	[liczba]	[liczba]	[liczba]

Trend od ostatniego komitetu sterującego: [tekst]. Wiersze wymagające dziś decyzji komitetu sterującego: [ID, każdy z jednostronicową kartą decyzyjną].

9. Przegląd wpływu aktualizacji

Uruchamiaj ten przegląd przy planowaniu każdego release update i w lżejszej formie dla service update. Im więcej wierszy na poziomie Rozszerzenie interfejsowe i Modyfikacja rejestr zawiera, tym dłużej trwa ten przegląd i tym rzadziej klient może aktualizować. Powiedz to wprost, gdy proponowany jest nowy wiersz.

Kontrola	Właściciel	Wykonano
Wszystkie wiersze na poziomie Konfiguracja, Rozszerzenie interfejsowe i Modyfikacja wypisane z uwagą o wpływie na aktualizacje	[rola]	[ ]
Notatki do wydania przeczytane pod kątem obiektów, projekcji i stron, od których zależy każdy wiersz	[rola]	[ ]
Przypadki testów regresji z kolumny dowodu testowego zaplanowane w planie testów aktualizacji	[rola]	[ ]
Wiersze modyfikacji: nakład na uplift wyceniony i uzgodniony przed zobowiązaniem się do daty aktualizacji	[rola]	[ ]
Wiersze już niepotrzebne, bo standard teraz pokrywa potrzebę: zaproponowane do wycofania	[rola]	[ ]

10. Checklista przekazania

Wsparcie nie może zweryfikować poprawki bez specyfikacji testowej. Sprawdź każdy zaakceptowany wiersz przed przekazaniem.

Kontrola	Wykonano
Najnowsza zatwierdzona specyfikacja zapisana pod linkiem w części B	[ ]
Specyfikacja testowa z oczekiwanymi wynikami zapisana razem z nią	[ ]
Dokumenty są w języku angielskim	[ ]
Integracje pojawiają się też w rejestrze interfejsów z nazwanym opiekunem poświadczeń	[ ]
Właściciel po starcie produkcyjnym nazwany po stronie klienta	[ ]
Status wiersza ustawiony na „Przekazana" dopiero po spotkaniu przekazania	[ ]

11. Zatwierdzenie

Zatwierdzenie tego rejestru na bramce potwierdza, że lista obiektów CRIM jest kompletna dla fazy i że zapisane decyzje są decyzjami nazwanego uprawnionego. Nie jest to zatwierdzenie poszczególnych specyfikacji.

Bramka	Rola	Imię i nazwisko	Decyzja	Data
Solution Confirmed	Kierownik projektu po stronie klienta	[imię i nazwisko]	[Zatwierdzono / Zatwierdzono z uwagami / Odrzucono]	[YYYY-MM-DD]
Solution Confirmed	Przewodniczący komitetu sterującego	[imię i nazwisko]
Solution Established	Kierownik projektu po stronie klienta	[imię i nazwisko]
Solution Established	Przewodniczący komitetu sterującego	[imię i nazwisko]

Uwagi i warunki: [tekst]

Niezależny szablon zgodny z metodyką wdrożeniową IFS. Nie jest oficjalnym dokumentem IFS. IFS jest zastrzeżonym znakiem towarowym IFS AB.

Marketplace