Part Submission Warrant (PSW) działa jak okładka całego PPAP. Streszcza, co wysyłasz, dlaczego to wysyłasz i na jakiej podstawie mówisz: „jesteśmy gotowi do produkcji seryjnej”. Z definicji podsumowuje dokumentację PPAP i zwykle jest wymagany dla każdego numeru części, o ile klient nie ustali inaczej.

A teraz najważniejsze: PSW jest krótki, ale konsekwencje błędnego wypełnienia już niekoniecznie. Rozjazd numeru części, poziomu submission (poziom przedłożenia), rewizji rysunku albo brak sensownego uzasadnienia „reason for submission” potrafi zablokować akceptację, nawet jeśli reszta dokumentów jest w miarę ogarnięta.

W tym artykule jedziemy po konkretach i błędach, ale najpierw ustawmy bazę: czym PSW jest (a czym nie jest), co realnie deklarujesz podpisem i na co patrzy klient, zanim da „Approved”.

Part Submission Warrant w praktyce: co to jest i po co Ci ten dokument

PSW = streszczenie PPAP (i formalna deklaracja dostawcy)

Najprościej: PSW to formularz, który podsumowuje całą paczkę PPAP. Najczęściej jest to jedna strona, która zbiera najważniejsze informacje o części, produkcji, powodzie submission i poziomie dokumentów, które dostarczasz klientowi.

I tu wchodzi słowo „warrant” – czyli gwarant. Nie „wysyłam, bo kazali”, tylko: „gwarantuję, że te próbki są reprezentatywne i zostały wykonane procesem, który spełnia wymagania PPAP; gwarantuję też, że były zrobione przy określonym cyklu produkcyjnym”.

W praktyce podpis pod PSW oznacza mniej więcej tyle:

• wysłane próbki nie są „specjalnie wyselekcjonowane” (kiedyś na szkoleniu od jednego z uczestników usłyszałem określenie „najładniejsze cukierki”), tylko pochodzą z procesu definitywnego, który ma działać seryjnie,

• wyniki (z całej dokumentacji) spełniają wymagania zapisu lub zapisów konstrukcyjnych – a jeśli nie, to piszesz to wprost i opisujesz odchyłkę,

• masz dowody w dokumentacji i jesteś w stanie je pokazać.

To dlatego Part Submission Warrant jest pierwszym filtrem. Klient czyta go, żeby sprawdzić, czy submission ma sens i czy formalnie „trzyma się kupy”, zanim ktoś zacznie weryfikować raporty pomiarowe i resztę załączników.

PSW nie jest „podpisem klienta na Twoją jakość”

Druga sprawa, o której wiele osób zapomina: jeśli klient podpisuje PSW po swojej stronie, to nie bierze odpowiedzialności za Twoje dane. Są firmy, które mówią wprost: akceptacja PSW oznacza, że dokumentacja i fizyczne próbki zostały przyjęte do procesu akceptacji, ale dostawca odpowiada za zawartość i poprawność tego, co wysłał.

Czyli: nawet przy „Approved” nadal warto mieć z tyłu głowy, że PSW to Twoja deklaracja. Jeśli coś jest przekłamane albo „naciągnięte”, to to wróci. Zwykle prędzej niż później.

Co klient widzi na PSW (i czego szuka od razu)

PSW ma sporo pól, ale kilka z nich ma „pierwszeństwo przejazdu”, bo od razu wyłapują niespójności. Przykładowo, w typowym opisie PSW (PPAP context) pojawiają się takie obszary jak:

• numer części klienta / nazwa części,

• poziom zmiany na rysunku i data zatwierdzenia,

• powód submission (initial, zmiana konstrukcyjna, zmiana narzędzia, zmiana źródła materiału, dodatkowa lokalizacja itd.),

• poziom submission (Level 1–5),

• sekcja deklaracji.

Zwróć uwagę na jedno: te pola są mocno „integracyjne”. One dotykają rysunku, poziomu zmiany, jakości, czasem logistyki. Właśnie dlatego PSW często obnaża chaos w firmie szybciej niż audyt.

Submission levels: skąd się biorą i czemu tu jest tyle nieporozumień

W PSW wpisujesz Requested Submission Level – czyli czego klient oczekuje w paczce. I tak: Level 1 to zwykle „PSW only”, a Level 3 to „PSW + próbki + komplet dokumentów”, Level 5 to „komplet dostępny do wglądu u dostawcy”.

