Wysłanie komunikatu i otrzymanie informacji o jego poprawnym przetworzeniu może sprawiać wrażenie, że obowiązek raportowy został wykonany prawidłowo. Taki status potwierdza jednak przede wszystkim, że komunikat został przyjęty przez system i przeszedł zastosowane reguły weryfikacji.
Nie daje natomiast pełnej odpowiedzi na pytanie, czy przekazane dane są kompletne, zgodne z dokumentami źródłowymi i odzwierciedlają rzeczywiste operacje zachodzące w organizacji.
Poprawnie wysłany komunikat nie oznacza jeszcze, że cały proces raportowania do ZSMOPL przebiega prawidłowo.
Rzetelna ocena raportowania wymaga spojrzenia szerzej: od konfiguracji kartotek i dokumentów, przez sposób rejestrowania operacji magazynowych, aż po kontrolę statusów, korekt i stanów przekazywanych do ZSMOPL.
Dlaczego status „Poprawny” nie wystarcza?
Status wskazujący na poprawne przetworzenie komunikatu oznacza, że system nie wykrył błędów uniemożliwiających jego przyjęcie. Nie jest to jednak równoznaczne z potwierdzeniem, że:
- wszystkie wymagane operacje zostały zaraportowane;
- wskazano właściwy rodzaj transakcji;
- dane kontrahenta i miejsca prowadzenia działalności są prawidłowe;
- ilości, serie i terminy ważności odpowiadają dokumentom źródłowym;
- raportowany stan jest zgodny ze stanem magazynowym;
- korekta została prawidłowo powiązana z wcześniejszą transakcją;
- dane zostały przekazane za właściwy dzień i przez właściwy podmiot.
System może przyjąć komunikat poprawny pod względem technicznym, którego treść nie odzwierciedla w pełni rzeczywistego przebiegu operacji. Może również nie wykryć, że komunikatu dotyczącego określonego zdarzenia w ogóle nie wysłano.
Dlatego kontrola raportowania nie powinna kończyć się na sprawdzeniu, czy w systemie nie ma komunikatów ze statusem błędnym.
Gdzie naprawdę zaczyna się raportowanie do ZSMOPL?
Proces raportowania rozpoczyna się znacznie wcześniej niż w momencie wysłania komunikatu. Jego jakość zależy przede wszystkim od danych i reguł funkcjonujących w systemie źródłowym.
Znaczenie mają między innymi:
- kartoteki produktów;
- dane kontrahentów i miejsc prowadzenia działalności;
- przypisanie kodów GTIN;
- sposób rejestrowania numerów serii i terminów ważności;
- konfiguracja dokumentów magazynowych;
- mapowanie dokumentów na rodzaje transakcji ZSMOPL;
- moment pobierania danych do komunikatu;
- zasady obsługi korekt, zwrotów i anulowań;
- sposób uzgadniania stanów magazynowych.
Błąd w jednym z tych elementów może być później powielany w kolejnych komunikatach. Jeżeli proces jest w pełni zautomatyzowany, nieprawidłowa konfiguracja może prowadzić do systematycznego przekazywania błędnych danych, mimo że technicznie komunikaty są wysyłane i przyjmowane.
Automatyzacja ogranicza pracę ręczną, ale sama w sobie nie zapewnia zgodności danych.
Pięć obszarów wymagających regularnej kontroli
1. Kompletność komunikatów
Pierwszym krokiem jest sprawdzenie, czy wszystkie operacje podlegające raportowaniu rzeczywiście zostały uwzględnione w komunikatach.
Warto zweryfikować w szczególności:
- czy raportowanie obejmuje wszystkie właściwe dokumenty;
- czy żadne dokumenty nie zostały pominięte;
- czy komunikaty są przekazywane za wszystkie wymagane dni;
- czy raportowanie obejmuje wszystkie miejsca prowadzenia działalności;
- czy po awarii lub przerwie zostały uzupełnione zaległe dane;
- czy nie dochodzi do podwójnego raportowania tych samych operacji.
Brak błędów w przesłanych komunikatach nie pozwala wykryć dokumentów, które nie zostały wysłane.
2. Poprawność danych podstawowych
Kolejnym obszarem są dane wykorzystywane do budowy komunikatów, w szczególności:
- identyfikatory produktów;
- kody GTIN;
- dane kontrahentów;
- identyfikatory miejsc prowadzenia działalności;
- numery serii;
- terminy ważności;
- informacje o dokumentach źródłowych.
Należy sprawdzić nie tylko, czy pola zostały wypełnione, ale również czy pochodzą z właściwych kartotek i odpowiadają dokumentacji operacyjnej.
3. Zgodność transakcji i stanów
Raportowane transakcje powinny prowadzić do stanów odpowiadających rzeczywistej sytuacji magazynowej.
Kontrola powinna umożliwić odpowiedź na pytania:
- czy każda transakcja właściwie zwiększa albo zmniejsza stan;
- czy zastosowano odpowiedni rodzaj transakcji;
- czy ilości wynikające z dokumentów odpowiadają ilościom zaraportowanym;
- czy serie i terminy ważności są przypisane do właściwych pozycji;
- czy stan przekazany do ZSMOPL można uzgodnić ze stanem w systemie magazynowym.
Pojedyncza nieprawidłowość może wpływać na kolejne raportowane stany, dlatego rozbieżności należy analizować w ujęciu chronologicznym.
4. Obsługa zmian i korekt
Szczególnej uwagi wymagają dokumenty modyfikowane po ich pierwotnym zaraportowaniu.
W organizacji powinny istnieć jasne zasady określające:
- które zmiany wymagają wysłania korekty;
- w jaki sposób korekta jest powiązana z dokumentem źródłowym;
- kto odpowiada za jej przygotowanie i sprawdzenie;
- jak postępować z dokumentami anulowanymi;
- jak obsługiwać zmiany dokonane po zamknięciu dnia;
- jak weryfikować rezultat przetworzenia korekty.
Brak spójnego procesu korekt jest częstym źródłem narastających rozbieżności między systemem magazynowym a danymi przekazywanymi do ZSMOPL.
5. Kontrola statusów, błędów i ostrzeżeń
Wysłanie komunikatu nie kończy procesu. Konieczne jest sprawdzenie wyniku jego przetworzenia.
Kontrola powinna obejmować:
- komunikaty błędne;
- komunikaty pozostające bez ostatecznego statusu;
- ostrzeżenia;
- odrzucenia pojedynczych pozycji;
- powtarzające się reguły walidacyjne;
- korekty wysłane w odpowiedzi na wykryte nieprawidłowości.
Ostrzeżenie nie zawsze uniemożliwia przyjęcie komunikatu, ale może sygnalizować problem z jakością danych lub konfiguracją procesu. Powtarzających się ostrzeżeń nie należy więc traktować jako nieistotnych tylko dlatego, że komunikat został przyjęty.
Najczęstsze sygnały ostrzegawcze
Niektóre objawy mogą wskazywać, że proces wymaga dokładniejszej kontroli. Należą do nich między innymi:
- komunikaty pozostawione ze statusem „Błędny”;
- brak regularnej kontroli komunikatów po ich wysłaniu;
- dokumenty zmieniane po zaraportowaniu bez ustalonej procedury korekty;
- powtarzające się ostrzeżenia ignorowane przez użytkowników;
- częste inwentaryzacje wykorzystywane do „naprawiania” rozbieżności;
- brak uzgodnienia danych między magazynem, systemem ERP i ZSMOPL;
- ręczne poprawianie danych bez udokumentowanej przyczyny;
- brak możliwości powiązania komunikatu z dokumentem źródłowym;
- problemy pojawiające się po zmianie konfiguracji albo aktualizacji systemu;
- zależność całego procesu od wiedzy jednej osoby.
Szczególnie ryzykowna jest sytuacja, w której organizacja wie, że komunikaty są wysyłane, ale nie potrafi wykazać, w jaki sposób kontrolowana jest ich kompletność i zgodność z rzeczywistymi operacjami.
Jak przeprowadzić wewnętrzną kontrolę procesu?
Kontrola nie musi od razu obejmować wszystkich danych historycznych. Dobrym punktem wyjścia jest wybór reprezentatywnej próbki dni raportowych i prześledzenie całego procesu od dokumentu źródłowego do danych przekazanych do ZSMOPL.
Krok 1. Wybierz próbkę
W próbce warto uwzględnić zarówno standardowe dni pracy, jak i przypadki mniej typowe, na przykład:
- korekty;
- zwroty;
- zmianę danych dokumentu;
- awarię albo opóźnienie wysyłki;
- inwentaryzację;
- operacje dotyczące kilku serii tego samego produktu.
Krok 2. Porównaj dokumenty z komunikatami
Dla wybranych operacji należy sprawdzić:
- czy dokument został uwzględniony w raportowaniu;
- jaki rodzaj transakcji zastosowano;
- jakie dane produktu, kontrahenta i serii przekazano;
- czy ilości i daty są zgodne z dokumentem;
- jaki status uzyskał komunikat;
- czy wystąpiły błędy lub ostrzeżenia.
Krok 3. Uzgodnij stany
Należy porównać stan wynikający z zaraportowanych transakcji ze stanem w systemie magazynowym. Jeżeli występuje różnica, trzeba ustalić moment jej powstania, zamiast ograniczać się do wyrównania wartości kolejną inwentaryzacją.
Krok 4. Sprawdź proces korekt
Warto przeanalizować kilka zmienionych lub anulowanych dokumentów i sprawdzić, czy odpowiednia informacja została przekazana do ZSMOPL oraz czy korekta została prawidłowo przetworzona.
Krok 5. Zweryfikuj odpowiedzialność
Kontrola powinna również objąć organizację procesu:
- kto sprawdza statusy komunikatów;
- kto analizuje błędy i ostrzeżenia;
- kto wykonuje korekty;
- kto odpowiada za konfigurację systemu;
- kto podejmuje działania podczas awarii;
- czy sposób postępowania został opisany i jest znany osobom zastępującym.
Wyniki kontroli warto zapisać w formie listy ryzyk, przyczyn i rekomendowanych działań. Pozwala to odróżnić pojedynczy błąd użytkownika od problemu systemowego lub procesowego.
Kiedy potrzebny jest pełny audyt?
Podstawowa kontrola wewnętrzna może wystarczyć do wykrycia pojedynczych nieprawidłowości. Pełny audyt warto rozważyć, gdy:
- organizacja zmienia system ERP lub oprogramowanie magazynowe;
- wdrażana jest nowa integracja z ZSMOPL;
- następuje przejęcie, podział albo połączenie podmiotów;
- zmienia się struktura miejsc prowadzenia działalności;
- występują trudne do wyjaśnienia rozbieżności stanów;
- błędy lub ostrzeżenia powtarzają się przez dłuższy czas;
- proces ma zostać zautomatyzowany;
- organizacja przygotowuje się do kontroli;
- nie ma pewności, czy raportowanie obejmuje wszystkie wymagane operacje;
- wiedza o procesie jest rozproszona albo zależy od jednej osoby.
Audyt powinien obejmować nie tylko komunikaty, ale również ich źródło: dane podstawowe, konfigurację dokumentów, mapowanie transakcji, procedury, odpowiedzialności oraz sposób obsługi sytuacji wyjątkowych.
Od czego zacząć?
Nie każda organizacja od razu potrzebuje pełnego audytu. Pierwszym krokiem może być Diagnoza ZSMOPL, która pozwala ocenić najważniejsze obszary ryzyka i ustalić zakres dalszych działań.