Kłopotliwa terminologia

Literatura stosuje kilka podobnych pojęć, które należy odpowiednio uporządkować przed rozpoczęciem dalszych rozważań.

Master Schedule – Harmonogram główny, tabela przedstawiająca dla kluczowych indeksów w podziale czasowym: prognozy sprzedaży, niezrealizowane zamówienia (backlog), prognozowany stan zapasu (PAB), wielkości ATP, wiersz MPS i ew. inne dodatkowe informacje.

Master Production Schedule (MPS) – Harmonogram główny produkcji, jeden wiersz z harmonogramu głównego (Master Schedule) opisujący oczekiwaną wielkość spływu produkcji danej pozycji. W przeszłości tym samym pojęciem określano także całą tabelę Harmonogramu głównego. Od kilku lat APICS stara się rozdzielić te pojęcia stosując określenie MPS jedynie w odniesieniu do wiersza w harmonogramie głównym.

Master Scheduler – Planista główny odpowiedzialny za opracowanie harmonogramu głównego. W swojej pracy powinien posiadać odpowiednie wsparcie systemu ERP. Współpracuje on od strony planów taktycznych z komitetem SOP oraz od strony realizacji produkcji z planistami MRP.

Master Scheduling – Proces ustalania harmonogramu głównego i jego wykorzystywania w obsłudze zamówień sprzedaży.

Pozostałe terminy są wyjaśniane na bieżąco w treści artykułu.

W praktyce ostatnio coraz częściej przyjmuje się, że utarte anglojęzyczne skróty (np. MRP, MPS, ATP) nie są tłumaczone na język polski. Zasada ta jest także utrzymana w tym artykule.

Cele Harmonogramu głównego

1. Stworzenie harmonogramu na konkretne kluczowe indeksy. Są to zwykle wyroby końcowe (w produkcji na zapas – Make-to-stock), główne moduły (w montażu na zamówienie – Assemble-to-order) lub główne materiały (w produkcji na zamówienie – Make-to-order). Harmonogram na konkretne indeksy, to podstawowa różnica w relacji do nadrzędnego planu SOP, który dotyczy grup asortymentowych. Dodatkowo harmonogram główny jest odnoszony do mniejszych przedziałów czasu: dni lub tygodni, podczas gdy SOP jest zawsze opracowywany w okresach miesięcznych.

2. Zabezpieczenie materiałowe dla harmonogramu montażu końcowego FAS tworzonego w firmach o typach produkcji ATO oraz MTO. Montaż końcowy jest realizowany w oparciu o konkretne zamówienia klientów. Aby mógł zostać zrealizowany w akceptowalnym przez klienta czasie dostawy (delivery lead time), to odpowiednie komponenty i materiały muszą już być wcześniej przygotowane, za co odpowiada harmonogram MPS

3. Podstawowe źródło danych do obliczeń MRP. W oparciu o MPS (wiersz z harmonogramu głównego) powstają potrzeby brutto w MRP, które dalej są rozwijane w oparciu o strukturę konstrukcyjną (Bill of material).

4. Źródło danych do utworzenia zgrubnego bilansu zdolności produkcyjnych – Rough Cut Capacity Plan, w skrócie RCCP. Bilans ten umożliwia ocenę, czy plan MPS jest realny. Jego tworzenie jest elementem Master Scheduling (procesu powstawania MPS).

5. Podstawa do analizy możliwości przyjęcia zamówienia (ATP – Available to promise). Wskaźnik ATP bazujący na planowanym spływie produkcji (MPS) i przyjętych już zamówieniach odpowiada na pytanie ile jeszcze można obiecać klientom przyjmując nowe zamówienia. Czasem stosuje się także wskaźnik CTP (Capable to Promise).

Powiązanie z SOP

W firmach, w których używa się planu SOP, Harmonogram główny (Master Schedule) jest tworzony na podstawie Planu produkcji (Production Plan) będącego elementem SOP lub przynajmniej kontrolowana jest zgodność Harmonogramu głównego z SOP. Ponieważ plan SOP został zatwierdzony przez naczelne kierownictwo (ściślej mówiąc – komitet SOP) i przy jego tworzeniu zostały uwzględnione także możliwości działów sprzedaży, dostępność środków finansowych, ograniczenia strategicznych zasobów oraz różne inne kluczowe aspekty dla funkcjonowania przedsiębiorstwa, to planista główny (Master Scheduler) jest zobowiązany zrealizować Plan produkcji z SOP. Dlatego jakiekolwiek zmiany w Harmonogramie głównym, które skutkowałyby jego rozbieżnością w stosunku do SOP musi uzgadniać z kierownictwem.

Poniżej przedstawione jest przykładowe powiązanie Planu produkcyjnego/SOP z MPS/Harmonogramem głównym w przedsiębiorstwie o typie produkcji MTS.

Harmonogram główny jest więc rozbiciem ilości zawartych w SOP na poszczególne wyroby końcowe na postawie procentowych udziałów wyrażonych w strukturze planistycznej (Planning BOM) oraz danych miesięcznych na okresy tygodniowe lub dzienne. Przy okresach tygodniowych rozbicie musi nastąpić proporcjonalnie do ilości dni roboczych w każdym tygodniu.

Planista główny może – uwzględniając różne aspekty procesu produkcyjnego – dokonać zmian w tak utworzonym MPS, ale tylko pod warunkiem, że ostateczna suma będzie zgodna z ilością wyrażoną w SOP.

W środowiskach produkcyjnych typu ATO i MTO rozbicie ilości także następuje z użyciem struktury planistycznej, ale sięga ono poziomu poszczególnych modułów lub opcji. Wówczas kontrola ewentualnych zmian w wygenerowanym MPS jest trudniejsza.

Cele dla planisty głównego

Planista główny stoi w obliczu trzech sprzecznych celów: obniżania zapasów, zwiększania poziomu obsługi klienta i poprawiania wydajności produkcji.

Zwykle obniżenie zapasów powoduje obniżenie poziomu obsługi klienta (bo częściej zdarzają się sytuacje, że nie ma tego, czego akurat klient oczekuje) albo obniżenie wydajności (bo musimy produkować w krótszych seriach).

Z kolei zwiększanie wydajności produkcji powoduje konieczność produkowania w długich seriach i stosowania sekwencji wyrobów zmniejszającej ilość przezbrojeń. Jest to wygodne dla wydziałów produkcyjnych, ale skutkuje wzrostem zapasów i obniżeniem poziomu obsługi klienta, bo częściej zdarza się, że nie mamy akurat tego, czego klient oczekuje.

Aby osiągnąć niski poziom zapasów, to konieczne staje się produkowanie w krótkich seriach (słaba wydajność), w przeciwnym wypadku narazimy się na braki w stanach i niski poziom obsługi klienta.

Sposobem na pogodzenie tego konfliktu jest ustalenie sztywnych zasad odnośnie dwu celów i oczekiwanie maksymalizacji trzeciego. W praktyce zwykle wygląda to tak: Planista główny ma zrealizować nast. cele:

• Utrzymanie pożądanego poziomu obsługi klienta, np. 97% – towary z grupy A, 95% – towary z grup B i C
• Utrzymanie przyjętego poziomu zapasów, np. zapasy dla każdego indeksu powinny być w przedziale między 15 – 23 tys. sztuk. Limit ten może także być ujęty wartościowo.
• Optymalne wykorzystanie zasobów i stabilizacja procesów. Stabilizacja jest ważna z punktu widzenia planowania MRP, którego celem jest nadążanie za zmianami w MPS. Jednak realizacja MRP nie byłaby możliwa, gdyby MPS zmieniał się zbyt często i zbyt mocno.

Dane wejściowe do harmonogramu głównego

• Plan produkcji z SOP. Plan SOP nie zawsze funkcjonuje w systemie ERP, jednak na pewno harmonogram główny musi mieć swoje miejsce w systemie informatycznym.
• Struktura planistyczna (Planning BOM). Musi być to osobna struktura od standardowej struktury konstrukcyjnej (zwykłego BOM).
• Szczegółowe prognozy. Szczegółowe prognozy można także utworzyć na podstawie prognoz z SOP z wykorzystaniem struktury planistycznej. Jednak lepiej jeśli każda z pozycji objętych harmonogramem głównym przejdzie osobną analizę i zostanie utworzona niezależnie.
• Bieżący poziom zapasów (z systemu ERP) i pożądany stan docelowy wynikający z np. przyjętej strategii wyrównywania produkcji (level production) przy popycie sezonowym.
• Aktualna produkcja i zamówienia zakupu w toku.
• Ograniczenia kluczowych zasobów (wąskich gardeł): zdolności produkcyjnych, zasobów ludzkich, narzędzi, budżetowe (do analizy RCCP).
• Niezrealizowane zamówienia (backlog) i pożądany stan docelowy.
• Polityka dotycząca granic czasowych, zwłaszcza określenie granicy popytu (DTF) i planowania (PTF)
• Dodatkowe źródła popytu:
  • - Zamówienia wewnętrzne (interplant) i korporacyjne (intraplant)
  • - Zamówienia dla serwisu i ich prognozy
  • - Zapotrzebowanie dla centrów dystrybucyjnych
  • - Zapotrzebowanie dla działów badań i rozwoju, do testów kontroli jakości itp.
  • - Inne…

Etapy tworzenia MPS

MPS, to wiersz w harmonogramie głównym przedstawiający oczekiwany spływ produkcji z wydziałów produkcyjnych do magazynów. Wyróżnia się cztery etapy jego tworzenia.

Pierwsza propozycja MPS może być prostym wynikiem jego wygenerowania na podstawie np. SOP z wykorzystaniem struktury planistycznej (planning BOM). Następnie planista główny wykonuje zgrubne planowanie zdolności (RCCP) i stara się zniwelować różnice, czyli wprowadzić w MPS takie zmiany, które zlikwidowałyby ewentualne przeciążenia lub nierówną pracę stanowisk. Jednakże musi uwzględnić także inne ograniczenia: prognozowany stan zapasu nie może spadać poniżej zapasu bezpieczeństwa, polityka dot. stref czasowych może mu ograniczać możliwości dokonywania zmian w strefie zamrożonej, zakładane docelowe poziomy zapasów muszą zostać osiągnięte itd. Po wprowadzeniu zmian ponownie jest wykonywane RCCP. Proces jest powtarzany tak długo, aż plan będzie spełniał wszystkie oczekiwania; powstaje wtedy docelowy MPS.

Podstawowa tabela Harmonogramu głównego

Jeden harmonogram główny obejmuje wiele tabel z danymi dla poszczególnych indeksów. Tak więc każda tabela harmonogramu głównego dotyczy konkretnego indeksu. Do obliczeń wykorzystywane są dodatkowe parametry planistyczne wykorzystywane w przetwarzaniu danych: Metoda partiowania (np. FOQ – Fixed Order Quantity), wielkość partii albo okres partiowania (zależnie od przyjętej metody), poziom zapasu bezpieczeństwa (SS – Safety Stock) albo metoda jego ustalania (np. Days of Supply), aktualny stan magazynowy, informacje o przynależności do grupy asortymentowej lub klasy indeksów, dla której zostały określone parametry polityki granic czasowych: granicy popytu (DTF – Demand Time Fence), granicy planowania (PTF – Planning Time Fence) i horyzontu planowania (PH – Planning Horizon).

Tabela zawiera kolumny będące kolejnymi okresami (dniami lub tygodniami). W akademickich prezentacjach często operuje się na numerach okresów, jednak w praktyce stosuje się konkretne daty lub numery tygodni. W podanym poniżej przykładzie pominięto soboty i niedziele (2. i 3. sierpień).

Podstawowymi wierszami są: prognoza popytu zewnętrznego (lub prognoza sprzedaży), sumaryczna ilość z niezrealizowanych pozycji zamówień klientów z terminem realizacji na określony dzień, prognozowany stan zapasu na koniec każdego okresu (PAB – Projected Available Balance) i Harmonogram główny produkcji (MPS).

Na harmonogramie powinny zostać wyszczególnione wyraźnie podziały stref: DTF i PTF.
Niektóre systemy ERP przedstawiają harmonogram główny w sposób wertykalny, w której okresy są prezentowane w wierszach. Wynika to możliwości narzędziowych tych systemów, gdyż wówczas jest sztywno określona liczba kolumn, nieokreślona jest ilość wierszy. Układ wertykalny jest też przyjętym standardem dla rozmaitych formularzy w systemach informatycznych. Nie zmienia to w żaden sposób filozofii obliczeń.

Prognozowany stan zapasu (PAB)

Prognozowany stan zapasu jest inaczej wyliczany w okresach do DTF, a inaczej po tym terminie:

Dla pierwszego okresu: PAB(1) = Stan magazynowy + MPS(1) – Zam.(1)

Dla kolejnych okresów do DTF: PAB(n) = PAB(n-1) + MPS(n) – Zam.(n)

Dla okresów po DTF: PAB(n) = PAB(n-1) + MPS(n) – max[Progn.(n), Zam.(n)]

Jednym z podstawowych zadań planisty głównego jest zapewnienie, by PAB nie spadał poniżej ustalonego poziomu zapasu bezpieczeństwa (SS – Safety Stock). Ograniczenie to nie dotyczy okresu zamrożonego (do PAB); wówczas dopuszcza się, by PAB spadał poniżej SS (w końcu po to jest zapas bezpieczeństwa, by w szczególnych przypadkach móc z niego skorzystać).

Aby ułatwić planiście głównemu szybkie zorientowanie się o niewłaściwym poziomie PAB niektóre systemy wyświetlają w osobnym wierszu również potrzeby netto (net requirements). Wypełniane są one tylko w tedy, gdy PAB spada poniżej SS (lub poniżej zera w okresie zamrożonym) i przedstawiają brakującą różnicę.

