Come il PLM aiuta davvero i team di ingegneria a muoversi più velocemente

Affinché i team di ingegneria possano muoversi con la velocità di cui abbiamo bisogno, le persone, i dati di prodotto e i processi che influenzano il loro lavoro devono rimanere perfettamente allineati.

Ogni modifica al progetto crea un effetto a catena sui team a monte e a valle, rendendo più difficile far sì che tutti lavorino con le stesse informazioni.

È qui che entra in gioco il product lifecycle management (PLM). I moderni software PLM gestiscono le informazioni di prodotto dall’idea alla produzione.

Il PLM aiuta a prevenire confusione tra versioni, discrepanze nella BOM, modifiche non documentate ed errori causati da passaggi di consegne manuali. 

Ma in che modo aiuta concretamente i team di ingegneria a muoversi più velocemente ogni giorno?

Dove si perde davvero tempo in ingegneria

Man mano che i prodotti diventano più complessi e i team sono spesso distribuiti, gli ingegneri dedicano più tempo alla ricerca di informazioni, alla verifica delle decisioni e alla conferma di lavorare sulla revisione corretta.

I team di ingegneria hanno regolarmente bisogno di risposte in tempo reale a queste domande:

• Quale BOM è quella attuale?
• Questo componente è stato approvato?
• Chi ha approvato questa modifica?
• Perché è stato selezionato questo componente?
• Quale revisione ha ricevuto la produzione?

Rispondere a queste domande non dovrebbe interrompere il lavoro di ingegneria. Quando le informazioni sono difficili da trovare, i team perdono tempo in rilavorazioni, controlli manuali e inutili botta e risposta. 

Gli attuali strumenti PLM offrono agli ingegneri un facile accesso alle informazioni di cui hanno bisogno, così possono dedicare più tempo alla progettazione e meno alla ricerca.

I team di ingegneria hanno bisogno di un unico record di prodotto affidabile

Un record di prodotto affidabile offre a ingegneria, approvvigionamento e produzione un’unica fonte di verità lungo tutto lo sviluppo del prodotto. Dà a ogni team la certezza di lavorare sulla revisione corretta.

La ricerca ha dimostrato che l’85% degli utenti PLM afferma che questi sistemi li aiutano a trovare le informazioni più facilmente, quasi il 75% segnala dati più accurati e più di due terzi affermano di avere un accesso più tempestivo alle informazioni di progettazione.

Con un unico record di prodotto affidabile, l’ingegneria può rilasciare i progetti con sicurezza, l’approvvigionamento può esaminare componenti approvati e alternative, la produzione può costruire partendo dalla revisione corretta e il management può monitorare i progressi senza fare affidamento su riunioni di stato.

Le modifiche ingegneristiche raramente riguardano un solo componente. Possono avere un impatto su assiemi, fornitori, disegni, piani di test, processi produttivi e documentazione di conformità.

Senza PLM, questi impatti vengono spesso gestiti tramite thread email, messaggi in chat, fogli di calcolo condivisi e conoscenza informale. Con la crescita di prodotti, team e supply chain, gestire manualmente queste modifiche diventa molto più difficile.

L’attuale change management dovrebbe essere molto più “ispirato a GitHub”, con la possibilità di tracciare le revisioni di componenti, disegni e BOM; vedere chi ha modificato cosa e perché; instradare gli ECO attraverso workflow di approvazione; notificare i revisori; e ridurre il numero di ordini di modifica respinti a causa di dati mancanti.

Quando gli ordini di modifica sono completi, visibili e instradati automaticamente, i team passano meno tempo a rincorrere le approvazioni e più tempo a risolvere problemi di ingegneria.

Il PLM porta le decisioni di sourcing in ingegneria più precocemente

Per gli utenti di Octopart, questo è uno dei vantaggi di velocità più importanti del PLM: aiuta ingegneria e sourcing a collaborare prima che le scelte dei componenti diventino costose da modificare.

Ad esempio, integrare Duro PLM nel vostro flusso di lavoro consente ai team di ingegneria di risparmiare ore di tempo spese a copiare/incollare manualmente i dati dei componenti sfruttando l’accesso API di Duro a Octopart.

Poi, una volta aggiunto un componente, i dati di prezzo (oltre a qualsiasi altro dato) possono essere aggiornati direttamente all’interno del PLM per offrire al team informazioni aggiornate e accurate. Questo fa anche risparmiare ore di controlli manuali dei prezzi, lasciando ai team più tempo per prendere decisioni e orientarsi verso un componente diverso se i costi diventano insostenibili o, peggio, se il componente diventa irreperibile.

Questo è il ROI del PLM per gli utenti di Octopart. Un prodotto può essere difficile da lanciare se i componenti non sono disponibili, sono obsoleti, troppo costosi o difficili da reperire. Quando la revisione del sourcing avviene dopo che il progetto è per lo più completo, i team sono costretti a compromessi nelle fasi finali, ritardando la pianificazione o riprogettando sotto pressione. Il PLM è progettato per aiutare i team a ottenere i dati di cui hanno bisogno molto prima, così da prendere decisioni che riducano il time-to-launch. Gli ingegneri possono visualizzare dati su fornitori, ciclo di vita, costi, disponibilità e componenti alternativi nel contesto del progetto.

Il PLM migliora la collaborazione cross-funzionale

Uno dei maggiori ostacoli a uno sviluppo prodotto più rapido sono i passaggi di consegne sequenziali. L’ingegneria completa un progetto e poi lo invia al sourcing. Il sourcing individua un problema e poi lo rimanda indietro. 

Il PLM consente ai team cross-funzionali di esaminare i progetti e contribuire prima nel processo di sviluppo. 

La produzione può ispezionare il progetto prima del rilascio, l’approvvigionamento può segnalare componenti rischiosi mentre la BOM è ancora in evoluzione e la qualità può convalidare i requisiti prima che il pacchetto di rilascio sia completo.

Questo è particolarmente importante per i team distribuiti. Il PLM fornisce loro un record di prodotto condiviso, così lo sviluppo può continuare senza dipendere da riunioni continue o aggiornamenti manuali sullo stato.

Il PLM preserva il “perché” dietro le decisioni ingegneristiche

I prodotti hardware che durano per anni richiedono una memoria di prodotto, soprattutto quando gli ingegneri lasciano l’azienda, i fornitori cambiano e i componenti diventano obsoleti. 

Quando il contesto decisionale è conservato nella memoria di qualcuno, in un vecchio thread email o in un foglio di calcolo locale, i team finiscono per perdere la logica alla base del progetto. 

Il PLM aiuta a preservare il “perché” insieme al “cosa”. Un buon record di prodotto dovrebbe rispondere a queste domande:

• Perché è stato selezionato questo componente?
• Perché questa alternativa è stata scartata?
• Perché questa tolleranza è stata modificata?
• Quale fornitore ha approvato questa revisione?
• Quale ECO ha introdotto questo requisito?
• Quali assiemi sono interessati se questo componente cambia?

Un prodotto dovrebbe portare con sé la propria memoria, così i team non devono risolvere gli stessi problemi ogni volta che una domanda riemerge.