Najczęstsze nieporozumienie? Że ktoś myśli: „Level 1 = mam spokój, wysyłam jedną kartkę”. A potem klient pyta o dowody i temat wraca jak bumerang, bo w wielu organizacjach „Level 1” oznacza tylko zakres wysyłki, a nie brak obowiązku posiadania reszty dokumentacji po stronie dostawcy. (Po prostu tego nie wysyłasz w mailu, ale masz to mieć w systemie).

Pro Tip!

Jeśli masz w firmie sytuację „PSW robi jakość, resztę robi inżyniering”, to zrób jeden prosty ruch: przed wysyłką PSW przejdź po numerach: rysunek / poziom zmian (klienta i wewnętrzny organizacji jeśli ma zastosowanie. Brzmi banalnie, ale może pojawić się rozjazd – i to taki, który potem nikt nie chce „brać na siebie”.

Po co to wszystko? Bo PPAP ma potwierdzić produkcję seryjną, a nie prototyp

Organizacja AIAG opisuje PPAP jako standard branżowy związany z tym, żeby dostawca potrafił produkować część stabilnie podczas rzeczywistego uruchomienia produkcji, przy tempie produkcji seryjnej i zgodnie z zapisami konstrukcyjnymi/specyfikacją.

PSW spina to w jedną deklarację: „tak, to jest z procesu seryjnego” i „tak, mamy dowody w dokumentacji”.

I teraz, mając tę bazę, możemy iść dalej do błędów. Bo większość problemów z PSW nie bierze się z niewiedzy o PPAP, tylko z pośpiechu, kopiuj–wklej między projektami i z tego, że PSW dotyka kilku działów naraz.

Błąd nr 1: Submission level wpisany „z głowy”

To jest klasyk: PSW wygląda dobrze, numer części się zgadza, ktoś nawet dopiął podpisy… i nagle klient odpisuje, że brakuje dokumentów. Albo że wysłałeś za dużo rzeczy, ale w złym trybie. A wszystko zaczyna się od jednego pola: Requested Submission Level.

Submission level to nie jest „co ja mam pod ręką” ani „jak robiliśmy ostatnio”. To jest konkretne oczekiwanie klienta. I jeśli tu jest rozjazd, reszta paczki często przestaje mieć znaczenie, bo klient nie wie, według jakiej logiki ma to oceniać.

Jak to wygląda w mailach od klienta (objaw)

Poniżej masz typowe odpowiedzi, które przychodzą, gdy submission level się nie zgadza (albo nie jest uzgodniony):

• „Please resubmit as Level 3. Current package is incomplete.”

• „We requested Level 2. Why did you send Level 1 only?”

• „Level 1 accepted for PSW submission, but supporting documents must be available. Please confirm you have them.”

• „Submission level not aligned with our CSR / PO. Please correct PSW.”

Czasem klient nie napisze wprost „submission level jest zły”. Po prostu zacznie dopytywać o brakujące elementy: raport wymiarowy, MSA, capability, wyniki materiałowe… i nagle robisz „dogrywkę z wysyłką”, potem kolejną, potem jeszcze jedną.

Co się dzieje dalej (ryzyko i koszt w praktyce)

Najczęściej mamy w tedy do czynienia z trzema konsekwencjami:

• stop w akceptacji – klient nie idzie dalej, bo submission level nie pasuje do tego, co dostał,

• lawina doprecyzowań – zamiast jednego zamknięcia tematu masz serię maili i rework dokumentów,

• przesunięcie terminu – bo klient ocenia dopiero, gdy submission jest kompletny w oczekiwanym formacie.

Ważny szczegół: nawet jeśli u Ciebie w firmie „Level 1” oznacza „wysyłamy tylko PSW”, to u klienta często oznacza: „wysyłasz PSW, ale resztę dokumentacji masz mieć gotową do wglądu, gdy poprosimy”. Jeśli Ty to rozumiesz inaczej, robi się zamieszanie.

Co sprawdzić w 2 minuty przed wysyłką (bez przekopywania SharePointa)

Zrób sobie taki mini-rytuał. Dwie minuty, serio.

Krok 1: Skąd w ogóle masz submission level?
Otwórz request/portal klienta i znajdź jedno zdanie, które mówi o levelu. Jeśli nie ma – nie wymyślaj. To jest moment na doprecyzowanie.

Krok 2: Czy PSW jest w formacie klienta?
Niektórzy klienci akceptują standardowy PSW, inni chcą swój. Jeśli nie jesteś pewien, sprawdź w CSR, CR’ach albo w ich instrukcji PPAP.

Krok 3: Czy to, co wysyłasz, pasuje do levelu?
Nie „czy masz”, tylko „czy wysyłasz” (albo czy masz dostępne do wglądu, jeśli to ten tryb).
Tu najczęściej wychodzą kwiatki: PSW mówi „Level 3”, a w paczce nie ma np. raportu wymiarowego albo Plan Kontroli jest sprzed zmiany.

Krok 4: Czy level jest spójny z powodem submission?
Initial submission i zmiana materiału to zwykle inna rozmowa niż „re-submission po odrzucie” albo „deviation”. Klient często oczekuje innego zakresu dowodów.

Krok 5: Jedno zdanie do klienta (jeśli cokolwiek jest niejasne)
Zamiast strzelać levelem: doprecyzuj. To oszczędza później trzy rundy „resubmit”.

Mini-check wewnętrzny: kto ma dać „OK” na submission level

Tu problem często nie jest po stronie klienta, tylko u Ciebie: każdy ma inną wersję prawdy. Prosty układ, który działa:

• Kto ustala level: osoba, która ma wgląd w request/CSR klienta (często SQE/QA/Supplier Quality po stronie dostawcy).

• Kto potwierdza zakres paczki: osoba składająca PPAP (bo wie, co faktycznie jest gotowe i w jakiej rewizji).

• Kto daje zielone światło: ktoś, kto podpisuje PSW (bo podpis to odpowiedzialność).

Jeśli te role mieszają się w jednej osobie – super. Jeśli są rozdzielone, to przynajmniej wiesz, gdzie powstaje rozjazd.

Błąd nr 2: Part Submission Warrant niepodpisany albo podpis „nie tej osoby”

To jest ten typ błędu, który boli najbardziej, bo nie ma nic wspólnego z jakością detalu (ja to kolokwialnie nazywam: głupia reklamacja – zgłoszenie jest ale bez zareklamowanej ilości części). Masz komplet dokumentów, próbki wyszły ładnie (i oby tak przez cały projekt :)), wszystko wydaje się dopięte… a klient odpisuje po 3 minutach: Rejected – missing signature.

