Udany import pliku potwierdza, że system potrafił go odczytać. O poprawności danych produkcyjnych świadczy dopiero rezultat: rozpoznane części, właściwe ilości, zachowana struktura i jednoznaczne wersje. Przy przenoszeniu BOM z narzędzia projektowego do ERP warto więc zacząć od ustalenia znaczenia informacji. W przeciwnym razie integracja może działać bez błędu technicznego, a planowanie otrzyma dane wymagające ręcznej naprawy.

Najpierw określ wynik, którego oczekuje produkcja

Model projektowy i dane potrzebne do zarządzania produkcją służą różnym zadaniom. Przedsiębiorstwo powinno ustalić, które elementy modelu mają pojawić się w ERP jako materiały lub podzespoły, a które pełnią inną funkcję. Nie należy zakładać, że każdy obiekt z projektu powinien automatycznie tworzyć osobną kartotekę magazynową.

Znaczenie ma także zakres pierwszego uruchomienia. Import samej struktury nie jest tym samym co przeniesienie dokumentacji, powiązanie wersji i przygotowanie danych do zlecenia. Te rezultaty warto opisać oddzielnie. Pozwala to sprawdzić, co integracja rzeczywiście wykonuje oraz które czynności pozostają po stronie użytkownika. Funkcje oferowane przez konkretny system wymagają potwierdzenia w jego konfiguracji i uzgodnionym sposobie wdrożenia.

Identyfikacja części poprzedza mapowanie pól

Najważniejsze pytanie dotyczy rozpoznania tej samej części w obu środowiskach. Nazwa opisowa może się zmienić, zawierać skrót albo występować przy kilku różnych elementach. Potrzebna jest reguła oparta na identyfikatorze, którego znaczenie jest uzgodnione przez osoby odpowiedzialne za dane.

Trzeba także wiedzieć, czy oznaczenie identyfikuje sam element, czy określoną wersję jego wykonania.

Warto przetestować sytuację, w której część już istnieje w ERP. Integracja powinna zachować się zgodnie z ustaleniem: odszukać właściwy rekord, zgłosić rozbieżność lub przekazać sprawę do weryfikacji. Automatyczne tworzenie nowej kartoteki przy każdym braku dokładnego dopasowania może prowadzić do rozdzielenia danych jednego elementu między kilka rekordów. Z kolei dopasowanie jedynie po podobieństwie nazw wymagałoby kontroli, zanim zostałoby użyte do pracy.

Uzgodnienie odpowiedzialności jest tu równie potrzebne jak tabela pól. Kto nadaje numer nowej części? Kto rozstrzyga konflikt oznaczeń? Kto zatwierdza dane wymagane przez ERP, których projektant nie wprowadza w CAD? Takie przypadki powinny mieć właściciela i określoną ścieżkę obsługi przed uruchomieniem codziennego importu.

Jednostki i ilości trzeba porównać na przykładzie

To samo oznaczenie pola nie gwarantuje tej samej interpretacji. Ilość może dotyczyć jednego zespołu albo całego zestawienia, a materiał może być opisany jednostką inną niż używana w kartotece docelowej. Dlatego dla każdej przenoszonej wartości trzeba znać jej podstawę i sposób przeliczenia. Warto zapisać również zasady dotyczące dokładności i zaokrągleń.

Przykładowy test może obejmować wyrób zawierający dwa podzespoły, z których każdy potrzebuje trzech identycznych elementów. Po rozwinięciu struktury na jeden wyrób przypada sześć takich elementów. Jeżeli eksport zawiera już ilość łączną, ponowne pomnożenie jej przez liczbę podzespołów da błędny wynik. Ten prosty przypadek pomaga ustalić znaczenie pól bez posługiwania się dużym, trudnym do prześledzenia projektem.

Przed zatwierdzeniem mapowania należy uzgodnić:

