Partie WIP – śledzenie pochodzenia w produkcji masowej w SAP ERP

Śledzenie pochodzenia czy identyfikacja produktu (ang. traceability) jest wymaganiem powszechnym w branżach takich jak farmacja, przemysł spożywczy czy chemiczny. Sprowadza się do zapewnienia dla każdej partii wyrobu możliwości zidentyfikowania wszystkich jego składników (półproduktów i surowców) oraz ich właściwości takich jak producent, data ważności, wyniki kontroli jakości. To samo wymaganie jest coraz powszechniejsze w innych branżach, niekoniecznie procesowych. W niniejszym artykule przedstawiamy wyzwania związane z implementacją identyfikacji produktu w produkcji masowej i sposób ich rozwiązania z wykorzystaniem standardowych funkcjonalności systemu SAP ERP.

Identyfikacja produktu w przemyśle procesowym

Farmacja, branża chemiczna czy spożywcza to prawie zawsze przemysł procesowy. Najprostszym wyróżnikiem produkcji procesowej jest fakt, że wyrobu gotowego nie można już rozmontować, rozdzielić na składniki. Tak jest z lekami – raz wyprodukowanego leku nie można łatwo rozdzielić na substancję czynną, masę tabletkową i inne substancje pomocnicze. Istotną cechą produkcji procesowej jest to, że zwykle zlecenie produkcyjne generuje jedną unikalną i jednorodną partię produktu. Ta partia powstaje przez homogenizację wszystkich komponentów, a zlecenie produkcyjne jest realizowane w miarę szybko. Zatem z punktu widzenia pochodzenia produktu mamy tutaj relację 1:N między partią wyrobu a partiami komponentów. Klasyczne śledzenie partii w systemie SAP ERP jest tutaj dobrym i wystarczającym rozwiązaniem.

Identyfikacja produktu w produkcji masowej

W przypadku produkcji masowej zlecenia są zwykle realizowane dłużej, z jednego zlecenia może powstać wiele partii wyrobu, a poszczególne sztuki wyrobu czy półproduktu są wytwarzane z dużą szybkością. Typowym przykładem jest branża AGD i obszar obróbki blachy – blacha z kręgów jest cięta na tzw. przygotówki, przechodzi przez tłocznię, a wytłoczone elementy są przekazywane do emalierni. Tłocznia pracuje z dużą szybkością. Jest zasilana przez kręgi blach pochodzące z różnych wytopów. Mimo starannej kontroli jakości często dopiero w emalierni ujawniają się problemy z surowcem. W takim przypadku konieczne jest zidentyfikowanie numeru kręgu blachy, z którego powstała dana partia problematycznego półproduktu. Klasyczne śledzenie partii nie jest tutaj wystarczającym rozwiązaniem, gdyż zlecenia produkcyjne na tłoczni opiewają na duże ilości i zużywają wiele kręgów blachy. W konsekwencji relacja między partią detalu a partią półproduktu jest tutaj typu N:M.

Partie WIP – rozwiązanie identyfikacji N:M w systemie SAP ERP

Rozwiązaniem powyższego problemu jest mało znana funkcjonalność SAP ERP – partie WIP (ang. work in progres batch), które wykorzystaliśmy w Amice w obszarze tłoczni.

Dotąd w Amice wyzwaniem była identyfikacja surowca (blachy), z którego wykonano dany detal. Identyfikacja w systemie była tracona w momencie wydania blachy z magazynu i jej zużycia na pierwszym etapie produkcji. Dodatkowo relacja między partiami blachy a partiami detali produkowanych na jednym zleceniu produkcyjnym jest typu N:M. Do identyfikacji produktu na wydziale tłoczni zastosowaliśmy standardową funkcjonalność SAP ERP śledzenia partii w toku tzw. partie WIP. Partie WIP pozwalają na analizę pochodzenia produktu i cofnięcie się od wyrobu gotowego aż do surowca nawet w przypadku, gdy jedno zlecenie produkcyjne wytworzyło wiele partii detalu z wielu partii surowca. Pozwoliło nam to na jednoznaczną identyfikację z jakiej konkretnie partii blachy została wyprodukowana dana część. Jest to nieocenionym ułatwieniem w sytuacji problemów na emalierni, kiedy konieczna jest reklamacja surowca. Dopiero w procesie emaliowania ujawniają się często wszystkie ukryte wady blachy, a dostawca wymaga wtedy podania konkretnego kręgu blachy z całej dostawy. Bez wykorzystania partii WIP identyfikacja produktu w obszarze tłoczni byłoby praktycznie niewykonalne.

Rys 1. Śledzenie partii WIP w SAP ERP – transakcja MB56