Strefy czasowe

Podział na strefy czasowe (time fences) oznacza dużo więcej, niż tylko inny sposób wyliczania PAB i potrzeb netto. Jest to głównie inne podejście biznesowe do potencjalnych zmian.

Strefy czasowe są ustalane dla poszczególnych rodzin wyrobów i zawierają określoną przez zarząd politykę dotyczącą sposobu wprowadzania zmian w MPS. W idealnej sytuacji zmiany powinny być wprowadzane jedynie w okresach poza PTF. W praktyce jednak bardzo często zdarzają się one w okresie elastycznym (między DTF i PTF), czyli krótszym niż całkowity czas wytwarzania, co powoduje konieczność przyśpieszonych dostaw i dodatkowych przezbrojeń.

Zmiany w okresie zamrożonym zasadniczo w ogóle nie powinny mieć miejsca. Przypominają one gaszenie pożarów i często niosą poważne konsekwencje. Aby im zapobiec wprowadza się dodatkowy wymóg, by zmiany te wymagały akceptacji zarządu; nie jest to wynikiem braku zaufania do planisty głównego, ale sposobem na ochronienie jego (i procesu produkcyjnego) przed różnymi naciskami z innych działów.

Wielopoziomowy MPS

Z wielopoziomowym MPS (Multi-level MPS) mamy do czynienia, gdy półprodukt będący składnikiem wyrobu finalnego jest sprzedawany jako niezależny wyrób.

W przypadku półproduktu, który stanowi zarówno samodzielny wyrób finalny, jak i składnik innego wyrobu pojawiają się dwa różne źródła popytu: popyt niezależny (prognozy sprzedaży i zamówienia) oraz popyt zależny (z MRP). Taki półprodukt też powinien być ujęty w harmonogramie głównym, jednakże w tym przypadku wprowadza się to w osobnym wierszu.

W praktyce może być więcej powodów, dla których półprodukt jest planowany w harmonogramie głównym. Przykładowo w przedsiębiorstwie mogą funkcjonować dwie niezależne fabryki: jedna wytwarzająca komponenty, a druga – montująca wyrób finalny. Każda fabryka musi mieć harmonogram główny, który gwarantowałby jej stabilność i efektywność produkcji oraz odpowiedni poziom zapasów, jednakże stosowanie w takim przypadku całkiem osobnych harmonogramów głównych, w którym zapotrzebowanie na komponenty jest wprowadzane jako zamówienia do harmonogramu głównego komponentów – co czasem ma miejsce – napotyka na problemy, gdy obie fabryki stosują te same materiały (jak np. materiał 2 na powyższym przykładzie). Wówczas zapotrzebowanie na ten sam materiał ma dwa niezależne źródła. Dlatego optymalnym rozwiązaniem jest zastosowanie wielopoziomowego MPS.

W dodatkowym wierszu harmonogramu głównego poza danymi o popycie zależnym mogą znaleźć się także informacje o innych dodatkowych źródłach popytu: zapotrzebowanie dla centrów dystrybucyjnych (z DRP – Distribution Resource Planning), dla serwisu, dla komórek badawczo – rozwojowych itp. Ważne, aby znalazły się tu informacje o wszystkich dodatkowych źródłach. W przeciwnym wypadku może dochodzić do sytuacji, w której np. dział serwisu będzie podbierał materiały i komponenty produkcji, co może później skutkować niemożliwością realizacji harmonogramu głównego.

Podejścia do planowania nadrzędnego

Wyszczególnia się trzy możliwe podejścia do planowania nadrzędnego

Produkcja typu A jest charakterystyczna dla sytuacji, gdy mamy ograniczoną liczbę wyrobów finalnych przy jednocześnie dużej ilości możliwych materiałów. Spotykamy się z tym najczęściej przy produkcji na zapas (MTO).  W tym przypadku harmonogramy SOP i MPS są tworzone na najwyższym poziomie i nie występuje harmonogram montażu końcowego (FAS – Final assembly schedule). Może za to występować rozbudowana sieć dystrybucyjna planowana przy użyciu DRP (Distribution Resource Planning).

Produkcja typu X występuje wtedy, gdy istnieje szeroka gama oferowanych wyrobów lub opcji montażowych przy jednocześnie ograniczonej ilości kluczowych uniwersalnych półproduktów. Jest to charakterystyczny układ dla montażu na zamówienie (ATO). SOP jest tworzony (jak zawsze) na najwyższym poziomie, zaś harmonogram główny dotyczy kluczowych półproduktów lub opcji. Dodatkowo do planowania montażu końcowego stosuje się FAS.

Produkcja typu V ma miejsce w przypadku, gdy istnieje szeroki asortyment wyrobów przy ograniczonej ilości materiałów. Zwykle ma to miejsce w przypadku produkcji lub konstrukcji na zamówienie (MTO, ETO). Wówczas harmonogram główny dotyczy materiałów.

Dostępne do obiecania (ATP – Available to Promise)

Przyjmowane zamówienia klientów stopniowo konsumują ilości MPS. Różnica między MPS a zamówieniami, to wskaźnik ATP obrazujący ilość, jaką możemy obiecać klientom przyjmując nowe zamówienia.

Wskaźnik ATP występuje w harmonogramie głównym w osobnym wierszu.

Sposób obliczeń „zwykłego” ATP jest następujący:

ATP (okres 1) = Stan mag. + MPS – suma zam. i dod. źródeł do nast. MPS

ATP (okres z MPS) = MPS – suma zam. i dod. źródeł do nast. MPS

ATP nie wypełnia się w okresach, w których nie występuje MPS.

Wadą „zwykłego” ATP jest brak możliwości zaspokojenia potrzeb klienta z różnych spływów produkcji (MPS). Aby temu sprostać wprowadza się tzw. Backward ATP lub Forward ATP

W powyższym przypadku wielkość ATP jest korygowana o wielkości przesunięć Backward/Forward Consumption.

Trzecią metodą jest wyliczanie skumulowanego ATP (Cumulative ATP)

Skumulowane ATP jest wyliczane następująco:

Cumulative ATP(1) = Sta mag. + MPS(1) – Zamówienia(1) – Dod. źródła(1)

Cumulative ATP(n) = ATP(n-1) + MPS(n) – Zamówienia(n) – Dod. źródła(n)

Dzięki skumulowanemu ATP nie jest konieczne korzystanie z Backward ATP, jednakże przesunięcia sposobu zaspokojenia popytu między okresami nie są wyraźnie ujawnione. Ponadto przy przyjmowaniu zamówienia nie wystarczy sprawdzić, czy bieżące ATP nie zostało przekroczone; system informatyczny powinien przeliczyć dla danego indeksu wskaźnik skumulowanego ATP co najmniej w okresie do PTF.

Pełna prezentacja harmonogramu głównego

W pełnej prezentacji harmonogramu głównego mogą występować także wiersze dotyczące dynamicznie zmieniającego się zapasu bezpieczeństwa (SS) oraz docelowych stanów zapasu.

Sposób obliczania dynamicznego zapasu bezpieczeństwa zależy od przyjętego algorytmu. Często jest nim Days of Supply, zwany po polsku „ilość dni pokrycia”, czyli na ile dni powinien wystarczyć zapas bezpieczeństwa biorąc pod uwagę planowany popyt w najbliższych okresach.

Rysunek 1

 Legenda do rysunków

PB    Poterzeby brutto w okresie
PD   Planowane dostawy najpóźniej na początek okresu
SZ    Stan zapasu planowany na koniec okresu
PN    Potrzeby netto w okresie
PP    Planowane przyjęcia najpóźniej na początek okresu
PU    Produkcja (dostawa) w toku

MPS

Harmonogram główny (MPS) przedstawia wielkości oczekiwanego spływu z produkcji dla poszczególnych wyrobów i półproduktów w podziale na poszczególne dni. W naszym przykładzie dla uproszczenia jest tylko jeden wyrób i dwa półprodukty, przy czym popyt dotyczy głównie wyrobu, ale pojawia się także zapotrzebowanie na półprodukt na 20wrz. Zwykle zapotrzebowanie na półprodukty wynika z zamówień serwisu, ale często także półprodukt jest sprzedawany jako niezależny produkt na rynku. Przykładowo: pompa i zestaw pompowy.

Zarówno MPS, jak i wyniki obliczeń MRP są prezentowane w kalendarzu z okresami dziennymi z pominięciem sobót i niedziel.

Obliczenia dla wyrobu

Obliczenia rozpoczynamy dla indeksów najwyżej położonych w strukturze, czyli dla Wyrobu A. (Nigdy system nie rozpoczyna obliczeń dla jakiegoś indeksu, jeśli obliczenia dla indeksów wyżej położonych w strukturze nie zostały zakończone.)

Wykonując obliczenia dla pojedynczego indeksu w pierwszym kroku dokonujemy obliczenia PB. Potrzeby brutto wynikają z MPS oraz z planowanych uruchomień indeksów wyżej położonych w strukturze. W przypadku wyrobu A bierzemy pod uwagę tylko MPS.

Rysunek 2

W kolumnie znajdującej się przed pierwszym okresem kalendarza jest zapisany aktualny stan zapasu indeksu (30szt). Zapas ten jest przepisywany w kolejnych okresach, aż do 6.września. Wartość 30szt w tym dniu oznacza planowany stan zapasu na koniec tego dnia. W kolejnym dniu występują PB, które zużywają część zapasu; pozostaje 5 szt., które następne są przepisywane aż do 13.września.

14. września zapas spadłby poniżej zera. Jest to sygnał dla systemu, by uruchomić produkcję. W tym celu program oblicza PN.

PN(n) = PB(n) – SZ (n-1) – PD(n)

Czyli w naszym przypadku PN(14.wrz) = 20 – 5 – 0 = 15.

Rysunek 3

Wystąpienie dodatnich PN oznacza konieczność uruchomienia produkcji. W tym celu program sprawdza parametry planistyczne. FOQ (stała wielkość partii) wynosi 40 szt. (uruchomienia produkcji powinny być wielokrotnością 40) , zaś LT (czas realizacji) – 2 dni. Dlatego system wstawia wartości 40szt w wierszach PU i PP w okresach odpowiednio 12. i 14. września.

Wielość PP = 40 szt. na 14. września oznacza, że taka ilość ma zostać przyjęta najpóźniej na moment początku okresu. W praktyce ma to zwykle miejsce pod koniec poprzedniego okresu roboczego.

Po zaplanowaniu uruchomienia produkcji należy przeliczyć stan zapasu:

SZ(n) = SZ(n-1) + PD(n) + PP(n) – PB(n)

Czyli SZ(14wrz) = 5 + 0 + 40 – 20 = 25

Rysunek 4

Stan zapasu jest przepisywany dalej do 26. września. Wówczas ponownie pojawiają się PN = 5, które stanowią analogicznie podstawę od uruchomienia produkcji i do obliczenia SZ w tym okresie.

Ponieważ nie ma więcej PB, to przeliczenia dla Wyrobu A zostają zakończone.

Zwykle przy obliczeniach dla PB obowiązuje zasada nie uwzględniania SZ i parametrów dot. wielkości partii. (Inaczej, niż zaprezentowane w przykładzie). Wynika to z założenia, że MPS jest harmonogramem oczekiwanego spływu produkcji i już na jego poziomie zostały wzięte pod uwagę: stan zapasu i wielkości partii. Zamierzeniem planisty MPS może być chęć wcześniejszego zbudowania odpowiedniego stanu zapasu przez sezonem zwiększonego popytu i planiście MRP nie wolno w to ingerować. Ponadto planista MPS przygotowując główny harmonogram produkcji musi być zgodny co do wielkości produkcji z planem SOP ustalonym przez zarząd. Planista MRP dokonując samodzielnie zmian w montażu wyrobów finalnych powoduje, że jego działania odbiegają od przyjętej strategii operacyjnej firmy.

Rysunek 5

Przeliczenia dla Półproduktu 1.

W pierwszej kolejności wykonywane są obliczenia PB. Tutaj potrzebne są informacje o strukturze konstrukcyjnej (BOM) i o planowanych uruchomieniach Wyrobu A (12. i 23. wrz.). Przepisywane są także wielkości z MPS (20. wrz.)

Następnie system przepisuje SZ do 30. sierpnia. W dniu 31sier. jest zaplanowana dostawa PD = 20szt. Jest to już uruchomiona produkcja w trakcie realizacji. Dlatego w tym dniu wzrośnie SZ do 30szt., który dalej będzie przepisywany do 9.wrz. Ten stan zapasu nie wystarczy na zaspokojenie PB, więc – żeby uniknąć ujemnego SZ – pojawiają się PN i uruchomienie produkcji.

Do uruchomienia produkcji system bierze pod uwagę parametry planistyczne. POQ = 2 tyg. oznacza, że wielkość uruchomienia musi wystarczać na zapotrzebowanie na najbliższe 2 tyg. System więc oblicza to następująco:

PN(12.wrz) + PB(od13. do 23.wrz) = 50 + 40 + 80 = 170.

Zgodnie z LT = 4 dni zostaje zaplanowane uruchomienie produkcji, następnie jest przeliczany stan zapasu, który dalej jest przepisywany i stopniowo zużywany wraz z kolejnymi PB, aż schodzi do zera w dniu 23. wrz.

W oparciu o takie przeliczenia dla Połproduktu 1. system wygeneruje komunikat o zalecanym opóźnieniu dostawy 20szt. zaplanowanej na 31.sier. Ona nie jest tak wcześnie potrzebna. Wystarczy, jak zostanie zrealizowane później, najpóźniej do 12.wrz.

