Category Archives: ALM

Continuando nell’esplorazione della fase di Workout, siamo giunti alla Bill of Materials per la quale, come si è visto, si è passati attraverso una serie di rifinimenti che hanno permesso di superare il Quality Gate ed essere pronti la Produzione Manifatturiera.

Sia che la produzione avvenga da parte di un produttore terzo, sia che, invece, se ne occupi un diverso team/dipartimento della stessa azienda, bisogna integrare la stessa nelle proprie attività di governance, per non incorrere in spiacevoli sorprese che vadano a minare quanto fatto fino a questo momento.

La relativa gestione operativa è affidata ad un (chief) Project Manager, se il prodotto è sviluppato in seno ad un’iniziativa più ampia, o ad un (chief) Product Owner, se dualmente si è deciso di avere una struttura di sviluppo orientata in modo esplicito al prodotto. In entrambi i casi, il compito relativo è quello di instaurare un proficuo rapporto di collaborazione e fiducia tra le diverse realtà produttive. 

 Project & Product

Rapporto che inizia ad instaurarsi sin dalla realizzazione del Primo di Serie, in cui la realizzazione dei primi esemplari è a livello prototipale avanzato, consentendo di condividere il know-how necessario alla successiva realizzazione industriale (che può essere anche massiva) del prodotto.

Normalmente l’azione di Manufacturing segue una logica più Lean-oriented (Lean manufacturing nello specifico) puntando sull’efficientamento della produzione e, quindi, sulla razionalizzazione dei costi annessi (costo marginale).

Una volta che il prodotto è operativo, ovvero installato ed in uso presso il cliente, il supporto allo stesso diventa bidirezionale, abilitando la logica del Product Continuous Improvement:

• Aggiornamento predittivo: avviene per azioni del produttore e può essere svolto anche in remoto (si pensi all’aggiornamento del firmware).
• Aggiornamento correttivo: avviene in seguito alla segnalazione di un malfunzionamento o un’anomalia segnala dal cliente.

L’obiettivo dell’approccio presentato è quello di far si che gli eventuali aggiornamenti siano focalizzati, nella quasi totalità, sugli elementi più duttili del sistema, evitando di agire sulle parti che comportano alti costi di intervento (si pensi ad esempio alla meccanica), a meno una revisione totale del prodotto.  Nel caso in cui il prodotto contempli anche l’integrazione del Cloud, inteso qui come approccio architetturale e non come fornitore, tale area è proprio quella maggiormente candidata allo sviluppo di miglioramenti continui. Ovviamente, l’utilizzo del Cloud va contemplato sin dall’inizio perché il prodotto stesso va progettato e realizzato per poterne sfruttare efficacemente le caratteristiche relative.

In questo caso, il product continuous improvement si sviluppa lungo due assi di riferimento (2 axis-improvement approach):

• cloud axis,che si lega in modo ottimale all’azione predittiva;
• hardware axis,che resta ancorato alla logica correttiva.

Un’azione critica da non sottovalutare è quella di strutturare adeguatamente, e per tempo, il piano di Training e di Supporto diretto ai clienti per l’utilizzo del prodotto. Ciò è fondamentale per aumentare il livello di qualità percepita, che trasforma un prodotto tecnicamente di qualità in un prodotto di successo apprezzato dai clienti. 

Con questo ultimo aspetto si chiude, per ora, il viaggio in AgileEngineering.

Continuate a seguirci (vi ricordo che agileconstellation.info è il sito ufficiale) e inviare i vostri feedback.

Stay tuned 

Nel precedente articolo abbiamo iniziato a vedere la fase di Workout che ha lo scopo di finalizzare l’ingegnerizzazione di prodotto, avviando la produzione manifatturiera e preparandosi a supportare adeguatamente i clienti.

Si è visto come tale fase sia basata sua una serie di elementi fondanti che, da un punto di vista operativo, sono espressione di un insieme di obiettivi di riferimento (goal) riportati nella “mappa mentale” seguente:

Workout goals

Nello specifico quindi si ha:

