MRP II w HermesSQL - jak liczy się zapotrzebowanie i zdolności produkcyjne

MRP II odpowiada na pytania planisty: co wytworzyć, z jakich materiałów i kiedy zamówić brakujące pozycje. W wersji z zasobami dochodzi kolejne, czyli czy hala i ludzie to udźwigną. Tekst wyjaśnia mechanizm tych obliczeń: od planu głównego przez strukturę BOM po przeliczanie planu po zmianie danych.

Opisy programu HermesSQL firmy Humansoft w tym serwisie wymieniają wbudowany moduł MRP II oraz planowanie z uwzględnieniem dostępności maszyn i pracowników. Sam algorytm opisujemy jako wiedzę ogólną o systemach ERP. Nie jest to specyfikacja modułu HermesSQL, a nazwy tabel w przykładach są poglądowe.

MRP II w HermesSQL - co obejmuje wbudowany moduł

Moduł MRP II jest w HermesSQL wbudowany, czyli nie stanowi osobnej aplikacji. W takim układzie plan może opierać się na stanach i zamówieniach z tej samej bazy co sprzedaż i magazyn oraz produkcja, bez eksportu danych.

Od MRP do MRP II

Pierwsza metoda, MRP, liczyła wyłącznie zapotrzebowanie na materiały. Wersja MRP II dodała do obliczeń zasoby (maszyny, ludzi) oraz koszty, dzięki czemu plan można sprawdzić pod kątem wykonalności. Różnica jest praktyczna: MRP potrafi wskazać, że surowca zabraknie, ale nie powie, że stanowisko nie zdąży go przerobić.

Dane wspólne z innymi modułami

Zamówienia klientów oraz stany magazynowe i zamówienia do dostawców przychodzą z pozostałych obszarów systemu. Opis HermesSQL wskazuje integrację z magazynem i modułem WMS, a także z zaopatrzeniem. Ogólny przegląd zakresu programu znajduje się na stronie o systemie HermesSQL dla firm. Wynikiem planu są planowane zlecenia i planowane zakupy, które planista zatwierdza.

Plan główny produkcji jako punkt wyjścia

Plan główny (MPS) określa, ile wyrobów końcowych ma powstać w kolejnych okresach. To on uruchamia całą kaskadę obliczeń: dopiero z niego wynika zapotrzebowanie na półprodukty i surowce.

Pozycje planu i horyzont

Plan obejmuje wyroby końcowe i, w razie potrzeby, półprodukty sprzedawane osobno. Horyzont musi być dłuższy niż najdłuższy łączny czas realizacji, inaczej system nie zdąży zaplanować zakupu surowca z długą dostawą. Okresy planistyczne mają zwykle długość tygodnia, ale przy szybkiej produkcji stosuje się dni.

Zamówienia i prognozy w planie głównym

Plan główny składa się z dwóch źródeł: potwierdzonych zamówień oraz prognozy popytu. Zamówienia mają pierwszeństwo, a prognoza uzupełnia okresy, w których zamówień jeszcze brak. Przy przejściu od prognozy do zamówień plan powinien zastępować prognozę, a nie dodawać się do niej, inaczej te same potrzeby zostaną policzone dwukrotnie. Reguła ta ma znaczenie w firmach, w których większość zamówień spływa w ostatnim tygodniu przed terminem.

Okno zamrożone

Najbliższe okresy planu są zamrożone. Automatyczne przeliczenie nie zmienia w nich zleceń, bo na hali trwają już przygotowania. Zmiana w oknie zamrożonym wymaga decyzji planisty, który świadomie przesuwa zlecenie albo zwiększa jego ilość.

Struktura BOM i rozwinięcie zapotrzebowania

Struktura BOM opisuje, z czego składa się wyrób i w jakich ilościach. MRP II rozwija ją poziom po poziomie: zapotrzebowanie na wyrób końcowy zamienia się w zapotrzebowanie na półprodukty, a te na surowce. Sposób zapisu technologii i zamienników opisuje artykuł o technologiach BOM w HermesSQL.