Rysunek 6

Obliczenia dla Półproduktu 2.

Potrzeby brutto wynikają tylko z PU Półpr. 1 w okresie 6.wrz. Są one proste do przeliczenia, gdyż ilość z BOM wynosi 1 szt. W tym samym dniu mamy już zaplanowaną dostawę PD 150szt. Wcześniejszy stan zapasu jest zerowy, więc ilość ta nie wystarczy na zaspokojenie PB. Pojawiają się PN = 20.

Do ustalenia wielkości uruchomienia system stosuje metodę LTL – partia na partię, czyli ile trzeba, tyle jest produkowane. Jednak problemem w przypadku tego indeksu jest długi czas dostawy LT = 2 tyg. Niestety czasu na takie uruchomienie nie wystarczy, dlatego wielkość PU jest wpisywana w dodatkowej kolumnie przed pierwszym okresem zwanym Overdue (przeterminowane). W tej samej kolumnie wpisuje się bieżący SZ.

Jest to sytuacja wymagająca szybkiej interwencji planisty MRP. System informatyczny wygeneruje dla niego komunikat zalecający zwiększenie otwartego już zlecenia produkcji z 150 na 170. Zanim planista MRP dokona takiej modyfikacji będzie musiał sprawdzić, czy jest to możliwe. W tym celu może np. skonsultować się z kierownikiem produkcji, zajrzeć do szczegółowego harmonogramu operacji, zaplanować pracę w godzinach nadliczbowych itp. Jeśli zarówno Półpr. 1, jak i Półpr. 2 są wytwarzane na tym samy wydziale, to przy założeniu, że zbyt wczesna produkcja 20 szt. Półpr. 1 zostanie opóźniona, pojawią się najprawdopodobniej wystarczające moce, aby wykonać dodatkowe 20szt. Półpr. 2.

Jednak najważniejsze, co planista MRP musi zrobić, to – przed zwiększeniem otwartego zlecenia – powinien sprawdzić dostępność składników. I tu natrafi na problem, gdyż brakuje materiału… (Problem ten zostanie omówiony nieco dalej.) Jeśli nie uda się zwiększyć otwartego uruchomienia produkcji, to planista może wrócić do Półpr. 1. i rozbić duże uruchomienie produkcji 170 na np. dwa mniejsze: na razie zrobić 90 (pod potrzeby z okresów 12. i 20 wrz.), zaś później osobne uruchomienie pod potrzeby z 23. września.

W skrajnym przypadku, jeśli nie udałoby się planiście MRP dokonać odpowiednich modyfikacji w planie, tak, aby był on możliwy do realizacji, to powinien zwrócić się do planisty MPS z prośbą o zmianę harmonogramu głównego.

Dla Półpr. 2 charakterystyczne jest także występowanie drugiej planowanej dostawy w takiej samej wysokości 150szt w dniu 13.wrz. (co jest trochę dziwne, gdyż oznacza, że zlecenie zostało uruchomione przed określonym czasem LT = 2 tyg.) oraz występowanie tzw. Firm Planned Order, czyli zlecenia przygotowanego przez planistę, choć jeszcze nie uruchomionego, w takiej samej wysokości w okresie od 6. do 20. wrz. Zwykłe uruchomienia produkcji wpisywane w wierszach PU – PP nazywają się Computer Planned Order, ale jeśli planista MRP zacznie je modyfikować lub ręcznie wstawi nowe uruchomienie, to ma ono status Firm Planned Order i jest prezentowane w tych samych wierszach z gwiazdką. Zarówno Firm Planned Orders, jak i Release Orders (dla których prezentowana jest tylko dostawa w osobnym wierszu – PD) nie podlegają komputerowym zmianom w wyniku kolejnych przeliczeń planu MRP.

Przypadek, który widzimy wynika prawdopodobnie ze świadomego działania planisty w poprzednich okresach lub może być przyczyną jego błędu. Tak, czy owak system zasugeruje komunikatem, aby usunąć obydwa zlecenia. Komunikat zalecający usunięcie powinien zawsze zostać przez planistę MRP potraktowany bardzo poważnie (poważniej niż np. komunikat ‘Opóźnij’), gdyż oznacza niebezpieczeństwo postania zapasów typu Obsolete, czyli zbędnych, na które nie ma zapotrzebowania i które potem latami leżą na magazynach, a w końcu zostają wyrzucone, bo do niczego się nie przydają. W naszym przypadku widać wyraźnie, że nie ma potrzeb pod te uruchomienia, więc należy je usunąć.

Rysunek 7

Obliczenia dla materiału.

PB na materiał wynikają zarówno z PU Półpr. 2, jak i z PU Wyrobu A – tak podaje struktura BOM.

Pojawiają się jednak PB na materiał w kolumnie Overdue. Najprawdopodobniej brak tych materiałów w przeszłości spowodował konieczność otwarcia zlecenia na Półpr. 2 w ilości mniejszej (150szt), niż było potrzeba (170szt). Teraz planista MRP otrzymuje alarmowy komunikat wyjątku i musi podjąć decyzję, co z tym zrobić. Może postarać się o natychmiastową dostawę Materiału (samolotem, taksówką). Nie zawsze jest to możliwe. Może więc rozpoznać, czy faktycznie materiał jest potrzebny „na już”. Może wystarczy, jak dojedzie za 2 dni? W końcu czas realizacji Półpr. 2 jest dość długi i kończy się dopiero 6.wrz.

Na razie system informatyczny dokonał przeliczeń PN i zaplanował uruchomienie produkcji (PU i PP) w jednej kolumnie Overdue.

Dokonując przeliczenia dla Materiału należy także zwrócić uwagę na jego specyfikę. Jest on ewidencjonowany w kg, inaczej niż półprodukty i wyroby, które były w szt. Nie przeszkadza to jednak w obliczeniach, gdyż ilości w BOM dla tego materiału są także wyrażone w kg. Ponadto ma on specyficzne parametry planistyczne: MOQ = 50kg oznacza, że minimalna wielkość partii wynosi 50kg, standardowy czas dostawy (LT) trwa 1 tydz. Dodatkowo zostały ustalone SS (zapas bezpieczeństwa) = 20 kg i DTF = 6 dni (granica popytu) wyznaczająca 6-dniowy okres zamrożenia. Okres ten jest istotny z punktu widzenia przeliczania PN, które inaczej są obliczane w okresie zamrożonym, a inaczej poza nim.

W okresie zamrożonym przyjmuje się, że stan zapasu może spadać poniżej poziomu zapasu bezpieczeństwa. W końcu po to jest zapas minimalny, aby w razie potrzeby można było z niego skorzystać. Natomiast poza okresem zamrożonym system przy obliczaniu potrzeb netto bierze pod uwagę także zapas bezpieczeństwa. Z tego powodu pojawiają się PN w dniu 6.wrz., które skutkują PU 30sier. i PP 6wrz. w wysokości odpowiadającej MOQ.

Powstały w ten sposób zapas jest przechowywany do 9. wrz i 12 wrz. pojawiają się kolejne PN przeliczone z uwzględnieniem SS skutkujące kolejnym uruchomieniem produkcji. To uruchomienie nachodzi na poprzednie. W dniu 5wrz. planowana wielkość dostaw w drodze wynosi 100 (połowa na 6., a druga połowa na 12.). Nie powinno te jednak przeszkadzać w ich realizacji. Jeśli jednak problem dotyczyłby wąskiego gardła produkcyjnego mogłoby okazać się konieczne kolejkowanie produkcji i odpowiednie przesunięcie uruchomień.

W dalszych przeliczeniach system stwierdził, że nie ma potrzeby dodatkowego uruchamiania produkcji z powodu PB w dniu 23. wrz, gdyż zapas wystarczy na ich pokrycie i to, co pozostanie nie jest mniejsze od zakładanego SS.

Podsumowanie

Powyższy przykład opisuje wiele istotnych zagadnień z zakresu przeliczeń MRP, ale w praktyce jest tylko małą częścią możliwości systemów informatycznych. Dodatkowo należy uwzględnić takie aspekty jak: współczynniki braków, uwzględnianie maksymalnej wielkości partii, stopniowe PP, bilansowanie mocy produkcyjnych (CRP), kolejkowanie zadań, różne kalendarze pracy poszczególnych stanowisk i kalendarze dostaw, wykorzystanie kooperacji, nietypowe jednostki miary w BOM różne od podstawowych jednostek produkcyjnych i różne od jednostek bazowych w których są przechowywane stany magazynowe skutkujące koniecznością użycia przeliczników jednostek i zaokrągleń, zmiany specyfikacji składników, zamienniki itd.

Typy strategii

Wyróżnia się trzy podstawowe typy strategii: korporacyjna, biznesowa i strategie funkcjonalne, do których należą: finansowa, rozwoju produktu, operacyjna i marketingowa.

 

Strategia korporacyjna i biznesowa

Strategia korporacyjna obejmuje następujące aspekty: wizję (stan docelowy), misję i cele organizacji. Zwykle tworzona jest na bazie analizy otoczenia (Environmental Scanning) i analizy SWOT (Strength, Weakness, Opportunities and Threats Analysis).

Strategia biznesowa jest realizowana w ramach danego przedsiębiorstwa i musi być zgodna z przyjętą strategią korporacyjną. Występują cztery podstawowe podejścia do strategii biznesowej:

1. Przywództwo cenowe – bazuje na standardowych produktach „z półki” wytwarzanych w standardowych procesach, niskich kosztach operacyjnych i efektywnym zarządzaniu łańcuchem dostaw.

2. Dywersyfikacja produktu – obejmuje wiele różnorodnych produktów wytwarzanych w wysokiej jakości na bazie elastycznych procesów produkcyjnych.

3. Koncentracja na konkretnym kliencie – produkty dostosowane do wybranego segmentu rynkowego.

4. Szybka reakcja na potrzeby rynku – ścisła współpraca w całym łańcuchu dostaw w celu zapewnienia natychmiastowej reakcji na zmiany popytu i tworzenie systemów produkcyjnych tak elastycznych, jak tylko to możliwe.

Strategia operacyjna

Strategia operacyjna obejmuje cztery następujące elementy:

1. Metody oceny skutków podejmowanych decyzji. Zależnie od przyjętych metod pracownicy podejmujący decyzje taktyczne i operacyjne w obszarach produkcyjnym i logistycznym będą dostosowywać swoje decyzje w taki sposób, aby jak najlepiej sprostać stawianym im wymaganiom.

2. Definicje wymiarów czasowych takich jak: horyzont planowania i granice stref (time fences): popytu i planistycznej. Strefy mogą być indywidualnie określone dla poszczególnych grup wyrobów. W poszczególnych strefach obowiązują inne zasady wyliczania pewnych wskaźników (PAB, ATP) oraz podejmowania decyzji dotyczących zmian w przyjętych planach produkcji (SOP, MPS i MRP).

3. Mechanizm integracji decyzji dotyczących innych strategii funkcjonalnych.

4. Decyzje o wyborze koncentracji na jednym z nast. obszarów:

a. Koncentracja na procesie – obejmuje szeroki zakres produktów lub usług wytwarzanych w małych ilościach.

b. Koncentracja na produkcie lub usłudze – wąski asortyment produktów lub usług wytwarzanych w dużych ilościach.

c. Koncentracja na kliencie – rozważenie potrzeb klienta od etapu projektowania aż do sprzedaży i opieki po sprzedażowej.

Źle wybrany system będzie stwarzał problemy i koncentrował na sobie uwagę pracowników. Będzie budził negatywne emocje, ograniczał możliwości rozwoju i powodował dodatkowe koszty.

Stojąc przed decyzją o wyborze pakietu ERP, to nie traktujmy tego jako „zadanie dodatkowe”, które trzeba wykonać, ale jako decyzję strategiczną.  Weźmy więc głęboki oddech i spróbujmy dojrzeć to, czego nie ma w stertach ulotek, nawale informacji z Internetu i o czym nie powie nam handlowiec próbujący zawrzeć z nami kontrakt na setki tysięcy złotych.

Niniejszy artykuł wskazuje, na co zwrócić uwagę przy wybieraniu systemu informatycznego, a w szczególności – pakietu klasy ERP.

Architektura i Technologia

Choćby producent wykazywał się licznymi referencjami i nagrodami otrzymanymi w przeszłości za swoje oprogramowanie, to nigdy w pełni nie zaspokoi naszych potrzeb, jeśli nie będzie spełniał podstawowych wymogów dot. architektury. Wcześniej czy później przestarzała technologia będzie powodować problemy z wydajnością i ergonomią. Twórca programu mając małe możliwości programistyczne wkrótce zaprzestanie rozwoju tego produktu i nawet nie będzie chciał go aktualizować o zmiany prawne.

Wybierając pakiet zbudowany w starych narzędziach postępujemy tak, jakbyśmy kupowali nowy samochód w modelu, który po wielu latach od jego wymyślenia właśnie wychodzi z produkcji. Jest on może nieco tańszy, ale nie jest ani ładny ani dość funkcjonalny, ani bezpieczny. Niedługo nam posłuży, zaś producent już po paru latach nie będzie dostarczał do niego części zamiennych.

Aby nasz nowy pakiet ERP służył długie lata, konieczne jest by:

