Dacă ar trebui să fac o analogie pentru procesul de PPAP (Production Part Approval Process sau Production Process and Product Approval) adică Procesul de Aprobarea Pieselor de Producție în limba română, v-aș spune să vă gândiți la dosarul cu șină pe care îl cunoaștem cu toții prea bine.
Imaginați-vă că, după ani sau luni de dezvoltare de produs, trebuie să îi trimiteți clientului vostru un pachet întreg de documentație prin care voi, în rolul de furnizori, dovediți că ați îndeplinit toate cerințele clientului, că nivelul de calitate este la nivelul contractual stabilit și că produsul vostru poate fi trimis în fabricație. Continuăm puțin analogia și vă rog să vă închipuiți realmente un dosar cu acte pe care îl trimiteți prin curier sau poștă. Clientul vostru primește aceste acte și fie le acceptă, le respinge sau le acceptă pentru o perioadă limitată, timp în care se vor soluționa anumite probleme rămase nerezolvate.
După mai mulți ani în care m-am ocupat de Software Quality Management și Process Management în industria Railway și în Automotive, am ajuns ca de aproape doi ani să mă ocup de procesul de PPAP pentru un OEM bine-cunoscut din sudul Germaniei, parte din grupul și mai renumit din nordul Germaniei în rolul de Software Quality Planner, dar despre acest rol discutăm imediat.
Așadar, în proiectele noastre ne orientăm după manualul VDA (Asociația Industriei Auto din Germania) vol. 2, însă producătorii americani se conformează cerințelor AIAG (Automotive Industry Action Group).
În ultimii ani, producătorii de automobile au început să prioritizeze componenta SW din produsele lor, astfel că și în procesul PPAP vom regăsi responsabili din zona calității furnizorilor, care se ocupă explicit de nivelul de calitate al software în produsul livrat, pe lângă colegii care însoțesc temele de hardware.
Concret, în acest volum VDA găsim șase categorii de cerințe pe care furnizorul trebuie să le pună la dispoziție producătorului. Primele cinci categorii se referă în mare parte la teme de producție și de HW: desenul tehnic, D/PFMEA, materialele conform IMDS, planul de control, caracteristicile produsului, dovezi de validare a procesului de producție etc.
În acest articol ne vom referi în special la cea de-a 6-a categorie și anume dovezile privind software, aceasta reprezentând și activitatea mea curentă.
Vedem în extrasul de mai jos din volumul VDA 2, care sunt subcategoriile necesare pentru partea de software. Acestea vor fi agreate și detaliate de către client și furnizor după semnarea contractului dintre părți. VDA încurajează toți furnizorii să nu neglijeze acest acord inițial și să documenteze într-un format propus tot de VDA (anexa 2) toate detaliile organizatorice și planificarea procesului PPAP.
Încheierea cu succes a procesului PPAP presupune în cea mai mare parte dovada capabilității procesului de producție (calitativ și cantitativ) în condiții de serie. În cazul în care PPAP trebuie repetat din cauza unor modificări sau refolosiri de produs, furnizorul poate retrimite dovezile și documentația pregătite anterior.
Un alt aspect important pentru furnizor este faptul că acesta trebuie să parcurgă procesul de PPAP mai întâi la nivel intern folosind piese de serie reprezentative fabricate în condiții reale de producție - adică produse exact pe linia, cu echipamentele și cu parametri de proces stabiliți pentru producția de serie.
VDA vol. 2, cap. 5
Începând cu ediția din 2020 a volumului 2, procesul PPAP se poate încheia cu două rezoluții: Adecvat pentru client/Adecvat pentru serie sau Neadecvat pentru client/Neadecvat pentru serie. În situația a doua, procesul trebuie reluat, motivele refuzului fiind adesea neîndeplinirea cerințelor legale sau ale clientului.
De cele mai multe ori, întâlnim în practică situația în care procesul de PPAP se încheie cu îndeplinirea parțială a cerințelor clientului, astfel încât este nevoie de o analiză de risc din partea furnizorului care se va agrea cu clientul. În cazul în care clientul acceptă riscurile descrise de furnizor, aceste deviații sunt acceptate în producție pentru o perioadă și pentru un număr limitat de piese.
VDA vol.2, anexe
Mai sus am văzut enumerate cerințele pentru software în procesul PPAP. Pregătirea acestor dovezi nu ar trebui să fie prea anevoioasă atâta timp cât detaliile au fost discutate și agreate inițial de client și furnizor, iar persoanele implicate în acest proces au mai parcurs acești pași. Provocarea este mai mult de partea clientului, a producătorului, deoarece aceste dovezi pot lua diferite forme de la un furnizor la un altul, chiar dacă pentru anumite puncte există șabloane propuse de VDA sau de AIAG.
Astfel, fiecare proces de PPAP pentru software va arăta diferit de la un furnizor la altul și rămâne la latitudinea clientului să analizeze din timp particularitățile și deviațiile din procesul de dezvoltare. Pentru a trata pro activ și eficient această provocare, grupul VW a introdus rolul de Quality Planner (pentru SW, respectiv HW) în cadrul departamentelor de Supplier Quality Management (Managementul calității furnizorilor).
Acest rol este asignat unor componente esențiale sau unor furnizori problematici pentru a se asigura că dezvoltarea de software se face conform normelor VW (KGAS, Formel Q etc.) și că toate componentele dezvoltate de furnizori sau in-house îndeplinesc standardele de calitate, de siguranță, de securitate și legale agreate. Un SW Q-Planner analizează regulat KPI de software, monitorizează defectele care apar, riscurile asupra produsului și raportează acest status mai departe în departamentul de Supplier Quality Management și către managerii de proiecte pentru diferite modele de autovehicule. Obiectivele sunt stabilite între furnizori și client odată ce contractele și negocierile au fost încheiate, iar scopul final al acestei colaborări este încheierea procesului de PPAP pentru componenta respectivă.
Metricile reprezentate aici sunt livrate de către furnizor de regulă cu fiecare release de software, iar rolul SW Q-Plannerului este să facă un control de plauzibilitate al acestora, să recunoască neconformități și să semnaleze din timp riscuri legate de produs.
KPI Cockpit, extras din 'Smart Quality Analytics Report (SQA-Report) - Introduction', V1.0, VW
Dacă ne întoarcem la analogia dosarului cu șină, putem spune că în afară de punctele 6.4, 6.5 și 6.11 din tabelul de mai sus, toate celelalte dovezi pot fi adunate cu ușurință dacă avem un proiect bine organizat. Pentru specificațiile tehnice putem avea anumite provocări, dacă cerințele încă nu au fost agreate final sau dacă toolurile folosite nu asigură o trasabilitate clară. Foarte des ne confruntăm cu situația în care furnizorul nu atinge cerința de la punctul 6.11 privind evaluarea procesului. În practică, producătorii solicită cel mai des ASPICE Capability Level 2, lucru care este o provocare pentru o bună parte din furnizori. Astfel, pentru acest punct este nevoie de o analiză a riscurilor găsite în evaluarea ASPICE, iar acestea trebuie să fie acceptate de către client.
Valoarea adăugată pe care o poate aduce rolul de Q-Planner nu constă însă doar în a bifa cerințele PPAP, ci în dezvoltarea unui produs cu o maturitate ridicată și cu un risc minim pentru clientul final. În ultimii ani, am putut observa diferența de maturitate și calitate între produsele în care un Q-Planner a fost implicat de la începutul procesului de dezvoltare și cele în care acesta a urmărit doar încheierea procesului PPAP. În primul caz, se observă cu ușurință că nivelul de înțelegere a metricilor de calitate este mult mai ridicat, trendul de îmbunătățire este vizibil cu fiecare release, iar mindsetul de calitate este prezent în întreaga echipă de proiect.
Îl întrebam pe un furnizor care a fost cheia succesului în a ajunge de la ASPICE Capability Level 0 la Capability Level 2 în aproximativ un an. Mi-a răspuns că a fost vorba de acceptarea lui (responsabil de calitate) de către echipa de proiect datorită modului în care le-a transmis importanța metricilor și a proceselor, dar și corelarea acestora cu produsul dezvoltat. Echipa l-a acceptat și datorită faptului că el a înțeles din punct de vedere tehnic produsul și a putut să îi ajute cu evaluarea corectă a riscurilor și cu definirea măsurilor adecvate. Așadar, odată ce succesul a devenit un scop comun, echipa a atins uimitor de rapid toate obiectivele clientului și procesul de PPAP a devenit o formalitate, la fel ca întocmirea unui dosar cu șină.
Programarea, securitatea și AI-ul
Marți, 30 Septembrie, ora 18:00
msg systems Romania
Timișoara
Facebook Meetup StreamEvent YouTubede Denisa Lupu
de Ovidiu Mățan
de Ovidiu Mățan
de Paul Orha