Rozwinięcie rekurencyjne w SQL

Rozwinięcie struktury o zmiennej głębokości najprościej wykonać w SQL Server rekurencyjnym wyrażeniem CTE. Poniższy przykład mnoży ilość na sztukę przez ilość planowaną na każdym poziomie.

-- przykładowy schemat: rozwinięcie struktury BOM do zapotrzebowania brutto
WITH Rozwiniecie AS (
    SELECT s.WyrobId, s.SkladnikId,
           CAST(s.IloscNaSztuke AS decimal(18,4)) AS IloscNaWyrob,
           1 AS Poziom
    FROM dbo.StrukturaBOM AS s
    WHERE s.WyrobId = @WyrobId

    UNION ALL

    SELECT r.WyrobId, s.SkladnikId,
           CAST(r.IloscNaWyrob * s.IloscNaSztuke AS decimal(18,4)),
           r.Poziom + 1
    FROM Rozwiniecie AS r
    JOIN dbo.StrukturaBOM AS s ON s.WyrobId = r.SkladnikId
)
SELECT SkladnikId, Poziom, IloscNaWyrob * @IloscPlan AS ZapotrzebowanieBrutto
FROM Rozwiniecie
OPTION (MAXRECURSION 20);

Klauzula MAXRECURSION chroni przed pętlą w danych, na przykład gdy półprodukt przez pomyłkę zawiera sam siebie. Bez niej błąd w strukturze mógłby zawiesić obliczenia całego planu.

Wskaźniki strat i zamienniki

Ilość na sztukę zwykle zawiera dodatek na straty technologiczne, na przykład na odpad z krojenia. Zamiennik pozwala pokryć zapotrzebowanie innym materiałem, gdy podstawowego brakuje. System musi wiedzieć, w jakiej kolejności je stosować, bo od tego zależy, który surowiec zostanie zarezerwowany.

Zapotrzebowanie brutto i netto

Zapotrzebowanie brutto oznacza ilość potrzebną do wykonania planu, bez oglądania się na magazyn. Zapotrzebowanie netto pokazuje, ile faktycznie trzeba wytworzyć lub kupić po uwzględnieniu zapasów i dostaw w drodze.

Wartości w tabeli są przykładem obliczeniowym, a nie danymi z żadnego wdrożenia. Ta sama zasada działa w SQL: stan dostępny to stan fizyczny pomniejszony o rezerwacje, o czym pisze strona o stanach magazynowych.

-- przykładowe wyliczenie zapotrzebowania netto dla jednego okresu planistycznego
SELECT TowarId,
       CASE WHEN Wynik > 0 THEN Wynik ELSE 0 END AS ZapotrzebowanieNetto
FROM (
    SELECT b.TowarId,
           b.Brutto - s.StanDostepny - ISNULL(d.DostawyPlanowane, 0)
                    + s.ZapasBezpieczenstwa AS Wynik
    FROM dbo.ZapotrzebowanieBrutto AS b
    JOIN dbo.StanDostepny          AS s ON s.TowarId = b.TowarId
    LEFT JOIN dbo.DostawyPlanowane AS d ON d.TowarId = b.TowarId
                                       AND d.Okres   = b.Okres
    WHERE b.Okres = @Okres
) AS x;

Czas realizacji i wyprzedzenie

Zapotrzebowanie netto przesuwa się w czasie o czas realizacji. Jeśli surowiec jest potrzebny w poniedziałek, a dostawca dostarcza go w dziesięć dni, zamówienie musi wyjść ponad dwa tygodnie wcześniej. Dla półproduktów wyprzedzenie równa się czasowi produkcji wraz z oczekiwaniem między operacjami.

Wielkość partii