1. Był zbudowany w architekturze trójwarstwowej. Wykorzystanie serwera aplikacji jako pośredniej warstwy między bazą danych i stacją kliencką jest niezbędne dla wydajnego przetwarzania danych. Przy ogromnej ilości obliczeń, jakie obecnie realizują pakiety ERP przetwarzanie danych nie może odbywać się na komputerach obsługujących bazę czy – co gorsza – stacje klienckie. Serwery aplikacji umożliwiają łatwe skalowanie programu poprzez możliwość równoległej pracy wielu serwerów oraz odciążają serwer bazy danych, którego podstawowe zadanie to obsługa zapytań i innych poleceń SQL.

2. Wykorzystywał nowoczesne środowisko programistyczne. (Współcześnie istnieją dwa: .NET i J2EE.) Tylko te platformy dają gwarancję, że w przyszłości będą posiadały one odpowiednie wsparcie ze strony ich producentów. Starsze środowiska w większości nie są już wspierane i dostosowywane do nowych systemów operacyjnych (np. Windows Vista) oraz możliwości sprzętowych (np. procesorów 64-bitowych). W nowoczesnych środowiskach istnieją wiele większe możliwości programistyczne i prostsze jest samodzielnie dokonywanie kastomizacji przez klienta. Łatwo znaleźć specjalistów, którzy mogą nam w tym pomóc. Programy wykonane w starszych środowiskach nie są certyfikowane na Windows Vista (choć na Viście mogą także pracować).

3. Opierał się na dobrej profesjonalnej bazie danych, np. Oracle, DB2 lub Microsoft SQL Server. Dostęp do tych baz danych możliwy poprzez ODBC, rozmaite programy raportujące (np. Crystal Reports) oraz programy do administracji baz. Posiadają wbudowane mechanizmy optymalizacji pracy znacznie zwiększające ich wydajność. Na rynku pracy można znaleźć administratorów, którzy znają się na zarządzaniu taką bazą i mogą wykonywać czynności typu strojenie baz danych. Część producentów ERP umożliwia zastosowanie nie jednej konkretnej bazy lecz dowolnej. Zwykle ma to wpływ na cenę i pracochłonność prac dodatkowych przy wdrożeniu.

4. Zapewnia wysoką wydajność przy współpracy z dużymi bazami danych . Na małych bazach demo każdy system informatyczny działa szybko. Aby można było powiedzieć, że system jest wydajny musi być sprawdzony w dużych przedsiębiorstwach. Dlatego m.in. powinien w pełni wykorzystywać możliwości nowoczesnych 64-bitowych systemów operacyjnych (a nie tylko potrafić pracować na nich jako maszyna 32-bitowa). Musi być także dobrze napisany, przez doświadczonych fachowców, którzy poza funkcjonalnością zwracają uwagę na kwestie szybkości działania, i być testowany pod tym kontem przez zespoły do kontroli jakości. Doświadczenie producenta ma tu więc niebagatelne znaczenie.

5. Dobrze integruje się z innymi nowoczesnymi programami dla biznesu np. MS Office 2007. Potrafi tworzyć wydruki w ich formacie oraz łatwo eksportować dowolne dane do arkuszy kalkulacyjnych. Najlepsze programy przy wykorzystaniu technologii inteligentnych dokumentów (ang. smart documents) umożliwiają np. tworzenie ofert wyłącznie z poziomu programów Word czy Excel z wykorzystaniem danych zawartych w systemie ERP bez konieczności przełączania do niego a jedynie poprzez wykorzystanie dodatkowego panelu wbudowanego w program biurowy.

Interfejs użytkownika

Systemy ERP składają się z setek formularzy, okien i wydruków. Nawet jeśli poszczególni użytkownicy korzystają jedynie z kilkunastu z nich, to i tak jest to spory zakres wiedzy, który muszą opanować. Od jakości interfejsu użytkownika zależy, jak szybko nauczą się programu i na ile sprawnie będą się w nim poruszać. Dlatego interfejs powinien być:

1. Jednolity w obrębie całego pakietu. Należy zdać sobie sprawę z tego, że przy jego programowaniu pracowało przez wiele lat kilkadziesiąt lub nawet kilkaset osób. Były one zapewne pogrupowane w niezależnie pracujące zespoły realizujące różne funkcjonalności pakietu. Zdarza się, że w efekcie takiej pracy poszczególne formularze tak wyglądają, jakby pochodziły z innych bajek. Dla użytkownika oznacza to, że każdorazowo przy zmianie formularza musi zmieniać także filozofię swojej pracy.

2. Zgodny ze ogólnie przyjętymi standardami, zwykle oznacza to zgodność ze standardami opracowanymi przez Microsoft. Niemal każdy potencjalny użytkownik systemu ERP pracował wcześniej z popularnymi programami typu Windows czy Word. Program powinien respektować przyjęte w tych programach standardy interfejsu. Dzięki temu użytkownicy nowego programu, jakim jest ERP, szybko go opanują, gdyż podstawowe zasady będą takie same. Szczegóły opisują kolejne punkty.

3. Program powinien dzielić się na nast. obszary: menu i pasek narzędzi (albo lepiej wstążki), nawigator, obszar roboczy i pasek statusu. W menu i pasku narzędzi powinny być funkcje dot. bieżącej obsługi, w nawigatorze – funkcjonalność biznesowa, w pasku statusu – informacje i statusy, obszar roboczy służy do wyświetlania formularzy i raportów.

4. Układ pozycji w menu i pasku narzędzi (lub wstążkach) powinien być jak najbardziej typowy. Każdy użytkownik popularnych programów jest przyzwyczajony do menu Plik, Edycja, Widok, Ulubione, Narzędzia, Akcje, Okno i Pomoc. W większości nie trzeba nikomu wyjaśniać gdzie w menu znajdują się poszczególne opcje typu ‘Zapisz jako’ lub ‘Wklej’. Ta sama zasada dotyczy układu przycisków w pasku narzędziowym.

5. Kolorystyka, kształty ikon, wygląd poszczególnych kontrolek (pól, przycisków itp.) powinny być zgodne z Windows. Dzięki temu wystarczy niemal jeden rzut oka na formularz wyświetlony na ekranie aby ogólnie zrozumieć o co w nim chodzi.

6. Program powinien w pełni wykorzystać rozdzielczość, z jakiej korzysta użytkownik dynamicznie rozszerzając wybrane kontrolki (pola, przyciski, tabele z danymi) w taki sposób, aby dopasowały się do aktualnych ustawień użytkownika. Starsze pakiety zbudowane są dla mniejszych rozdzielczości, czego nie widać na prezentacjach handlowych, gdyż – zwykle ze względu na ograniczenia techniczne projektorów – wykonuje się je na rozdzielczości 800×600 lub 1024×768.

Ergonomia wprowadzania danych

Choć poprawny interfejs graficzny użytkownika bardzo usprawnia wizualizację informacji i ergonomię pracy z programem przy pomocy myszy, to należy także zwrócić uwagę na odpowiednią ergonomię wprowadzania danych klawiaturą. W programach ERP w wielu miejscach użytkownicy muszą szybko wprowadzać dużą ilość podobnych dokumentów (np. faktur, dokumentów magazynowych) i po prostu nawet nie mają czasu, by sięgać po mysz. Dlatego uwzględniając ich potrzeby program powinien:

1. Obsługiwać wszystkie podstawowe przypadki użycia programu niemal wyłącznie przy pomocy trzech podstawowych klawiszy: Enter (klawisz akceptacji), Tab (klawisz przejścia) i Anuluj (klawisz wycofania). Do tego dochodzą oczywiście jeszcze klawisze liter i cyfr do wprowadzania danych, ale podstawowa nawigacja w obrębie pojedynczego formularza powinna być możliwa właśnie tymi trzema podstawowymi klawiszami. Przypadki, gdy użytkownik musi zastosować jakiś inny klawisz albo dwu lub trzyklawiszowy skrót, powinny dotyczyć tylko sytuacji innych, niż podstawowa ścieżka obsługi; ale nawet wówczas powinny być preferowane pojedyncze klawisze (np. strzałki, spacja, F1, F2,…) przed złożonymi skrótami.

2. Program powinien umożliwić wprowadzanie dokumentów przy pomocy jak najmniejszej ilości naciśnięć klawiszy, choćby nawet miałby to być tylko jeden dodatkowy ENTER na potwierdzenie dodatkowego komunikatu. Dla pracowników wprowadzających duże ilości dokumentów każde dodatkowe niepotrzebne naciśnięcie klawisza oznacza w ciągu dnia kilkaset dodatkowych uderzeń w klawiaturę dziennie. Aby w pełni spełnić to wymaganie program także powinien w nawigacji przyciskiem TAB po formularzu pomijać pola nieedycyjne oraz mało istotne (użytkownik w razie potrzeby będzie mógł do nich przejść np. strzałkami).

3. W zintegrowanym systemie musi obowiązywać zasada jednokrotnego wprowadzania informacji. Program musi więc być wyposażony w liczne mechanizmy generowania danych, np.: faktury z zamówienia, WZ z faktury, dokumentów magazynowych z dokumentów produkcyjnych, zleceń z zamówień, przewodników z planów, planów produkcji z planów sprzedaży itd. Powinien przy tym zapamiętywać pełną historię powiązań i informacji o tym co z czego powstało.

4. Skróty klawiaturowe (klawisze funkcyjne i Ctrl+klawisz) oraz klawisze dostępu (Alt+litera) powinny być zgodne ze standardami Microsoft, aby nie trzeba było uczyć się nowych. Dotyczy to zarówno podstawowych popularnych skrótów typu F1 (Pomoc) czy Ctrl+S (Zapisz), jak również wielu innych, do których przywykli doświadczeni użytkownicy, np. CTRL+D (Dodanie do ulubionych). Klawisze dostępu, to podkreślone litery w menu, na przyciskach i czasem także na innych kontrolkach umożliwiające szybkie przejście do nich poprzez ALT+litera. Zwłaszcza klawisze dostępu do menu powinny być takie jak w standardowych menu programów pod Windows.

5. Warto także zwrócić uwagę na ergonomię wprowadzania pól z datą przy pomocy klawiatury. Powinna być możliwość wpisania daty bez konieczności wprowadzania separatorów i czterech cyfr w roku. Innymi słowy wartość wprowadzoną w postaci 271107 program powinien samoczynnie przekonwertować na 27-11-2007 (i nie pomylić z 07-11-2027). Ponadto data powinna być wyświetlana zgodnie z formatem zadeklarowanym w ustawieniach systemu Windows.

6. W trakcie wprowadzania dokumentów (np. faktur) program powinien zapewnić możliwość dodania nowych wartości do słowników lub obiektów powiązanych (np. kontrahentów) bez konieczności zamykania bieżącego dokumentu i utraty wprowadzonych w nim już informacji. Nowo dodane pozycje powinny się automatycznie podpowiadać tak, by nie było konieczne ich ponowne wyszukiwanie.

Elastyczność

Wybrany program musi być na tyle elastyczny, aby można było łatwo dopasować go do naszych indywidualnych potrzeb. Nowoczesne pakiety można prosto dostosować do własnych potrzeb bez dodatkowych interwencji programistycznych.

1. Każdy ekran powinien umożliwiać indywidualną kastomizację, łatwą zmianę wymiarów i położenia pól, przycisków, tabel i ich kolumn, tworzenie wielu własnych widoków, autodopasowanie (automatyczne dostosowanie szerokości kolumny do największej długości danych). Powinno być można dodwać własne pola i kolumny (tekstowe, numeryczne, z datą, pola wyboru, przyciski opcji), a istniejące – usuwać, ukrywać lub zmieniać im właściwości (np. z opcjonalnych na obowiązkowe lub z edycyjnych na nieedycyjne).

2. Powinna być możliwość dodawania nowych własnych ekranów, zakładek, pozycji menu, nawigatora itp. Każde przedsiębiorstwo może mieć swoją specyfikę skutkującą koniecznością stworzenia własnych nowych modułów zawierających indywidualną funkcjonalność typową dla niego. Jeśli obszar ten zahacza o ERP lepiej go stworzyć wewnątrz systemu, niż poza nim.

3. Producent powinien dostarczyć program razem z narzędziami do tworzenia wydruków (w przypadku otwartych baz może to być np. CrystalReports) oraz na życzenie przeszkolić wybranych pracowników firmy z funkcjonalności tych narzędzi, a także struktury bazy danych. Program powinien także umożliwić kontekstowe podpinanie tych raportów wewnątrz systemu ERP z możliwością przekazania do nich pewnych parametrów dot. identyfikatora bieżącego obiektu i ustawień filtra. Umożliwi to np. szybkie wykonie danego wydruku dla dokumentu, który użytkownik widzi aktualnie na ekranie lub wykonanie zestawienia dla wybranego zestawu kontrahentów.
Bardzo przydatne są narzędzia do tworzenia wydruków bazujące na szablonach zbudowanych przy pomocy popularnych programów typu Word czy Excel. Użytkownicy bez większego doświadczenia mogą samodzielnie zmieniać treść i układ wydruku. Niestety tylko niektórzy dostawcy ERP oferują takie możliwości.

4. Program powinien umożliwiać administratorowi przedsiębiorstwa tworzenie własnych pakietów i bibliotek odpowiedzialnych za przetwarzanie danych. Zwykle wyniki takich obliczeń będą zapisywane w nowych polach specjalnie dodanych do systemu, jednakże czasem może zachodzić także konieczność modyfikacji wartości w polach standardowych.

5. Powinna być możliwość dowolnego komponowania zdarzeń i ciągów akcji w układy przepływu pracy (Workflow) z wykorzystaniem zarówno elementów dostępnych w programie, jak i zewnętrznych (np. Web Services). Umożliwi to znaczne usprawnienie procesów przedsiębiorstwa. Może być to realizowane także przy pomocy wbudowanego lub zewnętrznego systemu typu BPM (Business Process Management).

