Przy kilkunastu produktach braki można jeszcze sprawdzać ręcznie. Przy setkach SKU ten sam model prowadzi do duplikatów, nieaktualnych plików i decyzji, których nie da się odtworzyć. Skalowanie dokumentacji GPSR nie polega na tworzeniu większego arkusza. Wymaga rozdzielenia danych wspólnych, danych wariantu, dowodów i zadań.
Najpierw katalog referencyjny
Każdy produkt powinien mieć stabilny identyfikator wewnętrzny, nazwę, wariant, status i powiązania z producentem, dostawcą oraz rynkiem. Dane nie powinny zależeć od tytułu oferty, który może się zmieniać. SKU jest punktem wejścia, ale nie zawsze odpowiada jednemu technicznie odrębnemu produktowi.
Przed migracją warto wykryć duplikaty, puste identyfikatory i rekordy łączące kilka wariantów. Import nie powinien automatycznie uznawać danych za zatwierdzone. Powinien utworzyć kontrolowaną listę rekordów i wskazać problemy wymagające decyzji człowieka.
Rodziny produktów bez bezpodstawnego kopiowania
Rodzina pozwala współdzielić dane rzeczywiście wspólne: producenta, część instrukcji, raport obejmujący serię albo opis konstrukcji. Jednocześnie trzeba zachować różnice wariantów, takie jak moc, materiał, wymiary, akcesoria czy grupa użytkowników. Reguła dziedziczenia powinna być widoczna i uzasadniona.
Największym ryzykiem automatyzacji jest przypisanie dowodu do produktu tylko dlatego, że nazwa wygląda podobnie. System powinien wymagać określenia zakresu dokumentu i pozwalać wyłączyć wariant. Współdzielenie ma zmniejszać pracę, a nie ukrywać brak oceny.
Około 100 SKU - uporządkowanie podstaw
Na tym poziomie firma zwykle może wykonać ręczny przegląd każdego produktu, jeśli korzysta ze wspólnego schematu. Priorytetem jest kompletność podstawowych danych, rozdzielenie plików od decyzji i przypisanie odpowiedzialności. Dobrze działa tablica braków z terminami i filtrami według dostawcy.
Warto zacząć od produktów aktywnie sprzedawanych, produktów o większym ryzyku i ofert generujących największy obrót. Produkty archiwalne powinny pozostać dostępne ze względu na historię, ale nie muszą blokować pracy nad bieżącym katalogiem.
Około 500 SKU - proces zamiast indywidualnych wiadomości
Przy tej skali korespondencja z dostawcami wymaga szablonów, statusów i ponowień. Prośba powinna wskazywać produkty i oczekiwane materiały. Odpowiedź musi trafić do konkretnego rekordu, a nie tylko do folderu nazwanego nazwą kontrahenta.
Potrzebne są role użytkowników oraz kolejki przeglądu. Osoba zbierająca plik nie musi mieć uprawnienia do zatwierdzenia jego znaczenia. Rozdzielenie odbioru, weryfikacji i akceptacji ogranicza sytuacje, w których niezweryfikowany dokument staje się podstawą publikacji.
Około 2000 SKU - zmiany i wyjątki
Przy dużym katalogu nie da się codziennie przeglądać wszystkich rekordów. System powinien kierować uwagę na zmianę: nowy wariant, wygasający dowód, brak języka, zmianę dostawcy, incydent albo produkt bez właściciela. Raport kompletności powinien prowadzić do konkretnego zadania.
Znaczenia nabiera wersjonowanie zbiorcze i mierzenie jakości danych. Warto wiedzieć, ile produktów ma zatwierdzoną analizę, ile korzysta z dokumentu bez określonego zakresu i ile oczekuje na odpowiedź dostawcy. Wskaźnik nie może jednak automatycznie ogłaszać zgodności prawnej.
Model danych, który skaluje się lepiej niż foldery
- produkt i wariant,
- rodzina produktów,
- podmioty i ich role,
- rynek oraz język,
- instrukcja i ostrzeżenia,
- dowód ze wskazanym zakresem,
- analiza ryzyka i jej rewizja,
- prośba do dostawcy,
- decyzja z autorem i datą,
- dokument wyjściowy zachowujący źródła.
Rozdzielenie tych elementów pozwala aktualizować dane wspólne bez nadpisywania historii produktu. Ułatwia też wykrycie, które rekordy rzeczywiście korzystają ze zmienionego źródła.
Migracja partiami
Nie trzeba przenosić całego katalogu jednego dnia. Lepszy jest pilotaż na reprezentatywnej grupie produktów, poprawienie modelu, a następnie import partiami według kategorii lub dostawcy. Każda partia powinna mieć raport błędów i możliwość powtórzenia bez tworzenia duplikatów.
Po imporcie trzeba porównać liczbę rekordów, relacje, pliki i statusy. Szablon jest punktem startowym, nie dowodem, że wszystkie dane w źródle były prawidłowe. Dlatego import powinien zostawić ślad i wymagać świadomego zatwierdzenia.
Twarde limity i przewidywalna praca
Jeżeli pakiet określa maksymalną liczbę aktywnych SKU lub użytkowników, limit powinien być egzekwowany przed utworzeniem kolejnego rekordu. Nie powinien prowadzić do ukrytych dopłat. Użytkownik musi widzieć wykorzystanie i wiedzieć, co może zarchiwizować albo jaki pakiet wybrać.
GPSR / PPWR wspiera taki kontrolowany model. Celem nie jest automatyczne wydanie werdyktu, lecz uporządkowanie danych, źródeł i kolejnych działań niezależnie od wielkości katalogu.
Najważniejsze jest zachowanie tej samej logiki przy każdej skali: najpierw identyfikacja, później źródła i ocena, a dopiero na końcu zatwierdzony dokument.