Szablon: Strategia aktualizacji (Evergreen) (IDK-23)

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

Publikuj kalendarz do: [właściciele procesów, użytkownicy eksperci, właściciele integracji, partner, dostawcy zewnętrzni]. Horyzont kroczący: [uzgodnić w projekcie].

4. Wykorzystywane środowiska

Krok	Środowisko	Miejsce	Zasada
Uplift i przebudowa modyfikacji	[nazwa]	Build Place	[Kto to robi, jak powstają dostawy]
Pierwsze sprawdzenie techniczne	[nazwa]	Use Place	[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
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.

Marketplace