6. Poszczególne skróty klawiaturowe (nawet jeśli domyślnie byłyby zgodne ze standardami Windows) powinny być możliwe do przedefiniowania i indywidualnego dostosowania. Użytkownik powinien mieć możliwość podpięcia własnych często wykorzystywanych funkcji pod wybrany skrót.

7. Warto także zwrócić uwagę na to, w jaki sposób nowe wersje programu reagują na dotychczasowe zmiany dokonane w programie samodzielnie przez klienta. Przykładowo: klient dodał na formularzu nowe pole, jednak w nowej wersji układ formularza uległ zmianie i w miejscu, w którym dotychczas znajdowało się to pole teraz jest co innego. Czy system automatyczne dokonuje korekt lub przynajmniej ostrzega administratora o takich sytuacjach, aby on sam dokonał stosownych poprawek?

Filtrowanie

Pakiet ERP w dużej firmie po kilku latach pracy zawiera informacje o setkach lub tysiącach kontrahentów, dziesiątkach tysięcy indeksów, milionach różnego rodzaju dokumentów i dziesiątkach milionów pozycji dokumentów. Mimo tego znalezienie właściwej informacji powinno odbywać się szybko i sprawnie. W tym celu system powinien być wyposażony w nast. możliwości:

1. Filtrowanie bezpośrednio na formularzu przy pomocy prostych warunków nakładanych na dowolne pole. W przypadku danych tekstowych będzie polegało to na wprowadzeniu wzorca wartości (np. ‘J*Kowal*’ lub ‘J%Kowal%’ lub po prostu ‘J Kowal’), a w przypadku ilościowych lub dat – konkretnej wartości z dodatkową możliwością użycia operatorów >, >=, <, <=, <>. Pola z listą wartości powinny umożliwiać skorzystanie z tej listy także w trakcie filtrowania.

2. Filtrowanie pól tekstowych w sposób, który nie uwzględnia wielkości liter. W małych systemach jest to niemal standard, jednak w dużych może powodować problemy z wydajnością, tzn. czas oczekiwania na wynik takiego filtra jest bardzo długi. Można to zauważyć tylko przy dużej ilości danych i występuje jedynie w przypadku niektórych baz. Producenci systemów ERP w różny sposób próbują radzić sobie radzą z tym problemem. Mogą na przykład zastosować dodatkowe funkcje na bazie danych zwiększające wydajność filtrowania nieuwzględniającego wielkości liter. Jest rozwiązanie najlepsze, ale jednak pracochłonne i prawdopodobnie będzie ograniczone do wybranych miejsc w systemie. Inny sposób, to pozostawienie użytkownikowi decyzji o sposobie filtrowania z zaleceniem, by stosował metodę wrażliwą na wielkość liter, a jeśli nie, to czas oczekiwania na wynik może się wydłużyć. Trzecie rozwiązanie, to narzucenie użytkownikowi możliwości wprowadzania danych jedynie przy pomocy wielkich liter. Zwykle jest to do zaakceptowania w przypadku pól typu: symbol lub kod, jednak nie sprawdza się w nazwach i opisach m.in. dlatego, że wielkie litery zajmują dużo więcej miejsca na ekranie i wydrukach.

3. Filtrowanie pól tekstowych w sposób, który nie uwzględnia polskich znaków (ą, ę, ć itd.). Chodzi o to, żeby przy nałożonym warunku filtra typu „Gwóźdź” program znalazł także rekordy zawierające np. „Gwózdz” i na odwrót: przy wprowadzonym warunku „Gwozdz”, by pokazały się także wpisy zawierające polskie znaki.

4. Filtrowanie pól z uwzględnieniem wartości historycznych. Np. przy wyszukiwaniu pracownika po nazwisku panieńskim powinien on zostać wyświetlony nawet wtedy, gdy jego nazwisko w systemie zostało już zmienione bez konieczności dodatkowych czynności (np. korzystania z osobnych pól lub formularzy z danymi historycznymi).

5. Program powinien być także zabezpieczony przed problemami związanymi z filtrowaniem pól tekstowych zawierających spację na końcu. Spacji tej użytkownik nie widzi, więc nie jest świadomy, że system może nie odnaleźć danego wpisu, gdy w warunku filtra nie będzie na końcu także spacji lub tzw. znaku globalnego, czyli % lub *. Niektóre systemy po prostu obcinają końcową spację już na etapie wprowadzania wartości w pole tekstowe, nie chroni to jednak przed przypadkami, gdy dane trafiły do systemu inną drogą, np. poprzez interfejs z innego systemu.

6. Filtrowanie przy pomocy zaawansowanych mechanizmów umożliwiających odnalezienie określonych obiektów na podstawie powiązań z innymi obiektami, np. towarów, które były fakturowane w poprzednim miesiącu. Mechanizmy te powinny być na tyle przejrzyste, aby mógł z nich skorzystać przeciętny użytkownik.

7. Standardowych filtrów programistycznie wbudowanych w system dot. typowych potrzeb, np. filtrowanie wszystkich pracowników zatrudnionych w określonej jednostce organizacyjnej.

8. Filtrowanie przy pomocy definiowania zapytania SQL. Z możliwości tej będzie korzystał Administrator i zaawansowani użytkownicy do budowania szczególnie trudnych filtrów niemożliwych do uzyskania innymi metodami.

9. Zbudowane filtry lub zestawy filtrów powinny być możliwe do zapisania i udostępniania innym użytkownikom.

10. Program powinien wyświetlić np. w pasku statusu informacje o ilości obiektów znajdujących się w aktualnym filtrze. Dzięki temu użytkownik będzie wiedział, czy powinien dalej zawęzić kryteria filtrowania, czy też może ręcznie przejrzeć zwrócone przez system obiekty, aby odnaleźć ten, który go w danym momencie interesuje.

11. Dobre systemy prócz możliwości związanych z filtrowaniem danych posiadają także wbudowane mechanizmy ich wyszukiwania. Wyszukiwanie tym różni się od filtrowania, że przechodzi do obiektu zgodnego z wprowadzonym warunkiem, a jednocześnie nie zmniejsza ilości obiektów, na których użytkownik aktualnie pracuje.

12. Jeśli producent wyposażył swój pakiet w mechanizm archiwizacji danych, to trzeba także sprawdzić, czy możliwe jest łatwe filtrowanie i wyszukiwanie informacji w archiwum. Jednak w nowoczesnych bazach danych ich archiwizacja zwykle nie jest potrzebna. Umożliwiają one bieżący dostęp do wszystkich dokumentów znajdujących się w bazie przy bardzo niewielkim spadku wydajności z roku na rok spowodowanym wzrostem ilości danych, który można łatwo skompensować poprzez polepszenie parametrów serwera bazy danych. Nie zawsze jest to jednak oczywiste, dlatego przy analizie referencji warto zwrócić uwagę na starych klientów od lat wykorzystujących system.

Funkcjonalność

Nawet jeśli na początek zamierzamy wykorzystywać jedynie fragment pakietu, to jednak przy wyborze ERP należy ocenić jego całość. W przyszłości na pewno będziemy potrzebowali dodatkowej funkcjonalności, zaś już dzisiaj decydując się na tylko wybrane moduły powodujemy, że w przyszłości najprawdopodobniej będziemy musieli dokupić kolejne u tego samego producenta. Zwróćmy więc uwagę na nast. aspekty:

1. Funkcjonalność dostępną w dotychczas wykorzystywanych w firmie programach, arkuszach itp. Jest rzeczą oczywistą, że nie chcemy, aby nowy pakiet nie był krokiem wstecz. Ale niestety należy zauważyć, że nowe programy rozwijane od 2-3 lat, choć wyglądają dużo ładniej, mają lepszą architekturę itd., to jednak w wielu obszarach są uboższe pod względem funkcjonalności w porównaniu ze swoimi starszymi poprzednikami mozolnie budowanymi od kilkunastu lat. Jest to właśnie jeden z głównych powodów, dla których starsze pakiety ERP nadal cieszą się dość dużą popularnością. Jednak z drugiej strony oferta nowoczesnych pakietów staje się coraz bardziej rozbudowana i warto poświęcić nieco czasu na znalezienie odpowiedniego programu, który byłby zarówno bogaty funkcjonalnie, jak i nowoczesny.

2. Oczekiwaną przez pracowników dodatkową funkcjonalność, która powinna być obsługiwana przez nowy system. Często te oczekiwania koncentrują się na istotnych niedomaganiach dotychczas wykorzystywanych systemów.

3. Funkcjonalność dotychczas nieuświadamianą przez pracowników, jednak mogącą cennie podnieść efektywność przedsiębiorstwa. Dowiedzieć o niej można się na szkoleniach z ERP, na podstawie szczegółowej analizy systemów prezentowanych na życzenie w siedzibie firmy przez dostawców, poprzez wizyty referencyjne w pokrewnych branżach lub zaprzyjaźnionych przedsiębiorstwach tej samej branży. W rozpoznaniu dodatkowych przydatnych funkcjonalności mogą także pomóc niezależne firmy konsultingowe zajmujące się doradztwem przy wyborze ERP.

4. Rozwój oprogramowania jest niemal tak samo ważny, jak bieżąca funkcjonalność. Dlatego warto przeanalizować również to, co producent będzie robił w przyszłości, tzn. jakie ma plany i strategie dot. rozwoju własnego produktu oraz czy jest to dość duża firma, której nie grozi wrogie przejęcie przez konkurencję. Analizując plany rozwojowe koniecznie sprawdźmy jak producent w przeszłości dystrybuował nowe funkcje programu. Czy dystrybuując nowe wersje pakietu udostępnia bezpłatnie starym klientom nowe funkcje? Czy też bezpłatnie udostępniane są jedynie poprawki i zmiany prawne?

5. Zgodność z polskimi przepisami. Zwykle łatwiej jest ją uzyskać krajowym producentom, którzy potrafią szybkiej reagować na zmieniające się uwarunkowania prawne. Jednakże niezależnie od tego, czy wybieramy wśród krajowych czy zagranicznych dostawców powinniśmy dokładnie przyjrzeć się pakietowi w tym zakresie. Należy przy tym pamiętać, że przepisy zobowiązują nas do prowadzenia działalności w sposób zgodny z prawem, a nie producenta programu. Zwróćmy uwagę na: zgodność z Ustawą o Rachunkowości, przepisami Kodeksu Pracy i ZUS, obsługę międzynarodowych standardów rachunkowości i respektowanie przepisów dot. ochrony danych osobowych.

6. Moduły produkcyjne (jeśli jesteśmy firmą produkcyjną). Jest to bez wątpienia najbardziej specyficzny obszar o dużym zróżnicowaniu funkcjonalności oferowanej przez poszczególnych dostawców. Obszary typu finanse, czy płace są w większej lub mniejszej części regulowane przepisami prawnymi. Dlatego prawie każdy system da się w zakresie finansów i płac jakoś dopasować do dowolnej firmy. Dużo trudniej osiągnąć ten stan w sferze zarządzania produkcją, prawdopodobnie większość ofert nie pasuje do naszych potrzeb lub wymaga bardzo daleko idących modyfikacji. Dlatego przy wyborze programu należy szczególną wagę przyłożyć do sfery produkcyjnej, nawet jeśli na razie nie zamierzamy jej wdrażać w ramach aktualnie realizowanego projektu, dobierając właściwy system do naszej strategii produkcji (produkcja na magazyn, na zamówienie, montaż na zamówienie, a także produkcja jednostkowa konstruowana lub konfigurowana na zamówienie).

7. Funkcjonalność z zakresów logistyki sprzedaży i zakupu, finansów, majątku trwałego, zarządzania zasobami ludzkimi i płac, CRM oraz controllingu. Są to podstawowe obszary, które w dobrym pakiecie ERP powinny być obsługiwane. Ewentualne braki w tym zakresie na pewno trzeba będzie uzupełniać dodatkowymi programami.

8. Zagadnienia dotyczące planowania operacyjnego zgodnie ze standardem APICS. System powinien umożliwiać planowanie nadrzędne (SOP i MPS) oraz wykonywać rozwinięcie MRP z uwzględnieniem różnych możliwych metod partiowania, a także bilansować zasoby (RP, RCCP, CRP). Powinien wyliczać wielkości PAB i ATP w sposób odpowiedni dla poszczególnych stref czasowych. Dla sieci dystrybucyjnych musi obsługiwać także DRP. Do potrzeb montażu na zamówienie (ATO) i produkcji na zamówienie (MTO) powinien umożliwiać stworzenie harmonogramu montażu końcowego FAS. W ramach sterowania produkcją (PAC) powinno być możliwe zarówno harmonogramowani e ‘w przód’ jak i ‘wstecz’.

9. Uzupełniające moduły, w takim zakresie, w jakim są one naszej firmie konieczne: sprzedaż detaliczna i mobilna, Kanban, kontrola jakości, zagadnienia BHP, obsługa delegacji, świadczenia socjalne, kasa zapomogowo-pożyczkową i inne.

10. Możliwość ewidencji zarządczej w oparciu o obiekty ewidencyjne oraz kalkulacje kosztów metodą ABC. System powinien umożliwiać definiowanie dowolnej ilości obiektów ewidencyjnych bazujących na danych już istniejących w systemie lub specjalnie wprowadzanych do celów zarządczych. Konieczne jest także dodatkowe powiązanie z dekretacją pozwalające na automatyczne tworzenie konta księgowego dla dokumentu na podstawie jego opisu obiektowego.

