PFMEA – czy kontrola może być prewencją?

(Uwaga – tekst tylko dla pasjonatów FMEA)

Bardzo typowym problemem przy analizie FMEA jest odróżnienie kontroli od prewencji. Bez wątpienia dodatkowym utrudnieniem są tu oczywiste błędy w motoryzacyjnych standardach dotyczących tej metody (AIAG i VDA):

• AIAG ed. 4 – instrukcję pracy wpisano jako metodę detekcji („wzorcowy” przykład PFMEA)
• AIAG & VDA ed. 1 – na rysunku rozróżniającym prewencję od kontroli podano, że kontrola występuje tylko po pojawieniu się charakterystyki wyrobu (wady), a przecież jest coś takiego jak kontrola przyczyny, którą pojawia się zanim „na świat przyjdzie” wada.

Definicje

Generalnie, warto wprowadzić pewien wyraźny podział (rozróżnienie):

• Prewencja: działanie mające ZAPOBIEC pojawieniu się przyczyny.

• Kontrola: działanie mające na celu WYKRYCIE wady lub przyczyny.

Zatem kontrolą, w myśl PFMEA bez wątpienia będzie m.in.: ocena wzrokowa gotowego wyrobu (kontrola wady), 100% badanie automatyczne kamerą obecności etykiet, czujnik obecności kompletu blaszek przed rozpoczęciem procesu nitowania (kontrola przyczyny).

Ale… czy każda kontrola w rozumieniu PFMEA będzie działaniem detekcyjnym?

Co na przykład w przypadku kontroli przyczyny przyczyny (choć dziwnie to brzmi). Jeżeli zastosowane jest w procesie kontrola, której zadaniem będzie wykrycie zjawiska, które doprowadzą do pojawienia się przyczyny wady (czyli przyczyny przyczyny) to staje się ona pewną formą działania prewencyjnego.

Czytelnie przedstawia to poniższy rysunek:

 

Jeżeli zatem uznamy, że prewencja to działanie mające na celu ograniczenie możliwości pojawienia się przyczyny wady (a tak to należy rozumieć w kontekście PFMEA) to kontrolę przyczyny przyczyny uznać należy za prewencję.

Tak to właśnie kontrola staje się prewencją. Obrazuje to czytelnie poniższy schemat:

 

Rys. 2. Przykłady gdy kontrola staje się prewencją  Źródło: opracowanie własne

W związku z powyższym, przy analizie spójności dwóch ważnych dokumentów: PFMEA i planu kontroli (CP) próżno będzie szukać w tym definicji takich elementów jak TPM czy audit 5S.

Ale…* możliwe, że czasami trzeba będzie z powodów pragmatycznych postąpić niezgodnie z omówioną powyżej logiką.

*to już drugie „ale” w kontekście opisywanej tu tematyki

Chodzi o sytuację, gdy w trakcie procesu kontroluje się przyczynę przyczyny i tę kontrolę chce się pokazać w planie kontroli. Nie chodzi tu oczywiście o takie analizy, gdy zarówno PFMEA, jak i CP dokumentowane jest w arkuszu kalkulacyjnym, bo wtedy można sobie wpisać „wszystko wszędzie”.

Jednak w przypadku, gdy do FMEA wykorzystywane jest dedykowane, dobre oprogramowanie (np. PQ-FMEA, IQ – RM, Plato) „pilnować” nas będzie wbudowana w nie logika. A ta przy PFMEA jest oczywista: przyczyna wady wynika z błędnej charakterystyki procesu, a w CP kontrola przyczyny to kontrola charakterystyki procesu. Jeżeli zatem chcemy w CP ująć kontrolę przyczyny przyczyny to musimy lekko zaburzyć omówioną poniżej logikę.

Przykład:

Wada: chropowatość płaszczyzny po cięciu gorsza niż w wymaganiach

Przyczyna: drgania noża w trakcie procesu cięcia

Przyczyna przyczyny: nieskuteczne smarowanie – nie podano zadanej ilości środka smarującego.

Nadzorowanie

Charakterystyka procesu – ilość podanego środka smarującego

Detekcja – kontrola przepływomierzem podanej dawki środka smarującego

 

Podsumowanie

Zatem czasami może się pojawić chęć pokazania w CP kontroli czegoś co nie jest ani wadą, ani czymś co może być jej przyczyną. Moderator będzie miał w takiej sytuacji dwa rozwiązania:

1. Dopisanie przyczyny niebezpośredniej (tu: ilość środka smarującego) i przypisanie do niej kontroli
2. Przypisanie kontroli przyczyny niebezpośredniej do przyczyn bezpośredniej (takie jakby pośrednie wykrywanie) – tu jednak będzie mały problem z logiką CP.

Zatem na wiele nietypowych sytuacji można znaleźć sposób – trzeba tylko mieć odpowiednią wiedzę, żeby zastosowane rozwiązania nie przerodziły się w chaos.