Wymagania jakościowe w automotive potrafią wyglądać prosto, ale w praktyce to właśnie na etapie wdrażania pojawia się najwięcej błędów. Firma aktualizuje dokumenty, robi szkolenia i zamyka działania w systemie, a potem przychodzi audit, reklamacja albo problem przy PPAP i wychodzi, że proces działa inaczej niż zakładano.

Dlaczego wymagania jakościowe w automotive sprawiają firmom tyle problemów

Same wymagania nie są zwykle największym kłopotem.

Większy problem pojawia się wtedy, gdy firma nie potrafi przełożyć ich na konkretne działanie. Trzeba przecież ustalić, kto odpowiada za wdrożenie, co ma się zmienić w procesie, jaki dowód pokaże skuteczność i kto będzie pilnował dalszego utrzymania.

W wielu organizacjach wymagania jakościowe są znane, ale nie są dobrze powiązane z codzienną pracą firmy. Jedna część organizacji patrzy na dokumentację klienta, druga na CSR, trzecia na projekt, a czwarta na produkcję. Każdy widzi swój fragment, ale nikt nie spina całości.

Efekt jest prosty. Wymaganie istnieje, ale nie działa tak, jak powinno.

Wymagania jakościowe w automotive a dokumenty, które nie zmieniają procesu

Taaa. To jeden z częstszych błędów.

Po analizie wymagania ktoś poprawia procedurę, aktualizuje formularz albo wrzuca nową instrukcję do systemu. Formalnie wszystko wygląda dobrze. Jest nowa rewizja, jest zapis, jest ślad.

Tyle że proces dalej działa po staremu.

Operator pracuje według poprzedniego standardu. Lider zmiany nie zna nowych zasad reakcji. Inżynier procesu nie zaktualizował parametrów, planu kontroli albo działania po zrealizowanym audycie LPA. Dział logistyki postępuje tak jak wcześniej, bo nikt nie pokazał, że zmiana dotyczy też ich obszaru.

To właśnie wtedy wychodzi typowy rozdźwięk: dokument mówi jedno, a proces robi drugie.

W praktyce wymagania jakościowe bardzo często przegrywają właśnie na tym etapie. Firma uznaje, że skoro plik został poprawiony, to sprawa jest zamknięta (trochę wieje patologia – prawda?). A przecież aktualizacja dokumentu to dopiero początek.

Dobre pytanie kontrolne brzmi tak:
co dokładnie zmieniło się w działaniu procesu po wdrożeniu wymagania?

Jeżeli odpowiedź jest niejasna, to wdrożenie najpewniej zatrzymało się na papierze.

CSR przeczytane raz i odłożone na bok bo przecież to robota „jakości”

To następny błąd, który wraca regularnie.

Customer Specific Requirements są często analizowane na początku współpracy z klientem, przy nowym projekci. Ktoś robi przegląd, tworzy listę i temat trafia do archiwum. Na jakiś czas wszyscy mają spokój, do momentu, aż klient zmieni formularz, sposób raportowania, oczekiwania wobec APQP, PPAP, audytów albo zarządzania zmianą.

Nagle okazuje się, że organizacja pracuje według starych założeń.

Właśnie dlatego wymagania jakościowe nie mogą być traktowane jak jednorazowa analiza. Jeżeli firma nie monitoruje zmian, to wcześniej czy później temat wróci przy audicie klienta, odrzuconym PPAP albo przy eskalacji. Tu nie potrzeba rozbudowanego systemu.

Potrzebne są trzy proste rzeczy:

• właściciel monitorowania zmian,
• ustalony rytm przeglądu,
• jasna ścieżka przekazania zmian do odpowiednich działów.

Bez tego organizacja żyje w przekonaniu, że temat jest pod kontrolą, choć w praktyce kontrola dawno się skończyła.

Jakość nie wdroży wszystkiego sama

Najczęściej to dział jakości zbiera wymagania (lub służby centralne), przygotowuje matryce, organizuje spotkania, wysyła przypomnienia i próbuje spiąć całość. Problem w tym, że spora część działań nie kończy się w jakości. Przykłady dla innych działów:

• Produkcja ma zmienić sposób pracy.
• Technologia ma zaktualizować parametry, instrukcje i środki nadzoru.
• Logistyka ma wdrożyć inny sposób oznaczenia lub zabezpieczenia materiału.
• Zakupy mają przenieść wymagania w łańcuchu dostawców.
• Project manager ma zamknąć temat w harmonogramie uruchomieniowym.

