Dalle macchine speciali ai componenti automotive e ferroviari, il manifatturiero meccanico deve affrontare una sfida crescente: gestire prodotti e varianti sempre più complessi, mantenendo controllo e tracciabilità lungo tutto il ciclo di vita.
In questo contesto, la gestione tradizionale delle revisioni non sempre è sufficiente. Quando lo sviluppo richiede studi alternativi, prototipi, co-sviluppi con fornitori o interventi correttivi su componenti già rilasciati, diventa necessario gestire percorsi progettuali paralleli senza compromettere la continuità della produzione.
Che cos’è il branching nel PLM? È la possibilità di creare una derivazione indipendente di un oggetto di prodotto, con una propria identificazione, su cui lavorare senza modificare la revisione rilasciata. Una volta approvata la soluzione, le modifiche possono essere integrate nella struttura principale attraverso un processo di merge controllato.
La piattaforma 3DEXPERIENCE, attraverso il branching nativo di ENOVIA, offre un approccio strutturato per rispondere a queste esigenze. Creare derivazioni indipendenti, confrontarne i contenuti e integrarli attraverso processi di merge controllato permette di gestire la complessità mantenendo la coerenza della struttura di prodotto.
Indice:
- Oltre la gestione tradizionale delle revisioni
- Branch, Compare e Content Merge: come funziona il branching in ENOVIA
- Il branching nel manifatturiero: cinque scenari
- Branch o doppio indice di revisione: il confronto
- Branching Playbook: sei regole per governare le varianti
- Conclusioni: dal controllo delle revisioni alla governance del prodotto
Oltre la gestione tradizionale delle revisioni
Le tradizionali sequenze di revisione, alfabetiche (A, B, C…) o numeriche con indice secondario (1.1, 1.2, 2.0…), funzionano bene quando l’evoluzione del prodotto segue un percorso lineare. È il compito tipico del PDM, come spiegato nell‘articolo PDM o PLM: qual è il sistema più adatto.
Diventano invece meno efficaci quando le attività di sviluppo richiedono:
- studi progettuali in parallelo;
- isolamento di prototipi o fix urgenti;
- co-sviluppo con partner e fornitori esterni;
- comparazione e selezione tra alternative concorrenti.
In questi scenari, il problema non è soltanto identificare una nuova revisione, ma governare contemporaneamente più direzioni di sviluppo, mantenendo separata la definizione principale del prodotto dalle soluzioni ancora in fase di valutazione.
Nella piattaforma 3DEXPERIENCE, la distinzione tra revisione e branch è intenzionale: la revisione rappresenta la continuità del prodotto, mentre la branch crea un nuovo oggetto, con identificazione distinta, finalizzato a esplorare un intento progettuale alternativo.
Branch, Compare e Content Merge: come funziona il branching in ENOVIA
L’approccio al branching in ENOVIA si fonda su tre operazioni complementari, che consentono di passare dallo sviluppo indipendente di una soluzione alla sua eventuale integrazione nella linea principale del prodotto.
Branch: isolare lo sviluppo senza compromettere la linea principale
Una derivazione (branch) genera un nuovo oggetto, con una nuova identificazione e EIN (Enterprise Item Number) resettato, sul quale è possibile condurre studi indipendenti rispetto alla revisione di origine. Questo consente di esplorare soluzioni alternative senza intervenire direttamente sulla definizione del prodotto rilasciato. Un aspetto fondamentale riguarda la corretta selezione degli oggetti correlati: la derivazione deve preservare la coerenza delle relazioni strutturali, evitando che l’isolamento di una parte comprometta l’integrità dell’insieme.
Compare: valutare le differenze tra le alternative
Gli strumenti nativi di comparazione permettono di analizzare le differenze tra la derivazione e la revisione di origine. La comparazione diventa così un passaggio determinante nel processo decisionale: consente di valutare gli effetti delle modifiche introdotte e individuare la soluzione più appropriata prima del rilascio. Dalla release R2025x, le funzionalità di confronto si estendono anche alle branch create a partire da strutture filtrate, ampliando le possibilità di gestione di sottoinsiemi specifici del prodotto.
Content Merge: riportare le modifiche nella revisione principale
Una volta individuato il ramo più valido, il processo di Content Merge, attraverso la funzionalità New Revision From, permette di utilizzare i contenuti della derivazione per generare una nuova revisione del prodotto. Ad esempio, partendo da una revisione B, è possibile sviluppare più alternative indipendenti e integrare la soluzione approvata nella successiva revisione C.
Il processo Branch → Compare → Merge permette quindi di separare la sperimentazione dal rilascio, mantenendo il controllo delle modifiche e la tracciabilità delle decisioni.
Il branching nel manifatturiero: cinque scenari
Il valore del branching emerge soprattutto nei contesti in cui lo sviluppo prodotto non procede in modo sequenziale, ma attraverso attività parallele, varianti e modifiche che coinvolgono più soggetti.
1. Studi di variante su componenti critici
Un caso ricorrente riguarda componenti meccanici critici, come un housing gear in revisione B. Il responsabile di progetto può richiedere lo sviluppo di più studi in parallelo: P2 e P3 come varianti alternative, P5 come intervento correttivo. Ciascuna derivazione segue un percorso indipendente, senza modificare la revisione principale. Al termine degli studi, le soluzioni vengono confrontate e il ramo selezionato viene integrato nella nuova revisione C. La gestione delle alternative rimane così distinta dall’evoluzione ufficiale del componente.
2. Prototipazione e validazione cliente
Lo sviluppo di prototipi o varianti richieste dal cliente introduce spesso modifiche che devono essere valutate prima di entrare nella configurazione definitiva. Attraverso una branch è possibile isolare queste attività, preservando la definizione del prodotto rilasciato. Le modifiche possono essere governate attraverso le Change Action, mantenendo il controllo delle attività, delle responsabilità e delle decisioni assunte durante la validazione. Solo dopo l’approvazione, i contenuti selezionati vengono integrati nella revisione principale.
3. Co-sviluppo con fornitori esterni
Nei progetti che coinvolgono fornitori o collaboratori esterni, il branching permette di separare le attività di sviluppo dalla struttura principale del prodotto. Le derivazioni possono essere gestite in Collaborative Spaces (gli spazi di lavoro della 3DEXPERIENCE) distinti, con responsabilità e permessi dedicati. Questo consente di affidare lo sviluppo di contenuti specifici a soggetti esterni, mantenendo protetto il tronco principale e limitando i rischi associati a modifiche non ancora validate. La collaborazione diventa così parte di un processo controllato, anziché un’attività parallela difficilmente riconducibile alla configurazione ufficiale del prodotto.
4. Varianti di prodotto con 150% BOM
Per i prodotti configurabili, la gestione delle opzioni avviene attraverso le funzionalità di Variant Management e l’impiego di strutture 150% BOM (la distinta che contiene tutte le opzioni possibili di una famiglia di prodotti, non solo quelle di una singola configurazione), che rappresentano l’insieme delle possibili configurazioni di una famiglia di prodotti. Quando una variante richiede una modifica fisica, tuttavia, la sola gestione delle opzioni non è sufficiente. Una branch isolata permette di intervenire sul sottoinsieme interessato, sviluppare la modifica e verificarne la coerenza prima dell’eventuale integrazione nella linea principale. Il branching affianca quindi il Variant Management, distinguendo la configurazione delle opzioni dallo sviluppo delle modifiche fisiche necessarie a realizzarle.
5. Fix urgenti su parti rilasciate
Un difetto rilevato su un componente già in produzione richiede spesso un intervento rapido, senza compromettere la continuità della configurazione attualmente rilasciata. Una branch dedicata consente di isolare la correzione, svilupparla e validarla mentre la produzione continua a fare riferimento alla revisione esistente. Una volta approvato il fix, il contenuto corretto può essere integrato in una nuova revisione, secondo il processo di rilascio previsto. In questo modo, l’urgenza dell’intervento non compromette il controllo delle modifiche.
Branch o doppio indice di revisione: il confronto
La piattaforma 3DEXPERIENCE supporta anche schemi estesi di revisione, ma quando lo sviluppo richiede alternative indipendenti e lavoro parallelo, il branching rappresenta un approccio più strutturato.
Esigenza
Lavoro in parallelo
Tracciabilità del cambiamento
Merge controllato
Gestione varianti fisiche
Doppio indice di revisione
✖ Non supportato nativamente
Parziale
Assente
Difficoltosa
Branch ENOVIA
✔ Rami indipendenti
Completa con CA/CO (Change Action e Change Order)
Nativo con New Revision From
Adatto a modifiche fisiche e FFF Change (modifica di forma ingombro o funzione)
La differenza sostanziale non riguarda quindi il numero di revisioni gestibili, ma la possibilità di separare percorsi progettuali differenti e ricondurli a una configurazione comune attraverso un processo controllato.
Branching Playbook: sei regole per governare le varianti
Perché il branching diventi uno strumento efficace di gestione del prodotto, è necessario accompagnarne l’adozione con regole operative condivise.
1. Individuare i trigger appropriati
Una branch deve essere aperta quando esiste una reale esigenza di sviluppo alternativo: variante fisica, prototipo, fix, co-sviluppo o modifica di una porzione filtrata della struttura. Non ogni cambiamento richiede una derivazione indipendente.
2. Definire naming e oggetti collegati
L’adozione di convenzioni di denominazione chiare e la corretta selezione degli oggetti correlati sono fondamentali per mantenere leggibilità e integrità della struttura.
3. Gestire permessi e Collaborative Spaces
Le branch possono essere organizzate in spazi collaborativi separati, anche dedicati a fornitori esterni, per definire responsabilità e livelli di accesso coerenti con le attività assegnate.
4. Applicare un Change Management rigoroso
Le derivazioni devono essere governate attraverso processi strutturati di gestione delle modifiche, utilizzando Change Action e, quando necessario, Change Order.
5. Seguire il processo Compare → Decisione → Merge
La selezione del contenuto da integrare deve essere preceduta dalla comparazione delle alternative e da una decisione esplicita. Attraverso New Revision From, il contenuto approvato viene quindi riportato nella nuova revisione principale.
6. Allineare Manufacturing e Qualità
Il processo non termina con il merge. L’esito delle modifiche deve essere comunicato ai reparti Manufacturing e Qualità, affinché possano essere aggiornati MBOM (la distinta base di produzione), processi produttivi, piani di controllo e documentazione tecnica. Solo così la modifica progettuale diventa parte di un’evoluzione coerente dell’intero prodotto.
Conclusioni: dal controllo delle revisioni alla governance del prodotto
La crescente complessità del manifatturiero impone di superare una visione esclusivamente sequenziale dell’evoluzione del prodotto. Varianti, prototipi, co-sviluppi e interventi correttivi richiedono la capacità di gestire percorsi paralleli senza perdere il controllo della configurazione principale. Il branching nativo di ENOVIA, all’interno della piattaforma 3DEXPERIENCE, offre una risposta strutturata a questa esigenza. Attraverso il processo Branch → Compare → Merge, le organizzazioni possono isolare le attività di sviluppo, confrontare le alternative e integrare le modifiche approvate in modo controllato e tracciabile. Non si tratta soltanto di gestire più revisioni, ma di migliorare la governance del prodotto: contenere la complessità, rafforzare la collaborazione interna ed esterna e rendere più affidabili le decisioni lungo l’intero ciclo di vita.
In uno scenario industriale caratterizzato da iterazioni continue e crescente personalizzazione, governare le ramificazioni dello sviluppo significa mantenere il controllo sull’evoluzione del prodotto.
