Przyczyny różnic pomiędzy zapasami w systemie a rzeczywistością.

SAP ERP jest systemem wspierającym procesy biznesowe w firmie. Czasami jednak jest niesłusznie obwiniany za nieprawidłowości w swoim działaniu. Po głębszej analizie przypadku prawie zawsze pojawia się wniosek, że wina leży w użytkowaniu niezgodnym ze standardami. To z kolei ma swoją przyczynę w niskim poziomie świadomości użytkowników i małej ilości szkoleń na temat jego funkcjonowania. Brak świadomości skutków popełnianych błędów podczas użytkowania może okazać się przyczyną obniżenia poziomu dyscypliny, a to z kolei może prowadzić do sytuacji z jaką spotkałem się w praktyce: system SAP nie odzwierciedla fizycznej sytuacji na magazynie.

Produkcja idzie swoim tempem, koryguje się zapasy na bieżąco aby nie doszło do braku i na wszystko można przymknąć oko… dopóki nie dojdzie do różnic podczas inwentaryzacji rocznej, z których należy się wytłumaczyć.
W poprzednim artykule opisany został problem braku ruchu potwierdzającego dostarczenie komponentu do zlecenia produkcyjnego z uzupełnionego wcześniej miejsca stałego (który został rozwiązany). Pozostał jeszcze problem z potwierdzaniem zleceń przeniesienia i zleceń produkcyjnych w czasie rzeczywistym.

Zbyt późne potwierdzanie zlecenia przeniesienia (często dopiero na koniec zmiany) powodowało sytuację, w której zlecenie produkcyjne przeszło już przez wszystkie etapy produkcji, po przesunięcie na skład wysyłkowy, ale składniki potrzebne do jego realizacji, systemowo jeszcze nie zostały dostarczone do produkcji. To powodowało dużo zapasów ujemnych na magazynie. Brak dostępności składników podczas potwierdzania operacji produkcyjnych powodował dużo błędów w COGI. Odwiedziny w transakcji COGI odbywały się raz na jakiś czas i usuwano błędy masowo. Trudno było znaleźć przyczynę nieprawidłowego ruchu, ponieważ miał miejsce w dalekiej przeszłości.

Rys. 1 Zbyt późne wizyty w transakcji COGI – odległe daty

Nieumiejętne wykorzystywanie tej transakcji często ograniczało się do naprawiana poprzez zwykłe usunięcie rekordu. Po usunięciu błędu pojawiało się błędne przekonanie, że problem został usunięty, jednak nadal nie został potwierdzony uzysk komponentu. Nie rozumiano również tego, że błędy pojawiały się gdy potwierdzono operację zużywającą dany komponent chociaż nie był on dostępny w systemie.

Często pojawiała się sytuacja gdy pracownik zapominał potwierdzić zlecenia przeniesienia przy rozmieszczeniu dostawy na magazyn. Część została fizycznie pobrana do zlecenia serwisowego, natomiast w COGI pozostał błąd spowodowany niedostępnym składnikiem potrzebnym do potwierdzenia operacji w zleceniu serwisowym.

Rys. 2 brak potwierdzenia rozmieszczenia materiału na magazynie

Przeglądając dokumenty materiałowe widać, że nie został odnotowany ruch zużycia części przez zlecenie serwisowe, ani też nie odnotowano wejścia materiału na magazyn.

Rys. 3 brak wydania do zlecenia, brak wejścia materiału na magazyn

Po potwierdzeniu zlecenia przeniesienia na rozmieszczenie części na magazynie oraz przetworzeniu błędnego rekordu w COGI ruchy materiałowe wyglądały już prawidłowo:

Rys. 4 Prawidłowe ruchy materiałowe – widoczny ruch wejścia materiału i wydanie do zlecenia.

Po obserwacji systemu na serwerze testowym i próbach potwierdzania zleceń przeniesienia i zleceń produkcyjnych na różne sposoby wszystko stało się jasne. Bardzo istotnym spostrzeżeniem było odkrycie, że błędy są związane z pobraniem wstecznym – wskaźnikiem backflush zaznaczonym w specyfikacji materiałowej i w ustawieniach danych podstawowych komponentu (Wgląd MRP2). Stało się jasne iż system sam wykonuje ruchy materiałowe na podstawie danych podstawowych materiału. Po obserwacjach pracowników okazało się, że wielu z nich potwierdzało zlecenia przeniesienia dopiero na koniec zmiany a czasami nawet w ogóle o tym zapominali.
Zrozumienie, które przyszło wraz z obserwacją ułatwiło “naprawianie błędów w COGI” i sprawiło, że praca ta stała się przyjemna. Jednak taktyka naprawienia błędów bez eliminacji przyczyn okazała sie syzyfową pracą, dlatego przeszkolono pracowników i poinformowano ich o skutkach opóźnionego potwierdzania zleceń przeniesienia.