• Quality Gate: un insieme di azioni, test, validazioni e verifiche effettuate sul primo di serie che porta allo sviluppo di tutti gli elementi definitivi e le relative specifiche per la manifattura.
• Delivery Strategy:la strategia di dispiegamento in produzione del prodotto finale.
• Manufacturing Management: il processo di gestione della produzione industriale del prodotto.
• Packaging Verify: la convalida del packaging del prodotto.
• Product Training and Support: le azioni a supporto dell’utilizzo diretto da parte dei clienti e le relative azioni di fixing necessarie.
• Solution Continuous Improvement: l’azione di costantemente miglioramento del prodotto, in particolare con continui aggiornamenti delle aree più duttili dello stesso (es: firmware).
• Retreat Strategy: le opportune azioni di ritiro del prodotto, per obsolescenza o anche in caso di gravi malfunzionamenti.

Un aspetto particolarmente delicato è quello della realizzazione fisica del prodotto (supportato in particolare dalle pratiche annesse al goal di Manufacturing Management). In linea generale il prodotto finale sarà sicuramente basato su un mix tra Market Components e Custom Components, individuando sul mercato la maggior parte di componenti da poter riutilizzare tramite un loro adattamento (per ridurre i costi di produzione), mentre la parte restante verrà realizzata specificamente in funzione delle esigenze del prodotto. 

In ogni caso l’aspetto della produzione manifatturiera diventa un elemento centrale della fase di Workout e come tale va adeguatamente gestito creando un ponte tra il team di progettazione e quello di produzione (interno o esterno che sia) in modo da risolvere le iniziali inevitabile problematiche di realizzazione.

Questo, in particolare, porterà al Primo di Serie (che potrebbe essere seguito anche da ulteriori prototipi se necessario) che, oltre ad avere lo scopo di valutare l’efficacia funzionale del prodotto, aiuterà a settare i corretti processi produttivi e rivedere eventuali ipotesi realizzative per un’efficientamento complessivo.

Tutto ciò trova casa nel Quality Gate goal che dovrà portare alla definizione puntuale di tutti gli aspetti validati, di prodotto e processo, creando la Bill of Materials per l’avvio della produzione.

Nel prossimo articolo continueremo l’esplorazione della fase di Workout attraverso i suoi obiettivi primari e le riflessioni annesse.

Stay tuned 

Come più volte sottolineato, l’output primario sviluppato da un’azione di ingegneria di sistema è composto da diversi elementi afferenti a diverse discipline (ingegneristiche), molto spesso anche fortemente diverse tra loro.

Per questo la delivery (intesa come consegna del prodotto e quanto necessario per il suo corretto uso da parte dei clienti) è decisamente articolata e richiede l’utilizzo di specifiche tecniche di validazione e preparazione, nonché di training e supporto.

L’insieme di queste azioni, che portano il prodotto “nelle mani del cliente” viene definita in AgileEngineering come fase di Workout.

Workout phase

Nella fase di workout si identificano alcuni elementi fondamentali, che, nonostante vadano contestualizzati, sono di riferimento per una struttura gestione della delivery:

• First of Series(Primo di Serie): il “prototipo” industriale del prodotto. In pratica si ha un prodotto industrializzato rappresentativo di quanto verrà successivamente realizzato in modo massivo (o comunque di quanto verrà consegnato al cliente) su cui poter effettuare tutti le valutazioni di pre-produzione.
• Quality Gates: un insieme di azioni, test, validazioni e verifiche effettuate sul primo di serie che porta allo sviluppo di tutti gli elementi definitivi e le relative specifiche per la manifattura.
• Production Ready: sono le specifiche finali, e quanto necessario, per la manifattura.
• Manufacturing: è il processo di produzione industriale del prodotto.
• Final Product: è il prodotto industriale finale.
• Training e Support: ovvero tutte le azioni a supporto dell’utilizzo diretto da parte dei clienti del prodotto e le relative azioni di fixing necessarie.

Come si vede, la fase di workout è di per sé estremamente articolata e necessita del supporto di molte professionalità eterogenee.

