Lo sviluppo delle commesse cliente è normalmente gestito con un diagramma a cascata o diagramma di Gantt all’interno del quale le attività di progettazione meccanica, elettrica e/o elettronica e software sono pianificate per essere funzionali alla costruzione e/o all’acquisto dei materiali e componenti. Il tutto per consentire il rispetto delle successive attività di montaggio e collaudo necessarie per completare la costruzione del prodotto.
Nel caso di prodotti configurati secondo le opzioni previste – come nel caso di prodotti definiti con configuratori commerciali, spesso dati in mano al cliente finale – le attività di progettazione sono assenti, e la logica a cascata è perfettamente adatta per gestire la commessa.
In una grande quantità di casi si presentano commesse con leggere personalizzazioni di un prodotto “standard”, che possono richiedere piccoli interventi di adattamento del prodotto stesso alle specifiche esigenze del cliente. Si tratta di lievi aggiustamenti che richiedono comunque un passaggio nell’ufficio tecnico.
Se tali aggiustamenti sono eseguibili in poche ore – e il tempo di attraversamento dell’area della progettazione risulta trascurabile rispetto alle assai più rilevanti attività di costruzione, approvvigionamento, montaggio e collaudo – la logica di pianificazione a cascata rimane perfettamente adatta per gestire la commessa.
La progettazione software, se presente, è slegata dalla costruzione e dall’approvvigionamento dei materiali, ma è legata alle attività di montaggio e collaudo che consentono la messa a punto del software stesso grazie alla presenza del prodotto fisico.
Nel caso invece in cui si debbano sviluppare commesse con forti personalizzazioni del prodotto, l’impegno richiesto da parte delle attività dell’ufficio tecnico aumenta di uno o due ordini di grandezza, passando in altre parole da qualche ora per la configurazione di una macchina standard fino ad alcune centinaia di ore per lo sviluppo di una macchina personalizzata.
L’impegno progettuale, in questo caso, può essere paragonabile o superiore al tempo di costruzione e/o di montaggio. Di conseguenza non è pensabile che venga completata tutta la progettazione prima di dare inizio alla costruzione e/o agli acquisti.
Specialmente nel caso delle macchine personalizzate, l’attività di montaggio avviene molto spesso in una fase unica. Unica nel senso che il montaggio del tutto non viene scomposto in quello separato di tutti i sottosistemi macchina o gruppi macchina, seguito da un assemblaggio finale degli stessi (solamente aziende strutturate con pre-lanci di produzione e montaggio di interi sottosistemi in funzione delle previsioni di vendita attuano queste “sotto-fasi”, che ad ogni modo rimangono relative a sottosistemi o gruppi standard).
Con un’unica fase di montaggio, tutti i sottosistemi macchina o gruppi macchina vengono prodotti come semplice lista dei loro componenti.
In tal caso la distinta di costruzione/acquisti diviene una distinta base piatta, e i gruppi risultano “trasparenti” e, per tale ragione, vengono chiamati anche “gruppi fantasma”.
La pianificazione della costruzione/acquisti risulta così “tirata” dal “Tempo di Attraversamento” di ciascun elemento della distinta base, chiamato anche “Lead Time”.
La progettazione rilascerà quindi gli elementi della distinta base in modo incrementale, in funzione del Lead Time. Gli elementi a lungo Lead Time andranno rilasciati prima di quelli con Lead Time medio, e così via fino a quelli con il Lead Time più corto.
Tali diverse gradazioni di Lead Time non portano normalmente ad altrettante date di rilascio, o ne risulterebbero troppe negoziazioni di date.
Normalmente si concordano fra produzione e progettazione 3 o più date di rilascio degli elementi della distinta base, con la partenza di altrettante tipologie di approvvigionamento.
Per semplificazione di esposizione ho indicato genericamente “progettazione”, intendendo l’insieme delle progettazioni relative a oggetti fisici o hardware come ad esempio quelle meccaniche, elettriche ed elettroniche.
Nella esemplificazione riportata nel diagramma di Gantt sono indicate 3 date Milestone per la progettazione:
- Data Fine progettazione elementi a Lungo Lead Time.
- Data Fine progettazione elementi a Medio Lead Time.
- Data Fine progettazione elementi a Corto Lead Time.
Il Lead Time di nuovi elementi viene stimato per analogia con elementi simili.
La progettazione SW può muoversi più liberamente, condizionata dalle fasi di montaggio e collaudo come precedentemente descritto.
Il diagramma riportato qui sotto è esemplificativo del caso di una progettazione e costruzione/acquisti con 3 appuntamenti o Milestone (a lungo, medio e corto Lead Time).
Si può notare che l’attività dell’ufficio tecnico inizia con un certo anticipo, perché vi è sempre una progettazione sistemica senza la quale non sarebbe possibile individuare gli elementi speciali da progettare e gli elementi standard da lanciare invece in produzione senza modifiche.
Si può notare che le attività di progettazione continuano oltre il rilascio dei documenti tecnici necessari per costruire/acquisire l’ultimo componente, poiché vi sono altre attività tecniche a completamento dei lavori che non hanno impatto sul Lead Time dei componenti.
Questo è ciò che la produzione richiede, ma all’interno dell’ufficio tecnico la scomposizione dei lavori da svolgere segue una regola diversa, molto simile a quella impiegata per preventivare il lavoro.
In area tecnica si scompone infatti il prodotto in tutti gli elementi da sviluppare raggruppati per sottosistemi o gruppi, creando una distinta base semplificata o di alto livello.
Tipicamente si arriva a strutturare un elenco dei sottosistemi o gruppi macchina da progettare.
E per ciascuno di essi si stimano le Ore di Sviluppo.
| Elementi hardware da sviluppare | Stima Ore di Sviluppo (H) |
|---|---|
| Prodotto nel suo insieme • Studio geometrie CAD 3D • Studio modalità funzionamento • … | H previste = 82 • H = 28 • H = 23 • H = ... |
| Sottosistema A • Studio • Simulazioni numeriche • Disegni escutivi • Schede di collaudo • … | H previste = 148 • H = 85 • H = 35 • H= 30 • H= 25 • H = ... |
| … | … |
| Sottosistema B • Schema elettrico o circuitale • Distinta componenti • … | H previste = 170 • H = 120 • H = 23 • H = … |
| Sottosistema N • Studio • Disegni esecutivi • … | H previste = 90 • H = 52 • H = 18 • H = ... |
| … | … |
Lista degli elementi da sviluppare e stima dello sforzo necessario in Ore di Sviluppo.
Quasi tutti i sottosistemi macchina avranno al loro interno elementi con diversi Lead Time; pertanto ipotizzare una pianificazione della costruzione basata su un unico rilascio di un sottosistema completo non risolve il problema della gestione differenziata dei componenti aventi diverso Lead Time.
Come coniugare queste due legittime esigenze di tipo progettuale e di tipo costruttivo e di acquisto?
Pensare di costruire per ogni sottosistema un mini-diagramma di Gantt porterebbe a una complicazione di pianificazione veramente troppo alta, rendendo di fatto la cosa ingestibile di fronte a ogni minima richiesta di variazione del piano.
La variazione del piano è in realtà molto frequente e può avvenire per diverse ragioni, fra le quali ad esempio:
- Difficoltà progettuali incontrate.
- Difficoltà e/o imprevisti di costruzione e approvvigionamento.
- Variazione delle specifiche da parte del cliente.
- Variazione delle priorità di sviluppo delle diverse commesse in funzione del carico dei reparti o delle richieste dei clienti.
- Difficoltà o imprevisto al montaggio e collaudo.
- Errori lungo tutto il processo.
Ed è qui che ci viene in aiuto l’approccio agile di gestione del Backlog!
Se gli elementi di primo livello sono i sottosistemi o gruppi macchina, allora è immediato dare rappresentazione visuale alla precedente lista, scomponendola fino al dettaglio desiderato. Questo costituisce il Backlog dello sviluppo fisico o hardware.
A esso risulta poi relativamente facile aggiungere l’eventuale Backlog dello sviluppo software.
Il processo di sviluppo iterativo e incrementale – rappresentato dallo Story Mapping – prevede di distribuire gli elementi di secondo livello del Backlog nelle diverse iterazioni, trasformando la scomposizione del Backlog da statica a dinamica.
Lo sviluppo delle commesse è sempre caratterizzato da tempi stretti, e per questo è opportuno mantenere iterazioni di durata pari a una settimana. L’intervallo settimanale è sufficiente per soddisfare tanto i bisogni progettuali quanto quelli produttivi.
Ruotando lo Story Mapping di 90° in senso antiorario, la precedente lista degli elementi da sviluppare potrebbe avere questa rappresentazione:
Con iterazioni settimanali è possibile creare un macro-argomento Milestone che contenga i riferimenti alle Milestone indicate nel diagramma di Gantt.
La rappresentazione visuale riportata di seguito consente una gestione coerente con i bisogni di auto-organizzazione dell’area tecnica e con il rispetto delle Milestone:
In questa modalità tutti i lavori relativi ai lunghi Lead Time identificati dal colore della corrispondente Milestone devono essere sviluppati entro e non oltre la settimana di posizionamento del Milestone stesso.
In maniera simile si opera con i lavori relativi alle altre tipologie di Milestone.
Il tabellone consente un’immediata visualizzazione dei cartellini relativi agli elementi di secondo livello, che sono posizionati oltre la corrispondente Milestone identificata dallo stesso colore.
Se all’interno di ciascun cartellino – rappresentativo degli elementi di secondo livello – si indicano le ore di sviluppo necessarie per il suo svolgimento, è possibile calcolare (per iterazione) il carico di lavoro settimanale complessivo, da comparare poi con le ore a disposizione o capacità settimanale.
Questo approccio può ovviamente essere esteso anche alle attività di montaggio e collaudo, in mancanza di sistemi di pianificazione della produzione o qualora tali attività siano fra loro molto interconnesse come lo sono quelle progettuali.
Tale modalità agile semplificata con iterazioni settimanali – che è alla base dei Flash Meeting descritti nel libro all’interno del Capitolo 12 relativo alla Fabbrica Agile vera e propria – viene descritta anche nel Capitolo 13 relativo ai 3 casi di Sviluppo Prodotto: Semplice, Complicato e Complesso.
Nel libro ho definito questa modalità semplificata di gestione iterativa e incrementale del Backlog “Easy Agile”.
Uno strumento software adeguato è in grado di eseguire questi calcoli automaticamente rendendo molto più sostenibile l’approccio, specialmente in un’ottica multi-progetto.
Tornerò con un altro articolo sulla modalità di gestione multi-progetto delle commesse con forti personalizzazioni.
4 risposte
nuovo commento dopo primo intervento Chiara
test invio mail
test 2 invio mail
Prova di commento di maggio 2024 con Chiara