System może zaokrąglać zapotrzebowanie netto do wielkości partii zakupowej albo produkcyjnej. Partia stała, na przykład paleta lub opakowanie zbiorcze, zwiększa ilość, ale upraszcza zamawianie. Reguła, która minimalizuje koszt, zależy od ceny przezbrojenia i kosztu magazynowania.

Reguła: zapas bezpieczeństwa dodaje się do zapotrzebowania netto raz, a nie na każdym poziomie struktury. Powtórzenie go na każdym poziomie zawyża zamówienia surowców kilkakrotnie.

Przykład obliczeń dla jednego wyrobu

Najłatwiej zrozumieć mechanizm na małym przykładzie. Wyrób końcowy W zawiera dwa półprodukty P, a każdy półprodukt zużywa trzy sztuki surowca S. Zamówienie klienta wynosi sto sztuk wyrobu. Liczby mają charakter wyłącznie poglądowy.

Kolejność obliczeń po poziomach

System liczy od góry struktury w dół, poziom po poziomie. Ten sam składnik może występować na kilku poziomach, na przykład śruba użyta w wyrobie i w półprodukcie. Aby nie liczyć jej wielokrotnie, MRP przypisuje każdej pozycji kod niskiego poziomu, czyli najgłębszy poziom, na którym się pojawia. Zapotrzebowanie na nią sumuje się dopiero po zebraniu wszystkich potrzeb z wyższych poziomów.

Netto po każdym poziomie

Po wyliczeniu brutto dla półproduktu system odejmuje jego stan dostępny i zlecenia w toku. Zapotrzebowanie netto półproduktu przechodzi dalej i dopiero ono generuje zapotrzebowanie na surowiec. Jeżeli w magazynie leży wystarczająco dużo półproduktów, surowiec w ogóle nie trafia do planu zakupów. Z tego powodu niedokładny stan półproduktów wypacza plan zakupów na dole struktury.

Zdolności produkcyjne i kalendarze zasobów

Plan materiałowy może być poprawny rachunkowo i niewykonalny na hali. Dlatego MRP II sprawdza obciążenie stanowisk: zsumowane czasy operacji planowanych zleceń porównuje z dostępnym czasem pracy zasobu w kalendarzu.

Obciążenie stanowisk

Czas operacji wynika z normatywu w technologii i z ilości. Wyliczone obciążenie zestawia się z kalendarzem, w którym zapisano dni pracy i zmiany, a także przerwy. Według opisów HermesSQL planowanie uwzględnia kalendarze zasobów oraz dostępność maszyn i pracowników. Dzięki temu przeciążenie widać jeszcze przed emisją zlecenia.

Wąskie gardło w planie

Zestawienie obciążeń zwykle ujawnia jedno lub dwa stanowiska, które ograniczają przepustowość całej hali. Zlecenia kolejkują się przed nimi, a stanowiska za nimi pracują z przerwami. Rozwiązaniem bywa przeniesienie części operacji na inne stanowisko, praca w dłuższym kalendarzu albo kooperacja zewnętrzna, opisana w artykule o zarządzaniu kooperacją w HermesSQL. Wyliczenie obciążenia pozwala podjąć taką decyzję jeszcze przed uruchomieniem zlecenia.

Planowanie nieskończone i skończone

Planowanie nieskończone zakłada, że zasoby mają nieograniczoną pojemność, więc wykazuje przeciążenia, ale ich nie rozwiązuje. Planowanie skończone rozkłada zlecenia tak, by żadne stanowisko nie przekroczyło dostępnego czasu, kosztem przesunięcia terminów. MRP II zwykle zaczyna od pierwszego, a drugie stosuje się przy harmonogramowaniu szczegółowym, o czym mówi tekst o harmonogramie produkcyjnym.

Przeliczanie planu i komunikaty planisty

Plan starzeje się z każdą zmianą: nowym zamówieniem, spóźnioną dostawą albo awarią. System nie może więc liczyć raz na miesiąc. Metody przeliczania różnią się zakresem i kosztem obliczeń.