Każdy ruch fizyczny, każde przeniesienie i wydanie materiału na magazynie musi zostać odzwierciedlone w SAP w czasie rzeczywistym. Dzięki uświadomieniu pracownikom zależności pomiędzy rezerwacjami zapasów do zleceń przeniesienia i potwierdzeniami operacji produkcyjnych a stanami widocznymi w transakcji LS24, zapasy w systemie zaczęły odzwierciedlać zapasy rzeczywiste.
Po jakimś czasie wizyty w transakcji COGI pełniły już bardziej funkcję controllingową a zaoszczędzony czas poświęcany niegdyś na naprawę lub usuwanie błędów można było poświęcić na dalszą optymalizację. (Szczegółowy opis możliwości transakcji COGI zostanie przedstawiony w kolejnym wpisie).

Powyższe dowodzi, iż brak świadomości wpływu użytkowników na system SAP, może prowadzić do braku dyscypliny. Nieświadomi użytkownicy mogą chcieć “pójść na skróty”, nie wiedząc, że każdy błędny ruch i oddalenie od standardu przynosi skutki w innych obszarach SAP, o których ci użytkownicy nie mają pojęcia. Dlatego najlepszym rozwiązaniem jest obserwacja zależności pomiędzy procesami w SAP. Odłożenie pakietu Z-transakcji na bok, przyjrzenie się procesowi w standardzie a następnie uświadomienie użytkowników mających wpływ na źródło problemu. Zostanie już tylko systematyczna kontrola. Przy bieżącej kontroli przyczynę błędu można namierzyć bardzo szybko i sprawdzić sytuację fizyczną. Obserwacja ruchów w systemie w parze z obserwacją aktualnej sytuacji na magazynie/produkcji znacznie pogłębia zrozumienie.