I tak, zdarza się częściej niż ludzie chcą przyznać. Najczęściej w dwóch sytuacjach: ktoś wysyła PPAP „na szybko”, albo PSW krąży między działami i finalnie ląduje w mailu w wersji „prawie gotowej”.

Jak to wygląda w mailach od klienta (objaw)

Typowe wiadomości:

• „PSW is not signed. Please resubmit.”

• „Warrant must be signed by an authorized quality representative.”

• „Signature missing / date missing / name not legible.”

• „Submitted PSW is a draft version.”

Klient czasem nie wchodzi w dyskusję. Po prostu zamyka submission i czeka na poprawkę, bo PSW bez podpisu nie jest dla niego dokumentem.

Co się dzieje dalej (ryzyko i koszt w praktyce)

• Natychmiastowy stop – bez podpisu klient często nie rusza dalej, bo formalnie nie ma deklaracji dostawcy.

• Resubmission = nowy obieg – w części firm oznacza to nowe zgłoszenie w portalu, nowe daty, czasem nawet nowy „case”.

• Ryzyko niezgodnej wersji – gdy PSW wraca do poprawy, łatwo wysłać inną wersję plików niż ta, którą klient już pobrał (a potem pojawia się pytanie: „czemu revision się zmieniła?”).

Dlaczego to się dzieje (najczęstsze przyczyny)

• PSW jest traktowany jak „cover page” i ląduje na końcu, gdy wszyscy są już zmęczeni tematem.

• Brak jasnej zasady: kto podpisuje – jakość, kierownik jakości, pełnomocnik, project quality? W zależności od firmy to bywa różnie. Najlepiej zdefiniować to w wewnętrznej procedurze działu nowych uruchomień lub jakości zewnętrznej. Oczywiście jeśli nie istnieje procedura korporacyjna.