11. Sposób, w jaki program współpracuje z zewnętrznymi programami typu: programy bankowości elektronicznej, MES, CMMS, APS, SCADA, HMI, CAD, BPM, WMS itp. a także z programem Płatnik czy platformami dla biznesu typu SharePoint. Warto także zwrócić szczególną uwagę na możliwość współpracy z przenośnymi terminalami w zakresie wybranych funkcji logistycznych i produkcyjnych a także innych, np. inwentaryzacji majątku trwałego.

12. Specyficzne wymagania różnych branż, np. obsługa etykiet ODETTE w branży motoryzacyjnej lub uwzględnianie stężenia substancji czynnej w surowcach przy przeliczeniach zapotrzebowania materiałowego w branży chemicznej.

13. Obsługę struktur holdingowych i rozproszonych struktur organizacyjnych. System powinien umożliwiać definiowanie tych struktur oraz powiązanie dowolnego dokumentu znajdującego się w systemie z firmą i opcjonalnie z jednostką organizacyjną. Poprzez mechanizm uprawnień administrator powinien móc ograniczać użytkownikom dostęp do tych danych, które dotyczą obsługiwanych przez nich firm i jednostek organizacyjnych.

14. Wielojęzyczność. Nowoczesne systemy umożliwiają zmianę języka w trakcie pracy (lub w oknie logowania) bez konieczności przeinstalowywania programu. Wraz ze zmianą języka cały interfejs powinien się odpowiednio dostosowywać; dotyczy to zarówno menu, nawigatora, etykiet, komunikatów, wydruków i pomocy. W zakresie wielojęzyczności należy wyodrębnić dwa obszary: po pierwsze – możliwości narzędziowe, po drugie – faktyczne tłumaczenie. Może się zdarzyć, że choć system ma odpowiednie możliwości narzędziowe, to nie zostałw pełni przetłumaczony lub lista języków jestbardzo ograniczona do np. 2-3 języków.

15. Wielowalutowość. Obejmuje to zarówno wystawianie faktur w różnych walutach, jak i inne aspekty, np. rozliczanie różnic kursowych czy przeliczanie danych do zestawień.

16. Obsługa wielu jednostek miar. Każdy indeks powinien mieć możliwość indywidualnego zdefiniowania wielu jednostek miar z indywidualnymi przelicznikami i zaokrągleniami definiowanymi dla każdej jednostki osobno. Wystawianie dokumentów w dowolnej jednostce czy przeliczanie ilości do zestawień nie powinno być dla systemu problemem. W symbolu jednostki powinny być rozróżniane małe i wielkie litery.

Kontrola dostępu i Bezpieczeństwo

Choć o problemach z bezpieczeństwem mówi się wiele w kontekście systemów operacyjnych (np. Windows), przeglądarek internetowych i programów pocztowych, to potencjalne zagrożenia wynikające z nieszczelnego systemu ERP mogą być równie poważne. Dlatego nowoczesny system informatyczny powinien:

1. Umożliwiać zarejestrowanie dla każdego użytkownika osobnego identyfikatora i zapewniać dostęp do danych wyłącznie po wprowadzeniu identyfikatora i poprawnego hasła (chyba że zastosowano inną metodę identyfikacji – np. czytniki linii papilarnych).

2. Być zabezpieczony przed utratą danych spowodowaną awarią zasilania lub zakłóceniami w sieci zasilającej. Standardowo systemy oparte na dobrych bazach danych skutkują w razie przerwania zasilania jedynie utratą bieżącej niezapisanej transakcji nie powodując zniszczenia lub utraty integralności danych.

3. Spełniać inne wymogi wynikające z przepisów o ochronie danych osobowych, a w szczególności wymogi Rozporządzenia Ministra Spraw Wewnętrznych i Administracji z 29 kwietnia 2004 r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych.

4. Administrator powinien mieć możliwość ograniczania użytkownikom dostępu do danych. Ograniczenie to powinno dotyczyć zarówno dostępu do bazy z poziomu programu ERP, jak i innych programów (np. kwerend opartych na ODBC).

5. Użytkownicy korzystający z definiowalnych uprawnień funkcjonalnych (profili) powinni widzieć tylko taki zakres, jaki odpowiada pełnionej przez nich roli w przedsiębiorstwie (handlowiec, konstruktor, magazynier, księgowy, planista produkcji itp.).

6. System powinien umożliwiać kontrolowanie pracy użytkowników informując administratora o aktualnych sesjach, przedstawiając historie logowania oraz umożliwiając śledzenie zmian bazodanowych.

7. Powinna być możliwość osobnego nadawania uprawnień do zatwierdzania, księgowania i innych funkcji biznesowych, takich jak np. autoryzacje.

Przy kilku urządzeniach można sobie z tym poradzić metodami tradycyjnymi skrupulatnie wszystko notując i regularnie przeglądając zapisy. Jednakże każde przedsiębiorstwo dysponujące rozbudowanym parkiem maszynowym lub inną grupą urządzeń (środki transportu itp.) stoi przed potrzebą wdrożenia programu, który będzie wspomagał działalność związaną z zarządzaniem remontami i utrzymaniem ruchu. Takie programy należą do systemów informatycznych klasy CMMS.

Czym są systemy CMMS?

Computerized Maintenance Management Systems (w skrócie CMMS) ? Systemy komputerowe do Gospodarki remontowej i Utrzymania ruchu stanowią grupę oprogramowania odpowiedzialnego głównie za następujące obszary:

• Szczegółowa ewidencja wszystkich maszyn i urządzeń wraz z ich dokumentacją techniczną.
• Planowanie i kontrola prac rutynowych (przeglądy i remonty) wymagających realizacji po określonym czasie (np. corocznie) lub przebiegu (np. co 10 tys. km).
• Rejestracja zgłoszeń związanych z koniecznością wykonania dodatkowych prac bądź napraw na skutek awarii.
• Dokumentowanie wykonania wszelkich zleceń (napraw, przeglądów, itp.) wynikających z prac rutynowych bądź awarii obejmujące zużyte materiały i części zamienne oraz wyszczególnienie pracowników bądź firm zewnętrznych realizujących zlecenie.
• Analiza kosztów utrzymania ruchu obejmująca także planowane nakłady oraz budżetowanie.

Systemy CMMS to programy wielokrotnie mniejsze od pakietów ERP, ich producenci ciągle je udoskonalając doprowadzili niemal do perfekcji. W Polsce można spotkać oferty dotyczące kilkunastu zachodnich programów oraz kilku krajowych (w tym jednego naprawdę dobrego). Większość z tych systemów obsługuje wszystkie podstawowe funkcje z zakresu zarządzania remontami i utrzymaniem ruchu. Dlatego o wyborze odpowiedniego programu ostatecznie decydują często kryteria niefunkcjonalne: architektura systemu, rodzaj bazy danych, cena lub ? co bardzo istotne ? możliwości i zakres integracji z pakietem ERP. Wielu dostawców ERP może także pośredniczyć przy sprzedaży CMMS przejmując na siebie odpowiedzialność za powiązanie aplikacji.

Dlaczego systemy CMMS wymagają integracji z ERP?

Systemy CMMS posiadają wiele obszarów wspólnych z pakietami ERP. Obydwa oprogramowania mogą się wzajemnie wspomagać tworząc niezwykle efektywnie działające rozwiązanie informatyczne.

Pomiędzy CMMS i ERP występują liczne kartoteki wspólne. Na pierwszym miejscu należy wymienić maszyny i urządzenia ewidencjonowane jako majątek trwały w systemach ERP, gdzie system wylicza amortyzację księgową oraz podatkową, a także umożliwia rozliczanie jej do celów zarządczych. Z kolei w systemie CMMS są to podstawowe obiekty, których dotyczą przeglądy, remonty i inne prace; Tam także odbywają się analizy ich awaryjności oraz kosztów utrzymania, jak również tworzone są budżety prac.

Ważny element wspólny to także dostępność zasobów rozumiana w dwu aspektach: jako dostępność maszyn i urządzeń oraz dostępność wszelkich części zamiennych i materiałów eksploatacyjnych. Z jednej strony przeglądy i remonty rutynowe powodują czasową niedostępność stanowisk pracy, co musi być uwzględnione przez planistów w harmonogramach zadań dla tych stanowisk. Z drugiej ? do wykonania wszelkich prac potrzebne są odpowiednie ilości części zamiennych i materiałów. Dzięki odpowiedniej współpracy obu pakietów system CMMS może kontrolować stany magazynowe oraz zgłaszać z odpowiednim wyprzedzeniem zapotrzebowania i(lub) zamówienia, które są przez system ERP uwzględniane w procesie zaopatrzenia. Możliwe jest także rezerwowanie materiałów pod potrzeby planowanych prac.

Obydwa programy komunikują się także w zakresie wykonywanych transakcji magazynowych i usługowych. Dokumenty obrotowe (wydania, zwroty itp.) dotyczące części i materiałów rozchodowanych na potrzeby remontów i utrzymania ruchu są albo wystawiane w pakiecie ERP i następnie udostępniane CMMS celem odpowiedniego rozliczenia kosztów albo generowane przez ten drugi i jedynie wyceniane w pierwszym.

Z tych samych powodów również odpowiednie transakcje usługowe (faktury wykonania usług) mogą podlegać obustronnej komunikacji między pakietami.

Im więcej rejestrowanych transakcji tym większa potrzeba porządnej integracji systemów, aby uniknąć dwukrotnego wprowadzania danych.

Aby możliwe było pełne wymienianie informacji o transakcjach, systemy dbają o zgodność bazy kontrahentów zwłaszcza w zakresie dostawców części zamiennych i materiałów eksploatacyjnych, jak również podwykonawców zlecanych prac.

Kolejnym ważnym obszarem integracji jest kartoteka pracowników z jednej strony ewidencjonowanych i rozliczanych w module HR systemu ERP, z drugiej wykorzystywanych do planowania i przydzielania wszelkich prac remontowo-przeglądowych. Możliwe jest także automatyczne tworzenie kart pracy w systemie ERP na podstawie zaewidencjonowanego w CMMS czasu pracy osób z działu utrzymania ruchu.

Jak systemy CMMS integrują się z ERP?

Współczesne technologie informatyczne posiadają bardzo rozwinięte możliwości integracji odrębnych pakietów. Prawie nikt już nie używa tradycyjnych plików tekstowych wysyłanych z jednego programu i odbieranych przez drugi. Zamiast tego stosuje się rozmaite formy interfejsów API uzupełnianych przez pliki XML i zaawansowane kolejki, a w przypadku systemów oddalonych od siebie także usługi sieciowe. Dzięki temu programy funkcjonują niezależnie z zachowaniem dużego poziomu bezpieczeństwa wobec kontrolowanych możliwości ingerencji zewnętrznej aplikacji w wewnętrzną strukturę programu. Tworzą tym samym rozwiązanie stabilnie (także w momencie wykonywania upgrade jednego z pakietów, gdyż interfejsy API są obsługiwane przez ich różne wersje) a zarazem bardzo efektywnie, dzięki czemu dane wprowadzone w jednym programie są ? bez żadnych dodatkowych zabiegów ? dostępne także dla drugiego.

Zbigniew Lisowski

Terminale są jak małe komputery, które tym różnią się od dużych pecetów, że doskonale nadają się do celów mobilnych przy jednoczesnym zachowaniu integracji z macierzystym systemem informatycznym firmy. W jednych i drugich obowiązuje podstawowa zasada: bez odpowiedniego programu nie mogą właściwie realizować stawianych przed nimi zadań.

Znamy wiele rodzajów terminali: tradycyjne (tzw. batch’owe) i radiowe, umożliwiające pracę w różnych wariantach transmisji danych o rozmaitej przepustowości i zasięgu. Mogą one być wyposażone w różne rodzaje czytników kodów jedno i dwuwymiarowych. Wśród innych kluczowych kategorii decydujących o wyborze jest także waga, wytrzymałość baterii i odporność na trudne warunki pracy (wstrząsy, wilgoć, niska temperatura). Istotnym czynnikiem bywa także wielkość i rodzaj ekranu (monochromatyczny, kolorowy LCD, dotykowy) oraz klawiatury, a także system operacyjny, w jakim pracuje terminal (z reguły jest to MS-DOS lub Windows CE, ale dostępne są także terminale pracujące w środowisku Unix lub Linux). Lecz tak naprawdę sercem każdego terminala jest program odpowiedzialny za realizację funkcji biznesowych. To od niego w znacznej mierze zależy, czy wdrożenie terminali w firmie zakończy się sukcesem.

Różnorodność wykorzystania terminali i konieczność ich dobrego dopasowania do indywidualnych potrzeb sprawia, że z reguły każdorazowo potrzebne jest napisanie aplikacji dedykowanych dla poszczególnych klientów. Zadanie to bierze na siebie dostawca sprzętu lub producent systemu ERP. Współcześnie wymagana jest bieżąca współpraca terminala z funkcjami lub usługami dostarczanymi przez aplikację umożliwiającymi bieżącą analizę w systemie ERP danych wprowadzonych przez terminal i natychmiastowe udzielanie odpowiedzi użytkownikowi. Z tego powodu łatwiej oprogramować terminal dostawcy systemu ERP. Ten w razie potrzeby może rozbudować dostępne w systemie interfejsy komunikacyjne lub nawet dokonać zmian w samych procedurach przetwarzania danych. Należy także zauważyć, że często kody kreskowe odczytywane przez terminal są kodami drukowanymi z systemu dostawcy, dlatego jemu łatwiej jest zinterpretować odczytany kod.