Przeliczenie pełne i zmian netto

Przeliczenie pełne kasuje poprzednie zalecenia i liczy plan od początku, zwykle w nocy. Przeliczenie zmian netto obejmuje tylko pozycje, w których zmieniły się dane, więc trwa krócej i można je uruchamiać w ciągu dnia. Takie zadania w SQL Server planuje się przez SQL Agent, a wynik trafia do tabel zaleceń.

Komunikaty o terminach i ilościach

Po przeliczeniu system generuje komunikaty: przyspieszyć zlecenie, opóźnić je, zwiększyć ilość albo je anulować. Planista widzi listę wyjątków zamiast całego planu. Powiadamianie o takich zdarzeniach opisuje strona o powiadomieniach w systemie ERP.

Wersje planu i porównanie z wykonaniem

Każde przeliczenie zmienia zalecenia, więc warto zachowywać zatwierdzone wersje planu. Porównanie wersji z rzeczywistym wykonaniem pokazuje, gdzie prognoza się rozjechała, a gdzie zawiodła dostawa albo hala. Bez historii planista wie tylko, że obecny plan różni się od poprzedniego, ale nie wie dlaczego. Z takich porównań powstają wskaźniki, którymi koryguje się czasy realizacji i wielkości partii w kartotece.

Wyniki MRP II w zleceniach i zakupach

Wynik planowania nie jest jeszcze produkcją ani zamówieniem. Planowane zlecenia i planowane zakupy zamieniają się w dokumenty dopiero po akceptacji planisty.

Planowane zlecenia produkcyjne

Zalecenie produkcji trafia do emisji, czyli tworzenia zlecenia z rozpiską i marszrutą oraz rezerwacją. Szczegóły tego etapu opisuje artykuł o emisji zleceń produkcyjnych. Kolejność zleceń wynika z terminów i z priorytetu zamówienia.

Planowane zakupy materiałowe

Zalecenie zakupu przekłada się na zamówienie do dostawcy z terminem, który uwzględnia czas dostawy. Temat ten rozwija tekst o planowaniu zakupów materiałowych, a rezerwacje i bilans zamówień opisuje strona o bilansie zamówień.

Ograniczenia MRP II i jakość danych

MRP II liczy dokładnie to, co dostanie w danych. Każdy błąd w kartotece wraca w planie w powiększonej postaci.

• Stałe czasy realizacji - system zakłada, że dostawca dostarcza w takim czasie, jaki wpisano w kartotekę, więc rozjazd z rzeczywistością zaburza całą kaskadę terminów.
• Dokładność stanów - zapas policzony na papierze różny od fizycznego generuje zbędne zakupy albo brak surowca.

Kiedy MRP II nie wystarcza

Przy produkcji powtarzalnej, o stabilnym popycie i krótkich cyklach, planowanie z góry bywa cięższe niż sama produkcja. Wtedy stosuje się sterowanie zapasem: stały poziom, po którego przekroczeniu w dół uruchamia się uzupełnienie. Z kolei przy produkcji jednostkowej, z indywidualną strukturą każdego zlecenia, MRP II pełni rolę pomocniczą, a rozwinięcie struktury wykonuje się dla konkretnego zamówienia. Wybór metody zależy od profilu produkcji, a nie od tego, co oferuje system.

Dane, które trzeba utrzymywać

Kartoteka wymaga okresowej weryfikacji czasów dostaw i wielkości partii oraz wskaźników strat. Zestawienia odchyleń kosztów i czasów pokazuje artykuł o systemie MRPII w HermesSQL, w którym opisano m.in. porównania kosztów planowanych z rzeczywistymi. Dane o stanach mogą pochodzić także z zewnętrznego magazynu, a takie połączenia realizuje SoftwareStudio w ramach integracji z ERP.