In particolare, va sottolineato che la parte di manifattura richiede quasi sicuramente l’ingaggio di un partner esterno per la produzione del prodotto, cosa che sposta il focus su aspetti di gestione e relazione dei fornitori esterni. Normalmente il primo di serie serve per passare dagli strumenti di prototipazione rapida utilizzati nella fase di engineering a elementi industriali, custom o di mercato, per capirne gli impatti e valutarne i costi. Qui la scelta di un fornitore di fiducia è fondamentale per far fronte alle immancabili problematiche tipiche della transizione e lavorare in ottica agile di feedback costanti.

Questi argomenti, e altri elementi della fase di workout, saranno oggetto dei prossimi post in cui andremo ad esplorare il tutto con maggiormente in dettaglio.

Stay tuned 

Con questo nuovo appuntamento relativo ad AgileEngineering concludiamo l’overview relativo alla fase di Engineering, e lo facciamo affrontando due tematiche troppo spesso penalizzate nell’operatività quotidiana per far spazio alla “quantità”: stiamo parlando della qualità e delle metriche.

Quality and Metrics

La qualità è un elemento fondamentale che deve essere posta al centro della visione di progetto e, in particolare, di quella del/dei prodotto/prodotti annessi. Cosa realmente significhi “qualità”, e cosa implichi, dipende molto dal dominio specifico, dagli standard afferenti e dalle regolamentazioni annesse. 

Nonostante ciò, è possibile definire un modello astratto (ispirato alla Test Pyramid) che chiameremo Quality Pyramid e che può essere rappresentato come segue:

Quality Pyramid

L’aspetto fondamentale è che la qualità passa attraverso una serie di test e validazioni a più livelli, cercando di estremizzare l’automazione nei livelli più bassi della piramide dove, normalmente, si realizzano i diversi componenti del prodotto e dove gli sviluppatori usano le pratiche e gli strumenti più adatti al dominio afferente.

È evidente che più si riesce a ottimizzare il testing ai livelli più bassi, meno problemi dovrebbero sorgere quando ci si sposta verso la punta della piramide, dove, generalmente, il focus è di tipo end-to-end (verso l’utilizzatore finale) ed eventuali problematiche hanno un consto di risoluzione molto più alto, alcune volte non assorbibile.

Continuous Quality

In modo molto astratto, AgileEngineering considera la quality come un “gate” abilitante che si basa su un approccio orientato alla Continuous Quality: non esiste il “ni” nella qualità, ovvero o si rispettano le relative attese, oppure il componente/modulo in analisi non è pronto per l’integrazione con gli altri o per la consegna al cliente.

L’approccio alla Continuous Quality indica l’attenzione ad un miglioramento continuo nelle pratiche e negli strumenti affini, evidenziando ancora una volta come l’evoluzione contingente, e pragmatica, sia alla base di una buona gestione di tutto quanto afferisce a un prodotto complesso, rispetto al quale la conoscenza si affina proprio durante la sua realizzazione.

Il miglioramento non può però essere lasciato (unicamente) all’intuito, ma deve basarsi su dei dati oggettivi, dei numeri, che possano evidenziare dei fatti e non dare adito ad opinioni che sono sempre affette dalla propria capacità e declinazione interpretativa.

Proprio per questo, AgileEngineering definisce una serie di metriche di base che aiutano a valutare oggettivamente la capacità di sviluppo e di reazione dei team di lavoro:

Metrics

In particolare, si hanno:

• Il Cycle Time, che calcola il tempo medio impiegato per completare l’intero ciclo di lavorazione di un componete e/o un modulo.
• Il Lead Time, che calcola il tempo medio impiegato per completare l’intero ciclo di lavorazione di un sotto-insieme del prodotto (generalmente composto da più componenti, moduli) che può essere consegnato al cliente.
• Il Mean Time to Recovery (MTTR), ovvero il tempo medio di risoluzione di un problema.

Si tratta, chiaramente, di metriche di base, che normalmente vengono integrate con indicatori specifici del contesto, ma che sono al contempo particolarmente utili per accelerare le capacità di improvement dell’interno team di delivery.

Con questo appuntamento si chiude la nostra overview sulla fase di Engineering. Nel prossimo appuntamento ci concentreremo sulla fase di Workout, ovvero di “consegna” del prodotto.

Stay tuned

Continuiamo l’esplorazione della fase di Engineering nell’ambito dell’agile applicato all’ingegneria di sistema. Andremo a parlare dell’efficientamento dell’impiego delle risorse dando uno sguardo più di dettaglio alla composizione dei team.

