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)). 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 oznaczonePrzykł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 |
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.
- 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.
- Jeden sposób działania we wszystkich lokalizacjach, chyba że powód prawny lub fizyczny wymaga różnicy. Powód jest zapisywany.
- Decyzje podejmuje umocowany właściciel procesu podczas warsztatu, nie odkłada się ich do późniejszego komitetu.
- Dane są wprowadzane raz, u źródła, przez rolę, która jest ich właścicielem.
- Każda decyzja zapisuje, dlaczego została podjęta i które alternatywy odrzucono.
- [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
- Kto ma prawo zobowiązywać firmę do wydatku i gdzie to uprawnienie jest zapisane?
- Które zakupy potrzebują zapotrzebowania i zatwierdzenia, a które powinny płynąć bez niego?
- Czy zakupy są centralne, lokalne czy mieszane? Kto jest właścicielem każdej relacji z dostawcą?
- Skąd kupcy dziś wiedzą, że trzeba coś zamówić? Które z tych sygnałów powinien produkować system?
- Jak uzgadniane są ceny: za zamówienie, listy cen, umowy z datami ważności, progi ilościowe?
- Jakie waluty i warunki dostawy są w użyciu i kto decyduje o nich dla każdego dostawcy?
- Jak dostawca potwierdza zamówienie i co się dzieje, gdy nikt nie sprawdza, czy to zrobił?
- Co robisz, gdy potwierdzona data różni się od żądanej daty?
- Jak dziś zauważane są opóźnione dostawy i przez kogo?
- Czy kupujesz indeksy, które nigdy nie trafiają na magazyn, usługi lub operacje podwykonawcze? Czym się różnią?
- Jak towary są sprawdzane przy przyjęciu? Które indeksy lub dostawcy wymagają inspekcji i kto decyduje?
- Jakie tolerancje obowiązują dla nadwyżki dostawy, niedoboru dostawy i wcześniejszej dostawy?
- Jak obsługiwane są zwroty do dostawcy i reklamacje wobec dostawcy oraz ich uznania?
- Jak faktura dostawcy jest rozliczana: z zamówieniem, z przyjęciem czy z oboma? Kto rozwiązuje różnice?
- Które klasyfikacje dostawców ktokolwiek faktycznie wykorzystuje w raportowaniu?
- Czy lokalizacje kupują od siebie nawzajem? Czy to jest zakup, transfer, czy jedno i drugie z perspektywy prawnej?
- Jakie informacje o dostawcy muszą być kompletne, zanim będzie można złożyć pierwsze zamówienie?
- Które dokumenty zakupowe trafiają do dostawców, w jakich językach, którym kanałem?
7.2 Magazyn
- Które indeksy są magazynowane i kto decyduje, że indeks staje się magazynowany?
- Jak powinna być uzupełniana każda grupa indeksów: punkt zamawiania, planowane z popytu, czy kupowane na zamówienie?
- 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?
- Jak magazyn jest fizycznie zorganizowany i czy etykiety lokalizacji odpowiadają temu, co użytkownicy zobaczą na ekranie?
- Które lokalizacje są do kompletacji, które do składowania masowego, przyjęcia, inspekcji czy kwarantanny?
- Czy śledzone są partie, serie czy numery seryjne? Od przyjęcia czy tylko przy wydaniu?
- Czy indeksy mają termin przydatności lub datę ważności? Co się dzieje z zapasem, który wygasa?
- Jak zapas zablokowany, uszkodzony lub pod inspekcją jest trzymany z dala od planowania i kompletacji?
- Czy firma trzyma zapas należący do klientów lub dostawców, albo własny zapas u strony trzeciej?
- Jak towary są przemieszczane między lokalizacjami i między lokalizacjami, i kto potwierdza przemieszczenie?
- Jak wykonywana jest inwentaryzacja: pełna, cykliczna, czy obie? Kto zatwierdza różnice inwentaryzacyjne?
- Jakie jednostki miary są używane do magazynowania, zakupów i sprzedaży, i czy przeliczenia są wiarygodne?
- Jak wyceniany jest zapas i kto w finansach jest właścicielem tej decyzji?
- Które klasyfikacje indeksów sterują zachowaniem, a które są tylko opisowe?
- Jaki jest proces tworzenia nowego indeksu i które pola muszą być kompletne, zanim będzie można go kupić lub sprzedać?
- Jak wycofywane są przestarzałe indeksy i co blokuje ich nowe zakupy?
- Czy personel magazynu będzie używał urządzeń mobilnych? Do których transakcji?
- 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.
Deutsch (Deutschland)
English (United Kingdom) 