• jednostkę każdej ilości i dopuszczalne przeliczenia między systemami;
• informację, czy ilość odnosi się do pozycji nadrzędnej, czy do całego wyrobu;
• sposób zapisu wartości ułamkowych oraz reguły zaokrąglania;
• postępowanie z brakiem wartości, zerem i danymi odrzuconymi przez walidację.

Nie warto uzupełniać brakujących ilości wartością domyślną tylko po to, aby zakończyć import. Jeśli taka reguła ma istnieć, musi mieć uzasadnienie i jednoznaczny zakres. Użytkownik powinien móc rozpoznać, które dane pochodzą z projektu, a które zostały wyznaczone podczas przetwarzania.

Struktura płaska i wielopoziomowa dają inne informacje

Eksport zbiorczy może pokazywać sumę wystąpień części, lecz nie odtwarzać relacji między zespołami. Zestawienie z hierarchią pozwala zachować te relacje, o ile odpowiednio odczyta je mechanizm importu. Przed wyborem formatu trzeba ustalić, jaki układ jest potrzebny w procesie docelowym i jakie dane rzeczywiście zawiera plik źródłowy.

Przydatny jest test powtarzającego się podzespołu. Należy sprawdzić, czy po imporcie występuje on we właściwych miejscach, z odpowiednimi ilościami i składnikami. Osobno warto przetestować pozycję wyłączoną z danego wariantu projektu. Integracja nie powinna przenosić jej do zakresu produkcji tylko dlatego, że pozostaje widoczna w szerszym zestawieniu projektowym. Sposób obsługi wariantów trzeba jednak oprzeć na faktycznych możliwościach używanych narzędzi.

Kontekst wykorzystania danych konstrukcyjnych w planowaniu przedstawia artykuł: https://dlaprodukcji.pl/lista-materialowa-bom-jako-podstawa-planowania-i-realizacji-produkcji/. Przy projektowaniu integracji pomaga on ustalić, dokąd trafiają informacje z BOM i dlaczego błąd w relacji między elementami może wymagać sprawdzenia dalszych danych produkcyjnych.

Ponowny import i zmiana wersji to osobne scenariusze

Pierwszy zapis danych nie pokazuje jeszcze, jak mechanizm zachowa się przy kolejnym uruchomieniu. Trzeba ustalić, czy ponowne przesłanie tego samego zestawu aktualizuje istniejący wynik, zostaje pominięte, czy tworzy nowy obiekt. Oczekiwane zachowanie należy potwierdzić w testach, zwłaszcza po przerwaniu połączenia lub częściowym przetworzeniu pliku.

Zmiana wersji wymaga dodatkowej decyzji o zakresie aktualizacji. Nowy projekt nie powinien bez uzgodnienia zmieniać danych wykorzystywanych przez już realizowane zlecenia. Test musi zatem objąć zarówno utworzenie kolejnej wersji, jak i zachowanie informacji potrzebnych do odtworzenia wcześniejszego wykonania.

Należy też wskazać moment zatwierdzenia danych do produkcji oraz osobę odpowiedzialną za tę decyzję.

Odbiór integracji powinien obejmować wyjątki

Do próby warto wybrać kilka małych, zrozumiałych struktur oraz jeden rzeczywisty przykład o większej złożoności. Oprócz poprawnego przebiegu trzeba sprawdzić brak numeru części, konflikt jednostek i niedostępność wymaganej kartoteki. Dla każdego przypadku należy określić, co użytkownik zobaczy, jakie dane zostaną zapisane i jak będzie można bezpiecznie dokończyć pracę.

Wynik odbioru powinien pozwalać porównać dane źródłowe z zapisanymi w ERP: pozycje, relacje, ilości i wersje. Dopiero taki zapis stanowi punkt odniesienia przy późniejszej aktualizacji integracji. Jeśli po zmianie mapowania pojawi się rozbieżność, zespół będzie mógł odtworzyć konkretny przypadek i ustalić przyczynę, zamiast zaczynać od pytania, jak mechanizm działał podczas wdrożenia.

Publikacja przygotowana we współpracy