Obecnie można nawet kupić całą infrastrukturę u dostawcy ERP, który dostarczy klientowi sprzęt od partnera technologicznego wyspecjalizowanego w terminalach w cenie producenta. Dostawca systemu na podstawie oczekiwań klienta przedstawi w analizie propozycję pokazującą na diagramie procesowym szczegóły działania terminali, a następnie po akceptacji sprawnie je oprogramuje, wykorzystując kompetencje zdobyte w długookresowej współpracy z wybranym partnerem technologicznym. Dla klienta jest to rozwiązanie z finansowego punktu widzenia na ogół najbardziej korzystne i możliwe do realizacji w relatywnie krótkim horyzoncie czasowym, gdyż nie wymaga dodatkowych wysiłków na działania integrujące system terminali z ERP. Ponadto cała odpowiedzialność za poprawną komunikację leży po stronie jednej firmy.

Z technicznego punktu widzenia program działający w terminalu jest najczęściej biblioteką programu komunikacyjnego współpracującego bezpośrednio z usługami lub interfejsami API dostępnymi w systemie ERP. Program ten nie jest ulokowany w terminalu, lecz na stacjonarnym komputerze i komunikuje się z terminalem poprzez nadajniki radiowe – Access Pointy przesyłając do niego ekrany oraz odbierając informacje z klawiatury oraz czytnika kodów.

W celu zwiększenia szybkości działania program komunikacyjny może współdzielić serwer aplikacyjny z systemem ERP lub być z nim połączony dodatkowym łączem dużej przepustowości.

Terminale przechowujące program we własnej pamięci wymagają okresowego komunikowania się z systemem. Może to odbywać się np. przy użyciu stacji dokującej lub poprzez GPRS. Rozwiązanie takie jest zwykle tańsze, gdyż nie wymaga budowy infrastruktury radiowej, ale nie jest w nim możliwa bieżąca współpraca z systemem ERP i korzystanie z całości bazy danych, a informacje zebrane przez terminal trafiają do systemu z opóźnieniem.

Przykład 1. Weryfikacja dostaw

Przy pomocy terminala można skontrolować poprawność dostawy już na rampie lub jeszcze przed rozładunkiem samochodu. Oczywiście najlepiej, gdyby dostawca etykietował wyrób np. w sposób zgodny ze standardem ODETTE. Dzięki temu z etykiety umieszczonej na pojemniku lub palecie można w łatwy sposób odczytać z kodów kreskowych takie informacje, jak indeks pozycji kartotekowej, ilość czy symbol dostawcy. W przeciwnym wypadku brakujące dane należy wprowadzić ręcznie na klawiaturze terminala. Informacja przy użyciu sieci radiowej trafia do systemu, gdzie sprawdzana jest zgodność dostawy z zamówieniem. Jeśli nie ma różnic, to pracownik od razu na ekranie terminala otrzymuje potwierdzenie, towar zostaje przyjęty, a w systemie automatycznie generowany jest dokument przyjęcia (PZ). Jeśli zaistnieją rozbieżności w dostawie w stosunku do zamówienia, to może zostać podjęta decyzja o jej cofnięciu lub przyjęciu tymczasowym na magazyn depozytowy do wyjaśnienia.

Przykład 2: Zarządzanie magazynem wysokiego składowania

Podstawą zarządzania magazynem wysokiego składowania są lokalizacje, ich rozmieszczenie i pojemność. Dla każdego towaru przyjmowanego na magazyn (np. po pomyślnie przeprowadzonej weryfikacji dostaw) system powinien zaproponować optymalną lokalizację. Wybór lokalizacji dokonuje się w systemie ERP z uwzględnieniem takich czynników jak wymiary i masa towaru oraz dostępność miejsca na poszczególnych lokalizacjach, jak również – co być może najważniejsze – optymalne położenie dla danego towaru z punktu widzenia np. jego dostępności lub położenia innych dostaw od danego kontrahenta lub na daną pozycję kartotekową.

Na życzenie magazyniera system podpowiada optymalną lokalizację dla wybranego towaru, jednocześnie zostaje ona tymczasowo zarezerwowana pod kątem danej dostawy. Informacja, którą otrzymuje pracownik zawiera dostatecznie szczegółowe dane dotyczące regału, półki, przegrody itp., a czasami także sposobu umieszczenia danego towaru w danej lokalizacji.

Pracownik zawozi towar na miejsce i potwierdza to w terminalu. Potwierdzenie może przybrać formę odczytania kodu kreskowego umieszczonego przy lokalizacji. W szczególnych przypadkach możliwa jest zmiana zaproponowanego położenia. Nową lokalizację podpowiada system lub wybiera pracownik wprowadzając odpowiedni kod do terminala.

Reguły dotyczące układania towarów na lokalizacjach dotyczą zarówno magazynu materiałowego, jak i wyrobów gotowych. Mogą one być także stosowane do magazynów półproduktów, odpadów i narzędzi.

Przykład 3. Weryfikacja numerów serii

W niektórych branżach bardzo ważna jest szczegółowa identyfikacja numerów serii zarówno w zakresie operacji magazynowych, jak również rejestracji zużytych składników do poszczególnych partii wyrobów gotowych. Aby sprostać temu wyzwaniu wszystkie dostawy powinny posiadać etykietę z numerem serii w kodzie kreskowym. Jeśli kontrahent nie dołącza kodu z numerem serii towaru, to osoba przyjmująca dostawę umieszcza na każdym opakowaniu wydrukowaną z systemu etykietę. Równolegle numer serii zostaje przypisany do poszczególnych pozycji dokumentu przyjęcia (PZ).

Następnie przy wszystkich operacjach magazynowych realizowanych przy użyciu terminala pracownicy posługują się numerem serii odczytując go z kodu kreskowego. Dotyczy to także wydawania na produkcję; wewnętrzna dokumentacja produkcyjna (raporty produkcyjne) wiąże konkretne partie wyrobów gotowych ze zużytymi numerami serii składników.

Przykład 4. Rejestracja produkcji

Na wielkich halach produkcyjnych, gdzie położenie sieci komputerowej jest znacznie utrudnione, a pracownicy nie mogą być „uwiązani” do swoich miejsc, bardzo dobrze w rejestracji produkcji sprawdzają się przenośne terminale.

Pracownik przy użyciu terminala może zarówno odbierać od przełożonego lub planisty polecenia realizacji konkretnych operacji technologicznych, jak również rejestrować wykonaną produkcję. Wprowadza do terminala wykonaną operację i odczytuje kody kreskowe ze zużywanych komponentów dodatkowo każdorazowo podając ilość. Może również odczytać terminalem kod kreskowy maszyny oraz kody kreskowe z wizytówek pracowników realizujących zadanie. Wszystkie informacje są rejestrowane bezpośrednio w miejscu ich powstawania i w momencie pojawienia się zostają zapisane w bazie systemu ERP.

Dane osobowe najważniejsze

Na początek zastanówmy się jak chronimy właśnie dane osobowe. Mają one priorytet, gdyż obowiązek ten wynika z prawa, a poza tym lista wymogów jest w miarę dobrze w przepisach określona. Nikt też z pewnością nie zamierza narażać się pracownikom Biura Generalnego Inspektora Ochrony Danych Osobowych, który dowolnego dnia może zapukać do naszych drzwi w celu „przeprowadzenia niezbędnych badań lub innych czynności kontrolnych”.

Warto przy tym zwrócić uwagę, że przepisy zobowiązują do zapewnienia odpowiedniego poziomu bezpieczeństwa danych osobowych firmę lub instytucję korzystającą z systemu a nie dostawcę oprogramowania.

A więc firma we własnym interesie powinna przenieść wymogi wynikające z prawa na producenta systemu żądając od niego spełnienia określonych wymagań i ewentualnie zabezpieczając się odpowiednio skonstruowaną umową. Oczywiście nie wszystkie punkty ustawy oraz rozporządzenia dotyczą systemu sensu stricte, część z nich jest sprawą wewnętrzną firmy (np. procedury dot. przechowywania zapasowych kopii danych).

Odpowiedzialność karna

W razie stwierdzenia uchybień Generalny Inspektor może w najłagodniejszym przypadku np. zażądać usunięcia uchybień lub zastosowania dodatkowych zabezpieczeń a w najczarniejszym – skierować do organów ścigania zawiadomienie o popełnieniu przestępstwa. Wówczas może nam grozić grzywna, kara ograniczenia wolności lub pozbawienia wolności do roku (w razie np. niedostatecznych zabezpieczeń) lub do lat 2 (w razie nieuprawnionego przetwarzania) albo do lat 3 (jeżeli miałoby to dotyczyć danych ujawniających np. pochodzenie rasowe, przekonania religijne, dane o życiu seksualnym, przynależność związkową lub dane o stanie zdrowia). Łatwo zauważyć, że w dwu ostatnich przypadkach (przynależność związkowa, dane o stanie zdrowia) takie informacje mogą znajdować się w systemie ERP (w postaci np. odliczeń na składki związkowe, wyników badań okresowych lub zwolnień lekarskich).

Przepisy w największej mierze dotyczą administratora danych i to on powinien być najbardziej świadomy odpowiedzialności prawnej, jaka na nim spoczywa.

Wymogi rozporządzenia

Rozporządzenia Ministra Spraw Wewnętrznych i Administracji z 29 kwietnia 2004 r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych opisuje szereg wymogów, z których część dotyczy systemu informatycznego. Systemy takie powinny:

1. Automatycznie odnotowywać datę pierwszego wprowadzenia danych osobowych do systemu oraz identyfikator osoby je wprowadzającej w momencie zatwierdzania przez użytkownika operacji bazodanowej.
2. Ewidencjonować źródła pochodzenia danych osobowych jeśli nie pochodzą one bezpośrednio od osoby, której one dotyczą. W systemach ERP może to np. dotyczyć obciążeń komorniczych.
3. Umożliwiać ewidencję odbiorców, którym dane osobowe zostały udostępnione, dat i zakresów tego udostępnienia.
4. Umożliwiać odnotowanie sprzeciwu dot. przetwarzania danych w celach marketingowych lub udostępniania danych na zewnątrz.
5. Posiadać wbudowane mechanizmy kontroli dostępu do danych.
6. Umożliwiać zarejestrowanie dla każdego użytkownika osobnego identyfikatora.
7. Zapewniać dostęp do danych wyłącznie po wprowadzeniu identyfikatora i poprawnego hasła (chyba że zastosowano inną metodę identyfikacji).
8. Być zabezpieczone przed utratą danych spowodowaną awarią zasilania lub zakłóceniami w sieci zasilającej.
9. Umożliwiać nałożenie na użytkowników wymogów zmiany hasła co określoną ilość dni oraz dot. minimalnej długości i złożoności hasła. (Administrator powinien tak sparametryzować system, by użytkownicy zmieniali hasła nie rzadziej, niż co 30 dni oraz by każde hasło musiało składać się ono co najmniej z 8 znaków, zawierać małe i wielkie litery oraz cyfry lub znaki specjalne.)
10. Umożliwiać przygotowanie kopii bazy danych.
11. Odpowiednio zabezpieczać dane, które są przesyłane w sieci publicznej.
12. Posiadać w standardzie raport zawierający w zrozumiałej formie informacje dot.:
    1. datę pierwszego wprowadzenia danych do systemu;
    2. identyfikator użytkownika wprowadzającego dane osobowe do systemu;
    3. listę źródeł danych, w przypadku danych, które nie pochodzą od osoby, której one dotyczą;
    4. listę informacji o odbiorcach, którym dane osobowe zostały udostępnione, dat i zakresów tego udostępnienia;
    5. informacji o wyrażeniu sprzeciwu dot. udostępniania danych oraz ich przetwarzania do celów marketingowych

Spełniając wymogi rozporządzenia osiągniemy podwójną korzyść: nie tylko będziemy w zgodzie z prawem, ale wszystkie dane naszego systemu (nie tylko osobowe) będą dużo bezpieczniejsze.

Wymogi wewnętrzne

Niezależnie od powyższych punktów, aby w pełni spełnić wymogi rozporządzenia administrator we własnym zakresie powinien opracować odpowiednią dokumentację, na którą składają się polityka bezpieczeństwa i instrukcja zarządzania systemem informatycznym. Będą one zawierać m.in. wykaz budynków i pomieszczeń, w których przetwarzane są dane osobowe, procedury tworzenia kopii zapasowych, sposób przechowywania kopii zapasowych itp.

Dodatkowo jeśli system ERP „niedomaga” administrator powinien podjąć działania mające na celu spełnienie wymogów rozporządzenia. Przykładowo: jeśli system nie umożliwia ewidencji odbiorców, którym dane osobowe zostały udostępnione, to należy stworzyć taką ewidencję poza nim.

Luki w systemach

Ustawodawca poprzez szczegółowe wymogi starał się wysoko umieścić poprzeczkę dla systemów informatycznych. Jednak nie wszystko można przewidzieć, a pomysłowość złodziei danych jest duża. Faktycznie nawet spełniając skrupulatnie wymogi rozporządzenia nadal może pozostać wiele obszarów niezabezpieczonych lub słabych zabezpieczeń, które doświadczony hacker mógłby pokonać. Postarajmy się przyjrzeć kilu możliwym lukom:

1. Dostęp z poziomu konsoli programu może inaczej wyglądać, niż „od spodu”. Zwykle nowoczesne systemy umożliwiają wieloraki dostęp do danych poprzez liczne interfejsy, np. ODBC, Web Services. Warto sprawdzić, czy uprawnienia dot. ograniczenia dostępu dla do części danych z poziomu tych interfejsów są takie same, jak z poziomu konsoli programu.
2. Dane mogą być zapisywane na bazie lub lokalnie tymczasowo przechowywane w cache w postaci niezaszyfrowanej lub słabo zaszyfrowanej umożliwiającej złamanie szyfru.
3. Hasło dostępu dla użytkownika może być lokalnie zapisywane w postaci niezaszyfrowanej.
4. Użytkownik, który ma ograniczony dostęp do danych może dotrzeć do nich w inny sposób: np. nie widzi kartoteki kontrahentów, ale może dotrzeć do informacji o nich na podstawie faktur.
5. Użytkownik ma ograniczony przez administratora dostęp do pewnych danych poprzez nie udostępnienie dla niego części formularzy, ale może dotrzeć do danych „od spodu” lub poprzez takie miejsca w programie, gdzie może elastycznie definiować nowe pola, formularze lub wydruki.

Luki w procedurach

A oto przykładowe luki, jakie mogą się pojawić w wewnętrznych procedurach w firmie:

1. Niewłaściwe postępowanie z wydrukami zawierającymi istotne dane. Mogą być one np. rozprowadzane wśród pracowników w sposób niekontrolowany lub – gdy przestaną być potrzebne – być wyrzucane zamiast niszczenia.
2. Nie zabezpieczanie wydruków elektronicznych utworzonych w oparciu o dane z systemu a przechowywanych poza nim. Z sytuacją tą mamy do czynienia w firmach, w których wydruki elektroniczne (np. w formacie PDF lub RTF) są przechowywane w publicznie dostępnych lokalizacjach sieciowych lub są przetwarzane przez inne programy np. dot. obiegu dokumentów.
3. Niewłaściwe przechowywanie kopii danych w sposób nie gwarantujący ich przetrwania w razie np. pożaru lub w sposób umożliwiający dostęp do nich osobom postronnym.
4. Zbyt wiele osób mających dostęp do systemu z uprawnieniami administratora danych. Może to dotyczyć np. firm wielodziałowych, gdzie w każdym oddziale tworzy się oddzielne stanowisko administratora. Należy pamiętać, że niezależnie od zastosowanych zabezpieczeń i ograniczeń dostępu do danych, administrator zawsze będzie mieć do nich pełny dostęp.
5. Nieuświadomienie pracowników w zakresie konieczności nieudostępniania własnego hasła współpracownikom.

Literatura

• Ustawa z dnia 29 sierpnia 1997 r. o ochronie danych osobowych (Dz. U. z 2002 r. Nr 101, poz. 926).
• Rozporządzenia Ministra Spraw Wewnętrznych i Administracji z 29 kwietnia 2004 r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych (Dz. U. Nr 100 Poz. 1024)

Stowarzyszenie APICS[2] opracowało w latach 60-tych algorytm MRP (z ang. Material Requirements Planning). Został on następnie rozwinięty do tzw. MRP w zamkniętej pętli (MRP closed loop), a dalej do MRP II (Manufacturing Resource Planning) oraz oficjalnie ogłoszony w roku 1989 w postaci dokumentu ?MRP II Standard System?[3]. Koncepcja ta została później rozbudowana do MRP II+ oraz ERP (Enterprise Resource Planning).

Obecnie pod pojęciem MRP II rozumiemy z jednej strony rozbudowany algorytm do planowania zapotrzebowania na zasoby, z drugiej zaś standard zawierający szereg wymogów, jakie powinny spełniać systemy informatyczne do wspomagania zarządzania, wśród których centralne miejsce zajmuje algorytm MRP II. Niniejszy artykuł koncentruje się na opisie algorytmu MRP II począwszy od jego podstaw, aż po rozbudowane warianty i opcje.

Tradycyjne metody planowania produkcji koncentrowały się najczęściej na obliczeniach tylko ilościowych (np. ile jakich materiałów potrzeba do realizacji zlecenia) lub prostych czasowych (np. montaż zajmuje tydzień, więc podzespoły muszą być gotowe odpowiednio wcześniej). Natomiast algorytm MRP łączy w sobie obydwa te podejścia. Wszystkie ilości wyznaczane przez program są na bieżąco przypisywane do odpowiednich okresów planistycznych. W wyniku obliczeń tworzony jest szczegółowy plan produkcji, w którym dla każdego indeksu i czasookresu znajdują się informacje o ilościach i wielkościach uruchomienia zleceń zakupu lub produkcji, a także o produkcji w toku, planowanym zakończeniu produkcji i planowanym stanie zapasów.

Dane wejściowe do algorytmu.

Przed rozpoczęciem obliczeń potrzebne są następujące dane wejściowe:

1. Harmonogram główny produkcji (ang. MPS – Master Production Schedule) zwany także planem operatywnym lub planem spływu produkcji. Najczęściej przedstawiany jest on jako tabela, której wiersze dotyczą poszczególnych indeksów, a kolumny – okresów planistycznych, zaś w komórkach zapisywane są ilości. Okresami w praktyce najczęściej są dni lub zmiany produkcyjne, ale zaawansowane systemy dopuszczają definiowanie okresów dowolnej długości. MPS powinien zawierać okresy co najmniej do takiego horyzontu czasowego, który odpowiada całkowitemu czasowi realizacji produkcji (tzw. Cumulative lead time). Harmonogram główny zwykle jest tworzony ma bazie planu sprzedaży i operacji (SOP ? Sales and Operations Planning) i(lub) otrzymanych zamówień. Zawarte są w nim informacje o oczekiwanym spływie z produkcji wyrobów i półproduktów (np. dla serwisu). Jeśli przedsiębiorstwo dysponuje kilkoma harmonogramami produkcji (np. krótko- i długookresowy) obliczenia będą dla każdego z nich wykonywane niezależnie.
   
2. Specyfikacja konstrukcyjna (lub ? w niektórych branżach ? receptury) zwana BOM (Bill of Material) obrazująca zależności zachodzące pomiędzy poszczególnymi elementami wyrobu. Może ona przyjmować postać np. grafu drzewa struktury konstrukcyjnej wyrobu, w którym na najwyższym poziomie znajduje się wyrób finalny, a na niższych ? części i podzespoły, które dalej również są rozbijane na mniejsze elementy składowe, aż do pozycji zakupionych z zewnątrz. Specyfikacja konstrukcyjna musi zawierać ilości składników wchodzących do indeksów wyżej położonych w strukturze i może być uzupełniona o dodatkowe informacje: powstające odpady, daty ważności itp.
3. Informacje o stanie zapasu poszczególnych elementów, w skład której wchodzą: zapas rzeczywisty, rezerwacje (pomniejszające ilość dostępną z rzeczywistego zapasu), w realizacji (w otwartych zleceniach i w dostawy w drodze)
4. Dane planistyczne dla poszczególnych elementów obejmujące: sposoby partiowania, określenie minimalnej oraz maksymalnej wielkości dostaw, czasy realizacji dostaw (lead time), zapas bezpieczeństwa, współczynniki braków itp.
5. Jeśli obliczenia są realizowane na poziomie poszczególnych operacji technolgicznych, to brana dodatkowo brana jest pod uwagę specyfikacja technologiczna (Routings) obejmująca dla każdego wyrobu i półproduktu co najmniej jedną marszrutę technologiczną, czyli listę operacji technologicznych z podaniem dla każdej operacji jej czasów trwania (jednostkowego ? Tj i przygotowawczo-zakończeniowego ? Tpz) oraz ewentualnie inne dane, np. określenie typu stanowiska, na którym operacja ma być wykonana. Specyfikację konstrukcyjną i technologiczną można połączyć na wspólnym grafie drzewa technologicznego.

Mechanizm obliczeń

Ogólne funkcjonowanie MRP polega na wykonywaniu dla każdego indeksu następujących kroków:

1. Obliczenie potrzeb brutto (PB) na podstawie harmonogramu głównego produkcji i(lub) informacji o planowanych uruchomieniach (PU) elementów wyższego rzędu. W drugim przypadku PU są dodatkowo mnożone razy ilość składników wchodzących do indeksu wyżej położonego w strukturze (na podst. dokumentacji konstrukcyjnej).
2. Wyliczenie potrzeb netto (PN) z uwzględnieniem informacji o aktualnym i planowanym stanie zapasu (SZ). Dla każdego okresu PN= PB-SZ.
3. Następnie dla wszystkich dodatnich potrzeb netto ustalane są wielkości planowanych uruchomień w podziale czasowym. Na tym etapie wykorzystywane są czasy technologiczne, kalendarze pracy stanowisk i informacje dot. sposobu partiowania produkcji. Jednocześnie wypełniane są wielkości planowanych przyjęć i produkcji w toku (PT). Z kolei planowane przyjęcia powiększą planowany stan zapasu.

Po zaplanowaniu pojedynczego uruchomienia produkcji system powtarza cyklicznie obliczenie potrzeb netto dla danego indeksu (krok 2) i ponownie wstawia planowane uruchomienie (krok 3), tak długo, aż dla danego indeksu wszystkie PN zostaną zaspokojone. Wówczas przystępuje do obliczeń dla innego indeksu, dla którego obliczenia jeszcze nie zostały wykonane. Zwykle jest to element niżej położony w strukturze konstrukcyjnej lub na tym samym poziomie. W ten sposób całość ulega powtórzeniu. Algorytm działa tak długo, aż wszystkie indeksy zostaną zaplanowane.

Ręczne obliczenia przy większej ilości wyrobów finalnych i bardziej skomplikowanych strukturach byłyby zbyt pracochłonne, dlatego można je wykonać jedynie przy użyciu systemu informatycznego. W praktyce należy uwzględnić o wiele więcej dodatkowych informacji, takich jak współczynniki braków, różne metody partiowania, indywidualne kalendarze itp. Wszystko to sprawia, że przeliczenia są zbyt zawiłe, aby można było sobie z nimi poradzić bez dobrego programu.

Wyniki przeliczeń są często prezentowane w postaci wykresu Gantt?a.

Rozwinięcia algorytmu

MRP narzędzie czysto planistyczne, jednak dzięki stworzeniu sprzężenia zwrotnego między fazą planowania, a fazą realizacji można wykorzystać też te systemy do bieżącego sterowania produkcją. Otrzymujemy wówczas tzw. system MRP działający w zamkniętej pętli. W systemie tym w sytuacjach wystąpienia odchyleń od planowanego przebiegu produkcji można dokonać korekty harmonogramów, planów potrzeb materiałowych i zdolności produkcyjnych a nawet planu produkcji wyrobów finalnych.

Obliczenia przedstawione powyżej nie biorą pod uwagę zdolności produkcyjnych. Włączenie też tego aspektu do planowania daje cenne rozwinięcie algorytmu w postaci planowania zasobów produkcyjnych (Manufacturing Resource Planning, występującej w literaturze także jako MRP II). W koncepcji tej oblicza się wielkość zdolności produkcyjnych niezbędnych do realizacji zleceń w każdej planowanej jednostce czasu dla poszczególnych stanowisk, czy wydziałów i przedstawia w postaci wykresu obciążeń zleceniami. Wykres ten porównuje się następnie z posiadanymi zdolnościami i w sytuacji, gdy są one zbyt niskie lub też występują znaczne wahania obciążeń w poszczególnych okresach podejmuje się jedno z następujących działań: próbuje się zwiększyć zdolności produkcyjne przez np. pracę w godzinach nadliczbowych, dokonuje się zmian w rozkładzie zadań lub w ostateczności zmienia się harmonogram główny produkcji. Zaawansowane systemy potrafią na bieżąco w trakcie obliczeń analizować obciążenia stanowisk i w razie przeciążeń od razu kolejkować zadania w wąskich gardłach (tj. tam, gdzie nie można już zwiększyć możliwości produkcyjnych).

Kolejne rozwinięcie systemu MRP polega na włączeniu do niego planowania finansowego. Otrzymujemy w efekcie takich działań system ERP. Pozwala on kontrolować zdolności finansowe realizacji zleceń i tworzyć alternatywne plany produkcji z punktu widzenia ich wpływu na wynik finansowy.

• [1] Marek J. Greniewski ?Podstawowe pojęcia niezbędne dla zrozumienia MRP II? wyd. UCL S.A. Warszawa 1995r. str. 3
• [2] APICS The Association for Operations Management organizacja non-profit założona w 1957 roku początkowo pod nazwą American Production and Inventory Control Society
• [3] Darryl V. Landvater, Christopher D. Gray ?MRP II Standard System. A Handbook for Manufacturing Software Survival? wyd. Oliver Wight Limited Publications, Inc., Essex Junction, Vermont, USA, 1989r.

Ewidencja zleceń produkcyjnych

Każdy dobry system ERP umożliwia ewidencję zleceń produkcyjnych. Obejmuje ona podstawowe informacje, takie jak m.in: symbol, nazwa, data otwarcia, termin realizacji, opis, określenie grupy zleceń oraz jednostki organizacyjnej (oddziału, zakładu) odpowiedzialnej za realizację. Najbardziej istotnym elementem każdego zlecenia produkcyjnego jest lista produktów do wytworzenia. Dla każdej pozycji produktu powinna być możliwość podania co najmniej: indeksu pozycji kartotekowej, wymaganej ilości, jednostki miary (w jakiej wyrażona jest ilość) i indywidualnego terminu realizacji.

Ograniczenia niektórych systemów narzucających zlecenia jednopozycyjne mogą być barierą trudną do pokonania przy wdrożeniu. Odpowiedni program umożliwia wprowadzenie wielu pozycji do jednego zlecenia. Poszczególne pozycje mogą być nie tylko na różne indeksy, lecz także na ten sam indeks wytwarzany z różnymi terminami realizacji.

Wielość jednostek miar

Ważnym elementem jest możliwość wykorzystania wielu jednostek miar do każdego indeksu. Zdarzają się sytuacje, że np. odbiorca zamawia towar w tonach