Powyższy raport pokazuje identyfikację partii dla pojedynczego zlecenia produkcyjnego. Ikona oznacza partię, natomiast ikona partię WIP. Na tym zleceniu produkcyjnym zostały wyprodukowane dwie partie detalu o numerach 3135 i 3140. Dzięki zastosowaniu funkcjonalności partii WIP widać wyraźnie, że partia 3135 powstała z partii 2899, 2950, 2930 i 2953 blachy, natomiast partia 3140 z partii 2899 i 2950. Klasyczne śledzenie partii w SAP ERP nie pozwala na taką precyzję śledzenia, daje tylko informację, że obie partie detalu 3135 i 3140 powstały ze wszystkich partii blachy 2899, 2950, 2930, 2953.

Dodatkowo został zmodyfikowany procesu nadawania numerów partii dla kupowanych blach – każdy krąg stanowi teraz oddzielną partię, osobno kontrolowaną, oddzielnie śledzoną. Dzięki temu w przypadku jakiegokolwiek problemu z emaliowaniem detalu możliwe jest wyświetlenie całej jego struktury pochodzenia, aż do kręgu blachy wraz z informacją kto, kiedy go kontrolował i jakie były wyniki kontroli.

Konfiguracja w SAP ERP

Partie WIP są dostępne w SAP ERP w wersji ECC 6.00 z pakietem rozszerzeń minimum 4 po aktywacji funkcji biznesowych: LOG_PP_WIP_BATCH oraz LOG_PP_WIP_BATCH_02. Aktywację wykonuje się transakcją SFW5.

Rys 2. Włączenie w SAP ERP funkcji biznesowych partii WIP

Operacje potwierdzenia produkcji odbywają się w Amice w systemie SAP ERP zarówno na tłoczni, korzystającej z partii WIP, jak i na innych wydziałach, które ich nie używają, dlatego też konieczne jest rozróżnienie tego w systemie. Wykorzystane są tutaj odpowiednie profile przypisane do użytkowników, dzięki czemu interfejs w transakcji do rejestracji produkcji dostosowuje się do potrzeb zalogowanego użytkownika.

Rys 3. Transakcja CO11N do rejestracji przyjęć i wydań z partiami WIP na zleceniach produkcyjnych

Kolejnym krokiem konfiguracji partii WIP jest utworzenie materiału referencyjnego, na którym system będzie tworzył pośredniczące partie WIP przy rejestracji produkcji. Indeksy te są założone w systemie jako niewycenione materiały, dzięki czemu podczas księgowania dokumentów materiałowych nie powstają żadne dokumenty w rachunkowości. Odbywa się to poprzez dodatkowe ruchy materiałowe w systemie SAP ERP, które przeksięgowują w momencie potwierdzania produkcji ilości z surowca na materiał referencyjny w momencie wydania oraz z materiału referencyjnego na wyrób gotowy w momencie przyjęcia produktu końcowego.

Transakcje skanerowe

Ekran rejestracji partii WIP sprawia wrażenie mało intuicyjnego i faktycznie taki jest, choć daje wszystkie możliwości zarządzania partiami WIP. Uznaliśmy, że wykorzystanie takiego interfejsu użytkownika w środowisku tłoczni o dużej szybkości produkcji nie jest możliwe.

Dlatego całą operację rejestrowania wydania i przyjęcia z partiami WIP „opakowaliśmy” w ergonomiczną transakcję skanerową, z minimalną ilością pól do wypełnienia. Operator prasy na tłoczni nie musi wprowadzać ręcznie danych przy komputerze, a jedynie skanuje kody kresowe odpowiednich partii surowców, a następnie potwierdza wyprodukowane ilości na urządzeniu mobilnym. Dodatkowo transakcja ma wiele ułatwień i usprawnień w stosunku do wersji standardowej m.in. podpowiada ilości domyślne dla pojemników z przyjmowanymi detalami oraz wylicza w tle ilości do pobrania surowca. W transakcji skanerowej wprowadzono też automatyczne usuwanie danej partii z listy dostępnych, jeżeli zużyliśmy już cały jej zapas. Wszystko to skraca znacznie czas, który operator maszyny musiałby poświęcić na zarejestrowanie kolejnych partii wyprodukowanego towaru standardowo, ręcznie w systemie oraz pozwala na zminimalizowanie błędów wynikających z ludzkich pomyłek.

Podsumowanie

Standardowy system SAP ERP zawiera znacznie więcej funkcjonalności niż wydaje się na pierwszy rzut oka. Te funkcje są często nieaktywne i wymagają włączenia w transakcji SFW5. Kiedy stanęliśmy przed wyzwaniem implementacji śledzenia produktu na tłoczni wydawało się to zadaniem niewykonalnym w ramach standardu SAP ERP. Jednak dokładniejsza analiza dokumentacji wskazała na partie WIP, które w pełni spełniły wymagania firmy. Stąd wniosek, że każde wdrożenie należy zacząć od dokładnej analizy dokumentacji systemu, zanim zacznie się pisać własne rozszerzenia.

Zostaw komentarz

This site uses Akismet to reduce spam. Learn how your comment data is processed.