Komentarze o “Przyczyny różnic pomiędzy zapasami w systemie a rzeczywistością.

  1. Już nie wchodząc w szczegóły odpowiedzialności za wdrożenie, to co powoduje różnice w stanach, to zadania których nikt nie kontroluje, czyli joby uruchamiające szereg przeksiegowań w z-transakcjach, pomiędzy składam, magazynami, jednostkami i kolejnymi zdarzeniami. Bez obsługi błędów na każdym z etapów i raportów korygujach nie da się tego ogarnąć. A sam standard nic nie popsuje, chyba że mocno się postarasz (złe ruchy w np. Lt01, vlmove itp.)

    1. Święta racja! Nikt nie kontrolował, ponieważ nikt nie rozumiał co się dzieje w systemie – brak osoby odpowiedzialnej w firmie. Support znajduje się w głównej siedzibie firmy za granicą, która ma do ogarnięcia około 60 oddziałów, w tym wdrożenia wciąż budujących się nowych oddziałów. Przy wdrożeniu odpowiedni ludzie zostali przeszkoleni do prawidłowej obsługi systemu, ale ich już nie ma a Polak jak to Polak zawsze znajdzie sposób na pójście na skróty w systemie i tak z pracownika na pracownika metoda obsługi systemu ewoluuje odbiegając w nie do końca dobrą stronę. Jest jeden duży plus – to świetna okazja do nauki systemu i próby jego zrozumienia na własną rękę, czego skutkiem jest to, że teraz jest już dobrze 😉 To jak odkrywanie starożytnej wiedzy na nowo 😉

      1. Niezmiennie zdumiewa mnie fakt, że do obsługi SAP siadają ludzie nieprzeszkoleni. Magazynier nie sądzie na wózek widłowy bez odpowiednich uprawnień i przeszkolenia. Do obsługi SAP dopuszcza się natomiast ludzi zupełnie świeżych. A przecież odpowiedzialność i możliwość wyrządzenia szkód magazyniera na wózku jest nieporównywalnie mniejsza od użytkownika SAP o ograniczonych nawet uprawnieniach. To jest temat na oddzielną dyskusją o zarządzaniu wiedzą w firmach i zarządzaniu sukcesją na poszczególnych stanowiskach. Widziałem chyba tylko jedną firmę z potężnym systemem e-learning. Tam nikt nie miał dostępu do SAP bez przejścia odpowiednich szkoleń.

    2. Moim zdaniem od dyskusji o odpowiedzialności za wdrożenie jednak nie uciekniemy. Ktoś te Z-wynalazki jednak ciągle konstruuje, co gorsza działają one często w tle i nikt ich nie kontroluje. Może w założeniach takie zadania mają wykonywać jakieś użyteczne funkcje. Jednak zwykle prowadzą do braku odpowiedzialności biznesu za swoje dane, do syndromu "system tak zrobił". Dlatego uważam, że lepiej taki zadań nie tworzyć, a jeśli już je robimy to zawsze musi być ktoś rozumiejący ich działanie i odpowiedzialny za ich efekty, odpowiedzialny po stronie biznesu, nie IT.

    1. Szczerze mówiąc nie mam pojęcia skąd ten skrót. Pewnie tak jak pisze Dominik, nie jest to żaden skrót tylko po prostu nazwa transakcji, ale googlując w necie natknąłem się na opinię, że:
      1. COGI może oznaczać – Controlling of Goods Issue
      2. CO – dwa pierwsze symbole transakcji do zleceń produkcyjncych i GI (Goods Issue)
      3. Ostatnia opinia – jest to po prostu program do obsługi błędów, o których pisze Dominik i nazwa transakcji nie ma nic wspólnego z dwoma powyższymi punktami.
      źródło: LINK

  2. Wydaje się, że często w firmach, które zdecydowały się na wdrożenie SAP, już krótko po roll-oucie, odpowiedzialność szybko się rozmywa. Rozbieżności magazynowe, "job-y" działające w tle, transakcje Z-Y, itp. powodują, że nad systemem nikt nie panuje, a co więcej, pojawia się przekonanie, że "SAP nie działa". Osobiście jestem zwolennikiem tego, by roll-out został przeprowadzony przez firmę konsultingową w taki sposób, by pozostawiony po okresie wsparcia biznes, całkowicie czuł odpowiedzialność za dane, które w systemie muszą być up datowane i utrzymywane. Bez świadomości biznesu, i przede wszystkim poczucia odpowiedzialności, prawidłowe działanie standardu SAP, wg. mnie, jest niemożliwe. Pojawia się wiec pytanie, w jaki sposób zmotywować biznes do utrzymywania danych na właściwym poziomie jakościowym?

    1. Na Twoje pytanie mam dwie odpowiedzi, cytaty z wielkich tego świata:
      Peter Drucker: "if you can’t measure it, you can’t manage it"
      Eliyahu M. Goldratt: "tell me how you measure me, and I will tell you how I will behave"

      Moim zdaniem najlepszym sposobem motywowania biznesu jest tutaj ustanowienie jasnych miar jakości procesu / KPIs, np. liczby wyjątków MRP, liczby przeterminowanych dokumentów, poziomów zapasów itd. Te wskaźniki powinny być regularnie mierzone, raportowane i dostępne dla wszystkich zainteresowanych. Właściciele danych powinni natomiast być rozliczani z poziomów tych wskaźników, podobnie jak z poziomów sprzedaży czy zrealizowanych oszczędności w zakupach. Wtedy proste i mocne ustanawiasz przełożenie danych w systemie na biznes.

      Zdaję sobie sprawę, że nie jest to nic odkrywczego. Podobne sposoby motywowania działają od dawna. To co mnie zastanawia, to ciągły brak świadomości, że dane w systemie są częścią biznesu, a nie zabawką działów IT.

      1. "najlepszym sposobem motywowania biznesu jest tutaj ustanowienie jasnych miar jakości procesu / KPIs, np. liczby wyjątków MRP, liczby przeterminowanych dokumentów, poziomów zapasów itd. Te wskaźniki powinny być regularnie mierzone, raportowane i dostępne dla wszystkich zainteresowanych. Właściciele danych powinni natomiast być rozliczani z poziomów tych wskaźników, podobnie jak z poziomów sprzedaży czy zrealizowanych oszczędności w zakupach. Wtedy proste i mocne ustanawiasz przełożenie danych w systemie na biznes." – święte słowa. Nic dodać, nic ująć! Zgadzam się w 100%

Zostaw komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.