Perché l'automazione CAD fallisce quando la trattate come progetto IT
La frase più pericolosa che sento nei primi colloqui di un progetto di automazione CAD è questa: "Abbiamo assegnato il progetto all'IT".
Non perché l'IT sia un problema. Perché quel framing, da solo, predice con buona approssimazione come andrà il progetto nei 18 mesi successivi.
L'automazione dei reparti tecnici fallisce in una percentuale alta di casi, e quando analizziamo le cause a posteriori, la radice tecnica è raramente il motivo principale. Il motivo è quasi sempre organizzativo: chi ha in carico il progetto, chi decide le regole, chi valida i risultati, chi ne misura il ritorno.
Perché l'IT, da solo, non può riuscirci
Un sistema di automazione CAD non è un'applicazione. È un modello che codifica il know-how ingegneristico dell'azienda.
Le domande a cui deve rispondere non sono "quale database usiamo" o "come integriamo l'API". Sono: qual è il vincolo dimensionale quando la macchina supera i 4 metri? Quando si usa la soluzione A e quando la B? Perché il senior X sceglie sempre un certo tipo di cuscinetto in quella configurazione?
Queste risposte non stanno in un documento. Stanno nella testa di tre o quattro persone nell'ufficio tecnico.
Se l'IT guida il progetto, passa i primi sei mesi a costruire infrastruttura intorno a regole che non ha modo di estrarre. I tecnici senior rispondono alle interviste quando hanno tempo — che è raramente — e le regole che emergono sono incomplete. Il sistema viene rilasciato, funziona sulla casistica semplice, fallisce sulle varianti reali.
A quel punto, il progetto si blocca. L'IT non ha autorità per forzare i tecnici a dedicargli tempo. Il responsabile ufficio tecnico ha altre priorità. La direzione non vede ritorno e taglia il budget.
Cosa cambia quando guida l'ingegneria
- Il progetto ha un proprietario tecnico — tipicamente un senior dell'ufficio tecnico con ruolo parziale dedicato — che ha autorità riconosciuta per formalizzare regole.
- Il perimetro iniziale è ristretto: una famiglia di prodotto, una tipologia di commessa, un output specifico. Non "tutto il catalogo". Non "tutti i 3D".
- L'IT è partner, non lead. Fornisce l'infrastruttura, ma le decisioni progettuali sono ingegneristiche.
- La direzione operations valida KPI concreti: non "quanto è stato automatizzato" ma quante ore sono tornate disponibili, quanto è sceso il rework, di quanto è sceso il tempo di onboarding di una nuova risorsa.
- L'AI è un acceleratore della fase di estrazione — aiuta a classificare progetti storici e trovare pattern — non una sostituzione del lavoro ingegneristico di formalizzazione.
Il test di prontezza in tre domande
Prima di avviare un progetto di automazione CAD, tre domande in stanza con la direzione.
- Chi ha autorità riconosciuta per decidere quale regola progettuale è quella "ufficiale", quando due senior ne propongono due diverse?
- Chi misura il ritorno — e con quali metriche già concordate prima del kickoff?
- Siete disposti a dedicare almeno un senior per una quota del suo tempo a questo progetto per sei-dodici mesi, proteggendolo dalle urgenze di commessa?
Se la risposta a una di queste è vaga, il progetto non è pronto. Non è un problema di tecnologia. È un problema di governance.
Affrontare quelle tre domande prima di spendere in software è la differenza tra un ROI sotto l'anno e un progetto che scivola.
In Lemonjuice Solutions la fase zero dei nostri progetti è proprio questa: verificare che le condizioni organizzative esistano prima di toccare il CAD. Contattateci se volete farla.