Marketplace

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:

  1. Opisz potrzebę biznesową, nie wymarzone rozwiązanie.
  2. Pokaż wnioskodawcy standardową funkcjonalność w systemie. Zapisz, co zostało pokazane.
  3. Zapisz, dlaczego standard nie wystarcza, słowami wnioskodawcy i z konsekwencją dla biznesu.
  4. Dopiero wtedy zaproponuj obiekt CRIM, na najniższym poziomie dostosowania, który zaspokaja potrzebę.
  5. 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 Podpis
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.