In linea con la filosofia Agile, dobbiamo distinguere attentamente tra: risorse immateriali e risorse umane(meglio Persone), in modo da non perdere mai di vista l’attenzione allo sviluppo di un ambiente collaborativo in grado di migliorarsi costantemente.

Resta però un fatto evidente: non sempre avere un team con tutte le competenze necessarie ad affrontare un progetto, e un prodotto nella specifica are del Value Stream di implementazione, è efficiente da un punto di vista di ottimizzazione della loro allocazione. Ciò è, inoltre, valido anche per la stessa motivazione delle persone: una persona che da un contributo marginale durante una iterazione e deve “trovarsi” le attività da fare, non sviluppa un valido senso di appartenenza perché non riesce a trovare la propria vocazione operativa specifica.

Si evidenziano così 4 fattori specifici, qui definiti GEMI da tenere in conto nella creazione dei team per stimolare adeguatamente le persone e avere un “ambiente” idoneo al raggiungimento di obiettivi sempre più d’avanguardia:

• Goals, che sottende la capacità di avere degli obiettivi condivisi, chiari e ben identificati;
• Efficiency, tutte le attività devono sempre tenere in conto l’ottimizzazione delle risorse disponibili in relazione ai vincoli di contesto;
• Motivations, ovvero la capacità (qui i manager giovano un ruolo chiave) di motivare adeguatamente le Persone, creando un opportuno percorso di crescita “sociale” e professionale;
• Innovations, lavorare sempre su iniziative sfidanti che stimolano un continuo riallineamento dello State of Flow, ovvero la condizione di maggior stimolo per le persone.

GEMI factors

I diversi specialisti sono organizzati il più possibile in team multidisciplinari focalizzati su obiettivi, anche se bisogna sottolineare uno specifico effetto. Se è vero, infatti, che questo favorisce molto la capacità di essere focalizzati su un obiettivo complessivo di valore (e non locale), è anche vero che quando le attività sono estremamente specialistiche (ad esempio relativi ad aspetti derivanti da normative impattanti sul prodotto) non sempre tale scelta si rileva vincente, in quanto non è possibile “replicare” le competenze relative per ogni team e, oggettivamente, non trova ragionevole sostenibilità, di costo e di ingaggio.

Si ha così la necessità di far convivere dei veri cross-domain team, composti ad esempio da esperti in: meccanica, elettronica, software, chimica, ecc… con un gruppo di supporto che supporti i diversi team e sia prontamente disponibile. È fondamentale evidenziare che non si sta parlando di creare una “funzione” organizzativa, ma una sorta di loan team comunque dedicato al progetto.

Cross-domain teams and Loan team

I diversi cross-domain team si auto-organizzarono, quindi con un approccio fortemente bottom-up, con il supporto di un Product Owner (o Agile Project Manager) che li aiuta a restare focalizzati sugli obiettivi generali e dirimere il più possibile le dipendenze tra le attività specifiche su cui si sono ingaggiati.

Si possono quindi avere due scenari di riferimento: 

• un prodotto sviluppato da un unico team composto da tutti gli specialisti necessari. Questo scenario, seppur semplificando le diverse problematiche di dipendenza e coordinamento, è il meno realistico viste le complessità affrontate dall’ingegneria di sistema e la necessità di avere tempi ragionevoli nello sviluppo dei nuovi prodotti.
• un prodotto sviluppato da più team in parallelo. In questo caso, quello più comune, è fondamentale sviluppare una opportuna leadershipdi coordinamento per consentire ai diversi team di efficientare le proprie attività grazie ad una collaborazione efficace e snella.

One Cross-Domain team

Multi Cross-Domain team

Indipendente dallo schema organizzativo seguito, resta in essere il succitato loan team di supporto su argomenti specialistici non necessari nel quotidiano.

Con questo approfondimento sull’organizzazione dei team, si chiude il nostro secondo appuntamento dedicato alla fase di Engineering di AgileEngineering. Nel prossimo incontro affronteremo la questione della qualità, passando per testing e metriche annesse.

Stay tuned J