• Podpis elektroniczny vs skan – ktoś wstawia obrazek podpisu bez daty, ktoś inny robi PDF, w którym podpis „znika” po konwersji.

• Portal klienta – wrzucasz PSW, ale system wymaga podpisu w konkretnym polu / w konkretnym formacie.

Jak tego uniknąć (konkret: co sprawdzić przed wysyłką)

Zrób sobie checklistę „PSW podpis” i trzymaj ją przy wysyłce. Bez dyskusji, bez wyjątków.

Krok 1: Czy PSW ma podpis i datę?

• podpis osoby upoważnionej (nie „kto akurat był pod ręką”)

• data podpisu

• imię i nazwisko czytelne (czasem klient tego wymaga, bo skan podpisu nic mu nie mówi)

Krok 2: Czy podpis jest po stronie dostawcy tam, gdzie trzeba?
Na PSW są zwykle pola po stronie dostawcy i klienta. Ty odpowiadasz za swoją część. Klient swoją wypełni (albo nie) w zależności od procesu.

Krok 3: Czy to jest finalna wersja pliku?
Prosta zasada nazewnictwa pliku pomaga, np.:
PSW_PN12345_RevC_FINAL_signed.pdf
Bo inaczej w mailu ląduje „PSW_draft_v7_final2.pdf” i wszyscy udają, że jest ok.

Krok 4: Czy podpis nie „rozjechał” PDF-a?
To brzmi śmiesznie, ale przy konwersjach potrafią zniknąć elementy: podpis w warstwie, data w komentarzu, pieczątka poza marginesem. Otwórz PDF po zapisaniu i sprawdź go jak klient: na ekranie, bez edycji.

Błąd nr 3: Niespójność Part Submission Warrant vs reszta PPAP (PFMEA / Control Plan / raport wymiarowy)

To jest ten typ problemu, gdzie klient patrzy na PSW, potem otwiera raport wymiarowy, potem Control Plan… i po dwóch minutach widzi, że dokumenty żyją w różnych czasoprzestrzeniach. Najczęściej rozjeżdżają się dwie rzeczy:

• rewizje / daty (Part Submission Warrant mówi „Rev D”, a PFMEA/CP są z Rev C),

• tolerancje / charakterystyki (na rysunku jest zmiana, a raport trzyma się poprzedniej rewizji rysunku – albo masz inną metodę pomiaru niż w wymaganiu).

Jak to wygląda w realu (objaw)

• Part Submission Warrant ma aktualny numer rysunku i rewizję, a PFMEA i Plan Kontroli są sprzed zmiany.

• Na rysunku pojawiła się nowa cecha (albo zmieniła tolerancja), a w raporcie wymiarowym:

  • tej charakterystyki nie ma wcale,

  • jest, ale ma starą tolerancję,

  • jest, ale numeracja charakterystyk nie pasuje do ballooningu.

• CP mówi o kontroli charakterystyki „co godzinę”, a w raporcie masz pomiary z jednego ustawienia „na start”.

To nie są „duże” błędy, ale mogą wyjść przy zwykłym przeglądzie spójności.

Co z tego wynika (ryzyko)

To jest jeden z najbardziej klasycznych powodów odrzutu PPAP: klient nie ocenia wtedy Twojego detalu, tylko wiarygodność paczki. Jeśli dokumenty się rozjeżdżają:

• SQE ma sygnał: „proces nie jest pod kontrolą albo dokumentacja nie nadąża za zmianami”,

• temat wraca do poprawy i robisz kolejną rundę dokumentów: „proszę zaktualizować PFMEA/CP i przesłać ponownie”,

• czasem pojawia się dodatkowe pytanie: „czy próbki były robione po tej zmianie, czy jeszcze przed?”

I w tym momencie robi się nerwowo, bo zwykle nikt nie chce brać odpowiedzialności za to, że „to był tylko update w dokumentach”.

Jeśli chcesz wejść głębiej w temat i przejść APQP/PPAP krok po kroku na praktycznych przykładach, serdecznie zapraszam na szkolenie Zaawansowane planowanie jakości wyrobu APQP oraz proces zatwierdzania części produkcyjnych PPAP.

Dariusz Kowalczyk

Bibliografia:

1. Production Part Approval Process (PPAP), Fourth Edition. March 2006 (PPAP-4:2006). Effective June 1, 2006 – 4th Edition