---
title: "Szablon: Rejestr CRIM (IDK-10)"
date: 2026-09-22
description: "Gotowy do użycia szablon IDK-10: Rejestr CRIM dla projektów wdrożeniowych IFS Cloud, zgodny z metodyką wdrożeniową IFS."
author: "Dariusz Mysliwiec"
categories:
  - name: "Zestaw dokumentów wdrożeniowych"
    url: "https://www.ifs-erp.com/zestaw-dokumentow-wdrozeniowych.md"
---

# 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.

 | 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 |

 ## Spis treści

 
- [Kontrola dokumentu](#kontrola-dokumentu)
- [1. Cel i zasada „najpierw standard"](#1-cel-i-zasada-najpierw-standard)
- [2. Definicje typów](#2-definicje-typ-w)
- [3. Poziomy dostosowania i wpływ na aktualizacje](#3-poziomy-dostosowania-i-wp-yw-na-aktualizacje)
- [4. Wartości statusu](#4-warto-ci-statusu)
- [5. Rejestr, część A: potrzeba i decyzja](#5-rejestr-cz-a-potrzeba-i-decyzja)
- [6. Rejestr, część B: dostawa i przekazanie](#6-rejestr-cz-b-dostawa-i-przekazanie)
- [7. Uprawnienia decyzyjne i kontrola zmian](#7-uprawnienia-decyzyjne-i-kontrola-zmian)
- [8. Podsumowanie dla komitetu sterującego](#8-podsumowanie-dla-komitetu-steruj-cego)
- [9. Przegląd wpływu aktualizacji](#9-przegl-d-wp-ywu-aktualizacji)
- [10. Checklista przekazania](#10-checklista-przekazania)
- [11. Zatwierdzenie](#11-zatwierdzenie)

 ## 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](https://www.ifs-erp.com/pl/dokumentacja-wdrozeniowa/12-specyfikacja-konfiguracji-i-raportu)) | 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](https://www.ifs-erp.com/pl/dokumentacja-wdrozeniowa/12-specyfikacja-konfiguracji-i-raportu)) | 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](https://www.ifs-erp.com/pl/dokumentacja-wdrozeniowa/13-rejestr-interfejsow)) | Specyfikacja funkcjonalna (szablon [IDK-11](https://www.ifs-erp.com/pl/dokumentacja-wdrozeniowa/11-specyfikacja-funkcjonalna-integracji-lub-modyfikacji)) | 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](https://www.ifs-erp.com/pl/dokumentacja-wdrozeniowa/11-specyfikacja-funkcjonalna-integracji-lub-modyfikacji)) | 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.