---
title: "Szablon: Księga reguł (IDK-09)"
date: 2026-09-22
description: "Gotowy do użycia szablon IDK-09: Księga reguł 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: Księga reguł (IDK-09)

Szablon IDK-09, wersja 1.0. Faza: Confirm Prototype (aktualizowana podczas Establish Solution).

 ## Jak korzystać z tego szablonu

 
- Stwórz jedną Księgę reguł dla każdego obszaru rozwiązania. Nie łącz obszarów w jeden plik; każdy obszar ma własnego właściciela i własne zatwierdzenie.
- Wypełnij sekcje 1-5 raz dla obszaru. Skopiuj sekcję 6 dla każdego procesu w obszarze.
- Zapisuj każdą decyzję razem z uzasadnieniem stojącym za nią. Decyzja bez powodu zostanie otwarta ponownie później, zwykle w najgorszym momencie.
- Wszystko, czego standardowe rozwiązanie nie pokrywa, trafia do sekcji 6.8 jako kandydat CRIM i jest kopiowane do rejestru CRIM (szablon [Rejestr CRIM (IDK-10)](https://www.ifs-erp.com/pl/dokumentacja-wdrozeniowa/10-rejestr-crim)). Tutaj jest tylko zalogowane, nie specyfikowane.
- Użyj banku pytań w sekcji 7 do przygotowania warsztatów. Usuń go z zatwierdzonej wersji, jeśli wolisz krótszy dokument.
- Zastąp każde pole `[...]`. Usuń wiersze oznaczone `Przykład:` przed zatwierdzeniem.

 | Field | Value |
| --- | --- |
| ID szablonu | IDK-09 |
| Faza | Confirm Prototype (aktualizowana podczas Establish Solution) |
| Właściciel | Lider zespołu funkcjonalnego po stronie klienta, wspierany przez konsultanta aplikacyjnego |
| Zatwierdzający | Właściciel procesu po stronie klienta i kierownik projektu po stronie klienta |
| Bramka kwalifikacyjna | Solution Confirmed |
| Wersja | 1.0 |

 ## Spis treści

 
- [Kontrola dokumentu](#kontrola-dokumentu)
- [1. Struktura spółek i struktura prawna](#1-struktura-sp-ek-i-struktura-prawna)
- [2. Lokalizacje](#2-lokalizacje)
- [3. Model sterowania finansowego](#3-model-sterowania-finansowego)
- [4. Model sterowania operacyjnego](#4-model-sterowania-operacyjnego)
- [5. Zasady przewodnie](#5-zasady-przewodnie)
- [6. Proces: [nazwa procesu, np. Od zakupu do przyjęcia]](#6-proces-nazwa-procesu-np-od-zakupu-do-przyj-cia)
- [7. Bank pytań do warsztatów](#7-bank-pyta-do-warsztat-w)
- [8. Zatwierdzenie](#8-zatwierdzenie)

 ## Kontrola dokumentu

 | Pole | Wartość |
| --- | --- |
| Projekt | [nazwa projektu] |
| Obszar rozwiązania | [obszar rozwiązania] |
| Właściciel dokumentu | [imię i nazwisko, rola] |
| Właściciel procesu po stronie klienta | [imię i nazwisko] |
| Konsultant aplikacyjny | [imię i nazwisko] |
| Status | [Szkic / W przeglądzie / Zatwierdzony / Zaktualizowany po warsztatach rozwiązania] |
| Lokalizacja przechowywania | [link] |

 | Wersja | Data | Autor | Zmiana | Zatwierdził |
| --- | --- | --- | --- | --- |
| 0.1 | [YYYY-MM-DD] | [imię i nazwisko] | Pierwszy szkic po warsztacie [odniesienie] |   |
| [x.y] | [YYYY-MM-DD] | [imię i nazwisko] | [zmiana] | [imię i nazwisko] |

 ## 1. Struktura spółek i struktura prawna

 Opisz podmioty prawne, które będą działać w IFS Cloud, i ich wzajemne relacje. Trzymaj się faktów. Ta sekcja napędza konfigurację spółek, przepływy międzyspółkowe i obsługę podatkową.

 | ID spółki | Podmiot prawny | Kraj | Waluta księgowa | Rola w grupie | Handluje z innymi spółkami grupy | Uwagi |
| --- | --- | --- | --- | --- | --- | --- |
| Przykład: 10 | [Spółka handlowa macierzysta] | [kraj] | [waluta] | Kupuje, magazynuje i sprzedaje wyroby gotowe | Tak, sprzedaje do spółki 20 | Rejestracja podatkowa tylko w jednym kraju |
| [ID] | [nazwa] | [kraj] | [waluta] | [rola] | [tak/nie, z kim] | [uwagi] |

 Otwarte kwestie dotyczące struktury prawnej: [lista albo „brak"].

 ## 2. Lokalizacje

 Lokalizacja w IFS Cloud należy do jednej spółki i ma własny zapas, planowanie i kalendarze. Decyduj o lokalizacjach na podstawach operacyjnych, nie na podstawie tego, jak był zorganizowany system legacy.

 | Lokalizacja | Spółka | Typ | Miejsce | Procesy realizowane w tej lokalizacji | Kalendarz dystrybucji lub produkcji | Uwagi |
| --- | --- | --- | --- | --- | --- | --- |
| Przykład: S01 | 10 | Magazyn centralny | [miasto] | Zakupy, przyjęcie, składowanie, kompletacja, wysyłka | [ID kalendarza] | Zaopatruje inne lokalizacje przez uzupełnienie wewnętrzne |
| [lokalizacja] | [spółka] | [typ] | [miejsce] | [procesy] | [kalendarz] | [uwagi] |

 Decyzja o strukturze lokalizacji i jej uzasadnienie: [tekst].

 ## 3. Model sterowania finansowego

 Określ, co zarząd musi widzieć w raportowaniu finansowym i jaka struktura w IFS Cloud to poniesie. Uzgodnij to z finansami przed omawianiem grup indeksów czy grup dostawców, ponieważ od tego zależy kontrola księgowania.

 | Potrzeba sterowania | Kto z niej korzysta | Poniesiona przez (konto, code part, strukturę) | Decyzja | Uzasadnienie |
| --- | --- | --- | --- | --- |
| Przykład: Wydatki zakupowe wg kategorii | Kierownik zakupów, kontroler | Code part zasilany przez kontrolę księgowania z grupy indeksów zakupowych | Grupy indeksów zakupowych odzwierciedlają kategorie wydatków używane w raportowaniu zarządczym | Jedna klasyfikacja służy zarówno kupcom, jak i finansom, bez równoległego mapowania do utrzymania |
| [potrzeba] | [rola] | [struktura] | [decyzja] | [uzasadnienie] |

 Metoda wyceny zapasów i obsługa kosztów: [decyzja i uzasadnienie]. Oczekiwania dotyczące zamknięcia okresu, które dotyczą tego obszaru: [tekst].

 ## 4. Model sterowania operacyjnego

 Opisz, jak biznes steruje podażą, zapasem i obsługą. To jest model operacyjny klienta, w jego własnych słowach.

 | Temat | Jak biznes działa dziś | Jak będzie działać w IFS Cloud | Uzasadnienie |
| --- | --- | --- | --- |
| Przykład: Organizacja zakupów | Każda lokalizacja kupuje dla siebie | Centralni kupcy składają zamówienia dla wszystkich lokalizacji, lokalizacje wywołują i przyjmują dostawy | Lepsze warunki od dostawców i jeden właściciel relacji z każdym dostawcą |
| Przykład: Uzupełnianie zapasu indeksów magazynowych | Ręczny przegląd arkuszy | Metoda planowania na indeks magazynowy, propozycje konwertowane przez kupców | Usuwa ręczny przegląd zapasu, kupcy działają na wyjątkach |
| [temat] | [dziś] | [przyszłość] | [uzasadnienie] |

 Wskaźniki wydajności, którymi obszar będzie sterowany: [lista z właścicielem dla każdego wskaźnika].

 ## 5. Zasady przewodnie

 Zespół funkcjonalny stosuje te zasady do każdej decyzji w sekcji 6. Dostosuj sformułowania, trzymaj listę krótko.

 
1. Najpierw standardowa funkcjonalność. Potrzeba procesowa jest zaspokajana standardowym rozwiązaniem wszędzie tam, gdzie to wykonalne. Wszystko inne staje się kandydatem CRIM i potrzebuje własnego zatwierdzenia.
2. Jeden sposób działania we wszystkich lokalizacjach, chyba że powód prawny lub fizyczny wymaga różnicy. Powód jest zapisywany.
3. Decyzje podejmuje umocowany właściciel procesu podczas warsztatu, nie odkłada się ich do późniejszego komitetu.
4. Dane są wprowadzane raz, u źródła, przez rolę, która jest ich właścicielem.
5. Każda decyzja zapisuje, dlaczego została podjęta i które alternatywy odrzucono.
6. [zasada specyficzna dla projektu]

 ## 6. Proces: [nazwa procesu, np. Od zakupu do przyjęcia]

 Skopiuj całą tę sekcję dla każdego procesu w obszarze rozwiązania. Odwołaj się do modelu procesów w narzędziu Scope Tool: [link lub ID procesu].

 
### 6.1 Cel

 [Jedno lub dwa zdania. Jaki wynik biznesowy dostarcza ten proces i dla kogo?]

 
### 6.2 Wyzwalacz i punkt końcowy

 | Pozycja | Opis |
| --- | --- |
| Wyzwalacz | Przykład: Zwolnione jest zapotrzebowanie zakupowe albo planowanie tworzy propozycję zakupu dla indeksu magazynowego |
| Punkt końcowy | Przykład: Towar jest przyjęty na lokalizację magazynową, a przyjęcie jest dostępne do rozliczenia z fakturą |
| Proces poprzedzający | [proces] |
| Proces następujący | [proces] |

 
### 6.3 Role

 | Rola biznesowa | Odpowiedzialność w tym procesie | Przybliżona grupa użytkowników | Kandydat na permission set |
| --- | --- | --- | --- |
| Przykład: Kupiec | Konwertuje zapotrzebowania i propozycje na zamówienia zakupu, monitoruje potwierdzenia | [grupa] | [nazwa, do zdefiniowania w projekcie bezpieczeństwa] |
| [rola] | [odpowiedzialność] | [grupa] | [kandydat] |

 
### 6.4 Reguły i decyzje

 | ID | Temat | Decyzja | Uzasadnienie | Odrzucone alternatywy | Zdecydował | Data |
| --- | --- | --- | --- | --- | --- | --- |
| Przykład: PUR-D01 | Wykorzystanie zapotrzebowania | Zakupy niemagazynowe zawsze zaczynają się od zapotrzebowania zakupowego. Zakupy magazynowe zaczynają się od propozycji z planowania. | Osoby zatwierdzające mają jedno miejsce do autoryzacji wydatków. Uzupełnianie zapasu pozostaje wolne od ręcznych kroków zatwierdzania. | Zapotrzebowanie na wszystko: odrzucone, spowalnia uzupełnianie bez dodania kontroli | [właściciel procesu] | [YYYY-MM-DD] |
| Przykład: PUR-D02 | Autoryzacja zamówienia | Zamówienia zakupu powyżej `[ustalić w projekcie]` wymagają autoryzacji kierownika zakupów, z wykorzystaniem standardowych reguł autoryzacji | Zgodne z polityką delegowania uprawnień. Nie jest potrzebny niestandardowy ekran zatwierdzania. | Zatwierdzanie e-mailem poza systemem: odrzucone, brak śladu audytowego | [właściciel procesu] | [YYYY-MM-DD] |
| [ID] | [temat] | [decyzja] | [uzasadnienie] | [alternatywy] | [imię i nazwisko] | [YYYY-MM-DD] |

 
### 6.5 Decyzje dotyczące danych podstawowych

 | Obiekt danych podstawowych | Decyzja | Wartości lub konwencja nazewnictwa | Właściciel po starcie produkcyjnym | Uzasadnienie |
| --- | --- | --- | --- | --- |
| Przykład: Grupy indeksów zakupowych | Odzwierciedlają kategorie wydatków z sekcji 3 | [lista lub link] | Kierownik zakupów | Współdzielone z raportowaniem finansowym |
| Przykład: Lokalizacje magazynowe | Struktura magazyn, sektor, rząd, poziom, miejsce składowania odzwierciedla fizyczne etykiety | [konwencja] | Kierownik magazynu | Operatorzy czytają ten sam kod na regale i na ekranie |
| [obiekt] | [decyzja] | [wartości] | [rola] | [uzasadnienie] |

 
### 6.6 Wyjątki

 Rozdziel wyjątki normalne, które zdarzają się regularnie, od wyjątków specyficznych, które są rzadkie, ale muszą działać. Testowanie eskaluje w tej samej kolejności.

 | ID | Wyjątek | Klasa | Jak jest obsługiwany | Rola |
| --- | --- | --- | --- | --- |
| Przykład: PUR-E01 | Dostawca dostarcza więcej niż zamówiono | Normalny | Przyjęcie w ramach tolerancji nadwyżki dostawy z umowy z dostawcą, w przeciwnym razie przyjęcie zamówionej ilości i zwrot reszty | Odbiorca towaru, kupiec |
| [ID] | [wyjątek] | [Normalny / Specyficzny] | [obsługa] | [rola] |

 
### 6.7 Otwarte pytania

 | ID | Pytanie | Właściciel | Potrzebne do | Status | Odpowiedź |
| --- | --- | --- | --- | --- | --- |
| [ID] | [pytanie] | [imię i nazwisko] | [data lub kamień milowy] | [Otwarte / Odpowiedziane] | [odpowiedź i link do decyzji w 6.4] |

 
### 6.8 Kandydaci CRIM

 Zaloguj tylko potrzebę. Specyfikacja następuje później i tylko po decyzji w rejestrze CRIM.

 | Kandydat | Typ (C, R, I, M) | Potrzeba biznesowa | Omówiona alternatywa standardowa | ID rejestru CRIM |
| --- | --- | --- | --- | --- |
| Przykład: Przegląd kupca dla niepotwierdzonych pozycji zamówień | C (lobby) | Kupcy potrzebują jednego widoku pozycji, których dostawca nie potwierdził | Pokazano standardowy przegląd pozycji zamówień zakupu z zapisanym wyszukiwaniem: wykonalne, lobby preferowane do codziennego użytku | [ID] |
| [kandydat] | [typ] | [potrzeba] | [alternatywa] | [ID] |

 
### 6.9 Dane do migracji

 | Obiekt danych | Potrzebny dla tego procesu, ponieważ | Otwarte transakcje lub dane podstawowe | Właściciel | W planie migracji |
| --- | --- | --- | --- | --- |
| Przykład: Dostawca dla indeksu zakupowego | Ceny i czasy realizacji muszą istnieć przed konwersją pierwszej propozycji | Dane podstawowe | Kierownik zakupów | [tak/nie, odniesienie] |
| [obiekt] | [powód] | [typ] | [rola] | [odniesienie] |

 
### 6.10 Potrzebne raporty i informacje

 | Potrzeba informacyjna | Użytkownik | Częstotliwość | Pokryta przez standardową stronę, lobby lub raport | Luka |
| --- | --- | --- | --- | --- |
| Przykład: Otwarte pozycje zamówień zakupu wg obiecanej daty | Kupiec | Codziennie | Standardowa strona przeglądu z zapisanym wyszukiwaniem | Brak |
| [potrzeba] | [rola] | [częstotliwość] | [źródło] | [luka, skopiuj do 6.8, jeśli jest] |

 ## 7. Bank pytań do warsztatów

 Użyj tych pytań do przygotowania warsztatu. To są podpowiedzi, nie lista do odczytania na głos. Po każdej odpowiedzi zapytaj „dlaczego" i zapisz powód.

 
### 7.1 Zakupy

 
1. Kto ma prawo zobowiązywać firmę do wydatku i gdzie to uprawnienie jest zapisane?
2. Które zakupy potrzebują zapotrzebowania i zatwierdzenia, a które powinny płynąć bez niego?
3. Czy zakupy są centralne, lokalne czy mieszane? Kto jest właścicielem każdej relacji z dostawcą?
4. Skąd kupcy dziś wiedzą, że trzeba coś zamówić? Które z tych sygnałów powinien produkować system?
5. Jak uzgadniane są ceny: za zamówienie, listy cen, umowy z datami ważności, progi ilościowe?
6. Jakie waluty i warunki dostawy są w użyciu i kto decyduje o nich dla każdego dostawcy?
7. Jak dostawca potwierdza zamówienie i co się dzieje, gdy nikt nie sprawdza, czy to zrobił?
8. Co robisz, gdy potwierdzona data różni się od żądanej daty?
9. Jak dziś zauważane są opóźnione dostawy i przez kogo?
10. Czy kupujesz indeksy, które nigdy nie trafiają na magazyn, usługi lub operacje podwykonawcze? Czym się różnią?
11. Jak towary są sprawdzane przy przyjęciu? Które indeksy lub dostawcy wymagają inspekcji i kto decyduje?
12. Jakie tolerancje obowiązują dla nadwyżki dostawy, niedoboru dostawy i wcześniejszej dostawy?
13. Jak obsługiwane są zwroty do dostawcy i reklamacje wobec dostawcy oraz ich uznania?
14. Jak faktura dostawcy jest rozliczana: z zamówieniem, z przyjęciem czy z oboma? Kto rozwiązuje różnice?
15. Które klasyfikacje dostawców ktokolwiek faktycznie wykorzystuje w raportowaniu?
16. Czy lokalizacje kupują od siebie nawzajem? Czy to jest zakup, transfer, czy jedno i drugie z perspektywy prawnej?
17. Jakie informacje o dostawcy muszą być kompletne, zanim będzie można złożyć pierwsze zamówienie?
18. Które dokumenty zakupowe trafiają do dostawców, w jakich językach, którym kanałem?

 
### 7.2 Magazyn

 
1. Które indeksy są magazynowane i kto decyduje, że indeks staje się magazynowany?
2. Jak powinna być uzupełniana każda grupa indeksów: punkt zamawiania, planowane z popytu, czy kupowane na zamówienie?
3. Kto jest właścicielem parametrów planowania, takich jak zapas bezpieczeństwa, wielkość partii i czas realizacji, i jak często są przeglądane?
4. Jak magazyn jest fizycznie zorganizowany i czy etykiety lokalizacji odpowiadają temu, co użytkownicy zobaczą na ekranie?
5. Które lokalizacje są do kompletacji, które do składowania masowego, przyjęcia, inspekcji czy kwarantanny?
6. Czy śledzone są partie, serie czy numery seryjne? Od przyjęcia czy tylko przy wydaniu?
7. Czy indeksy mają termin przydatności lub datę ważności? Co się dzieje z zapasem, który wygasa?
8. Jak zapas zablokowany, uszkodzony lub pod inspekcją jest trzymany z dala od planowania i kompletacji?
9. Czy firma trzyma zapas należący do klientów lub dostawców, albo własny zapas u strony trzeciej?
10. Jak towary są przemieszczane między lokalizacjami i między lokalizacjami, i kto potwierdza przemieszczenie?
11. Jak wykonywana jest inwentaryzacja: pełna, cykliczna, czy obie? Kto zatwierdza różnice inwentaryzacyjne?
12. Jakie jednostki miary są używane do magazynowania, zakupów i sprzedaży, i czy przeliczenia są wiarygodne?
13. Jak wyceniany jest zapas i kto w finansach jest właścicielem tej decyzji?
14. Które klasyfikacje indeksów sterują zachowaniem, a które są tylko opisowe?
15. Jaki jest proces tworzenia nowego indeksu i które pola muszą być kompletne, zanim będzie można go kupić lub sprzedać?
16. Jak wycofywane są przestarzałe indeksy i co blokuje ich nowe zakupy?
17. Czy personel magazynu będzie używał urządzeń mobilnych? Do których transakcji?
18. Na które liczby zapasowe patrzy zarząd i jak są zdefiniowane?

 ## 8. Zatwierdzenie

 Zatwierdzając, klient potwierdza, że ten dokument opisuje sposób działania biznesu w obszarze rozwiązania i że decyzje w sekcji 6 mogą być użyte jako podstawa dla prototypu i dla budowy rozwiązania. Późniejsze zmiany przechodzą przez kontrolę zmian projektu.

 | Rola | Imię i nazwisko | Decyzja | Data | Podpis |
| --- | --- | --- | --- | --- |
| Właściciel procesu po stronie klienta | [imię i nazwisko] | [Zatwierdzono / Zatwierdzono z uwagami / Odrzucono] | [YYYY-MM-DD] |   |
| Kierownik projektu po stronie klienta | [imię i nazwisko] |   |   |   |
| Konsultant aplikacyjny (zrecenzowano) | [imię i nazwisko] |   |   |   |
| Architekt rozwiązania (spójność między obszarami) | [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.