Jeżeli wszystko zostaje po stronie jakości, bardzo szybko pojawia się znany scenariusz: wszyscy zakładają, że ktoś już to prowadzi. A skoro „ktoś” prowadzi, to nikt nie czuje się właścicielem po stronie procesu.

W takich sytuacjach wymagania zaczynają krążyć między działami, ale nie przekładają się na konkretne działania. Jakość może koordynować. To ma sens. Ale wdrożenie w procesie powinien prowadzić właściciel procesu.

Bez tego odpowiedzialność robi się zbiorowa, a zbiorowe tematy lubią stać w miejscu.

APQP śpi, PPAP biegnie sprintem

Na początku nowego uruchomienia każda firma organizuje spotkania z zespołem wdrożeniowym. Wszystko wydaje się pod kontrolą, do momentu wysyłki PPAP – i zaczyna się nerwowe kompletowanie braków.

Może brakować części zapisów. PFMEA i Control Plan nie są ze sobą spójne. Część walidacji została zrobiona, ale nie wszystko jest dobrze udokumentowane (witamy w świecie inżynieringu). Niektóre decyzje zapadły, tylko nikt nie zostawił po nich śladu. Dokumentacja powstaje na końcówce, byle zamknąć termin.

To zwykle oznacza, że APQP było traktowane jako obowiązek formalny, a nie jako sposób prowadzenia projektu.

W takich sytuacjach wymagania jakościowe w automotive pojawiają się w projekcie za późno. Nie prowadzą działań od początku, tylko wracają wtedy, gdy klient już oczekuje dowodów.

Czasem taki PPAP uda się wysłać. Tyle że problem wraca później. Przy SOP, przy pierwszych reklamacjach, przy pytaniach klienta, przy wewnętrznych problemach z powtarzalnością procesu lub analizie zwrotów gwarancyjnych.

PFMEA mówi jedno, Control Plan drugie, instrukcja trzecie

To błąd, który bardzo szybko wychodzi przy audicie procesu.

PFMEA opisuje ryzyka i środki nadzoru. Control Plan pokazuje punkty kontroli. Instrukcja stanowiskowa mówi operatorowi, co ma zrobić. Audit procesu powinien sprawdzić, czy to wszystko działa razem.

A teraz praktyka: zmienia się proces, ale zaktualizowany zostaje tylko jeden dokument. Drugi zostaje na później. Trzeci nikt nie rusza, bo „przecież był poprawiany niedawno”. Efekt? Ten sam proces jest opisany na kilka różnych sposobów.

Na audicie wygląda to źle. Na hali jeszcze gorzej, bo pracownik dostaje niespójne informacje i później odpowiada za proces, który sam system opisał niespójnie.

Dobrze wdrożone wymagania jakościowe powinny być powiązane z całym pakietem dokumentów procesu, a nie tylko z jednym plikiem. Jeżeli zmiana dotyczy procesu, to trzeba spojrzeć szerzej niż na pojedynczą instrukcję. Tu dobrze działa prosta zasada: po każdej zmianie procesu uruchamiaj przegląd całego pakietu powiązanych dokumentów – więcej informacji znajdziesz w zarządzaniu zmianą.

Audity sprawdzają papier, a nie skuteczność

Bywa tak, że audit jest zamknięty bez większych uwag, a kilka dni później pojawia się reklamacja. Wtedy pojawia się pytanie: co tak naprawdę zostało sprawdzone? Jeżeli audit skupia się głównie na tym, czy dokument istnieje, czy podpis jest na miejscu i czy formularz został wypełniony, to bardzo łatwo ominąć to, co dzieje się naprawdę w procesie.

To samo dotyczy LPA (audyty wielopoziomowe – Layered Process Audits). Jeżeli pytania auditowe nie wynikają z ryzyk, wcześniejszych problemów, zmian procesu albo reklamacji, audit zaczyna działać jak rytuał. Jest wykonany, raport jest gotowy, ale wpływu na proces nie widać.

A przecież wymagania jakościowe powinny być sprawdzane nie tylko na poziomie dokumentu, ale też na poziomie działania. Ludzie muszą wiedzieć, co robić. Reakcje muszą być jasne. Zapisy muszą mieć sens. Audit powinien pokazać, czy system rzeczywiście działa.

Audit, który niczego nie zmienia, szybko staje się obowiązkiem do odhaczenia.

Lessons learned zatrzymują się na jednym problemie

To jeden z bardziej irytujących scenariuszy. Problem został rozwiązany. 8D zamknięte. Klient dostał odpowiedź. Działania są wpisane. Na pierwszy rzut oka temat nie istnieje. Następnie po kilku miesiącach ten sam typ wady powraca. W innym projekcie lub u innego klienta.

To zwykle oznacza, że organizacja zamknęła temat lokalnie, ale nie przeniosła wniosków szerzej. Nie sprawdziła, gdzie działa ten sam mechanizm ryzyka. Nie rozszerzyła działań. Nie poprawiła standardu. W efekcie firma drugi raz płaci za tę samą lekcję.

Właśnie tu wymagania jakościowe powinny łączyć się z 8D, audytami, reklamacjami i zarządzaniem zmianą. Bez tego lessons learned zostaje wydmuszką, a nie narzędziem. Po każdym większym problemie dobrze sprawdzić nie tylko, czy zamknęliśmy ten temat. Trzeba też sprawdzić, gdzie jeszcze to samo może się wydarzyć.

Jak uporządkować wymagania jakościowe w automotive w firmie

Nie trzeba od razu startować z dużym projektem. W wielu firmach wystarczy uporządkować kilka podstawowych rzeczy.

1. Zbierz źródła wymagań w jednym miejscu

IATF, CSR, manuale klienta, formularze, wymagania projektowe, APQP, PPAP, wymagania dotyczące audytów i zmian. Jeżeli to wszystko jest rozproszone, bałagan zaczyna się już na wejściu.

2. Przypisz właściciela do każdego wymagania

Nie ogólnie. Konkretnie. Kto prowadzi temat, wdraża działanie, potwierdza zamknięcie? Bez tego temat się rozwadnia, wisząc na tablicy kilka tygodni, po czym w cudowny sposób zostaje z niej usunięty (niestety znam to z doświadczenia).

3. Określ wpływ na proces

Co dokładnie zmienia dane wymaganie? Instrukcję? Typ kontroli? Reakcję na niezgodność? Oznaczenie? Walidację? Komunikację z klientem? Wymagania dla dostawcy? Jeżeli nie wiadomo, co ma się zmienić, to wdrożenie będzie zwykłą zasłoną dymną.

4. Ustal dowód wdrożenia

Samo „zrobione” nie wystarczy. Dowodem może być aktualizacja PFMEA i Control Planu, szkolenie, wynik walidacji, zapis ze zmiany procesu, potwierdzenie wdrożenia u dostawcy albo wynik auditu.

5. Ustal interwały przeglądów dla planowanych działań

Nie po to, żeby dokładać kolejne spotkania, tylko żeby regularnie sprawdzać:

• czy pojawiły się nowe wymagania,
• czy wdrożenia są domknięte,
• czy któryś temat wraca w reklamacjach, auditach albo problemach wewnętrznych.

Tak uporządkowane wymagania przestają być listą do odhaczania, a zaczynają działać jak element zarządzania procesem.

Checklista: czy wymagania jakościowe w automotive działają w praktyce

Na koniec zrób prosty test. Sprawdź pięć pytań:

1. Czy mamy jedno miejsce, w którym zebrane są obowiązujące wymagania?

2. Czy każde wymaganie ma właściciela po stronie procesu?

3. Czy wiemy, co dokładnie zmienia się w praktyce po wdrożeniu wymagania?

4. Czy mamy dowód wdrożenia, a nie tylko zaktualizowany dokument?

5. Czy monitorujemy zmiany i przenosimy wnioski do podobnych procesów?

Jeżeli przy kilku punktach odpowiedź brzmi „nie”, to problem raczej nie leży w braku procedury. Leży w sposobie, w jaki firma zarządza wdrożeniem.

Podsumowanie

Najwięcej problemów nie bierze się z samej treści wymagań. Bierze się z tego, że organizacja myli dokument z wdrożeniem.

A w automotive takie podejście wraca. Przy audicie. Przy reklamacji. Przy PPAP. Przy projekcie. Przy rozmowie z klientem, który zakłada, że skoro coś zostało wdrożone, to po prostu działa. Dlatego wymagania jakościowe w automotive trzeba traktować nie jak temat administracyjny, tylko jak element zarządzania procesem.

Nie chodzi o sam zapis, tylko o proces, który naprawdę działa zgodnie z wymaganiem.

Dariusz Kowalczyk