Cliccate sul link per la prima parte di questo articolo su MIL-HDBK-502: il processo di acquisizione e l’ingegneria di sistemi (1^ parte).
Introduzione
Proseguiamo con la seconda parte della serie di articoli in tema di logistica dell’acquisizione (acqusition logistics o acquisizione logistica) e l’ingegneria dei sistemi, sempre nella visione proposta della MIL-HDBK-502 del Department of Defense (DoD) degli Stati Uniti d’America.
In questo articolo approfondiremo il concetto di ingegneria dei sistemi allo scopo di darne una sintesi e una visione sotto forma di processo ed inizieremo ad esplorare il suo rapporto con la supportabilità.
Il processo di ingegneria dei sistemi
L’ingegneria dei sistemi (o ingegneria di sistema) è un processo finalizzato a un approccio interdisciplinare che, in maniera evolutiva e verificata, porti ad un insieme di prodotti e di processi in grado di soddisfare le necessità esplicitate da un cliente. Molto spesso il cliente rappresenta più parti interessate e ne è la semplificazione dal punto di vista della sintesi. Ciò significa che, nel seguito, quando parleremo di necessità del Cliente, in realtà intenderemo le necessità delle varie Parti Interessate (Stakeholders).
L’approccio interdisciplinare dell’ingegneria dei sistemi consente di far evolvere in maniera armonica, nell’intero ciclo di vita, una soluzione ottimale per le esigenze del Cliente. Grazie a tale approccio si arriverà non solo ad avere il sistema richiesto dal Cliente ma anche il Supporto Logistico Integrato (integrated Logistic Support o ILS) che gli è necessario per funzionare come atteso.
Affinché ciò avvenga andrà progettato l’intero sistema, nel senso più ampio possibile, includendo non solo hardware e software ma anche le risorse logistiche via via pianificate.
Il processo dell’ingegneria dei sistemi integra, quindi, gli elementi essenziali e le più importanti decisioni progettuali dei tre ambiti di progettazione suddetti (hardware, software e supporto logistico). Il risultato sarà quindi una soluzione complessiva di sistema che, in maniera equilibrata, risponderà alle esigenze operative e permetterà il conseguimento degli altri obiettivi del programma in questione.
Nella visione della MIL-HDBK-502, il processo di ingegneria di sistema procederà traducendo le esigenze operative in requisiti, e i requisiti in progetti che soddisfano le prestazioni, i costi e le tempistiche richieste.
In pratica, il processo di ingegneria dei sistemi procederà in maniera top-down, raffinando via via il progetto. Si tratta quindi di un processo iterativo nel quale i requisiti operativi sono tradotti in requisiti prestazionali degli elementi funzionali del sistema. Per ciascuno di essi vengono identificate e analizzate le possibili alternative progettuali e, con tali risultati, si procede alla selezione della combinazione ottimale di elementi progettuali per soddisfare gli obiettivi del sistema. I requisiti prestazionali sono, quindi, raffinati in base alle alternative selezionate e, una volta aggiornati i requisiti relativi, questi vengono di nuovo utilizzati, aumentando nel dettaglio, per il successivo livello funzionale e via dicendo.
Questa decomposizione funzionale progressiva dei requisiti continua fino ad arrivare al livello più basso possibile di una funzione prestazionale. Qui giunti il processo di progettazione s’inverte e diventa bottom-up, producendo i componenti fisici del progetto (sintesi), le loro connessioni e le verifiche necessarie per garantire la coerenza con quanto previsto dal livello superiore. Tutte le stime e le previsioni vengono a questo punto raffinate e verificate mediante dimostrazioni e test.
In breve, l’analisi dei requisiti passa prima all’analisi e all’allocazione delle funzioni (iterativamente) e da questa passa alla sintesi dei componenti (anche questo in maniera iterativa).
Allo scopo di selezionare correttamente le scelte progettuali tra le varianti disponibili è necessaria, però, un’attività di analisi e controllo del sistema.
L’attività di analisi e controllo del sistema (detta anche bilanciamento del sistema) si compone di numerose attività che in genere includono, come minimo, le seguenti:
- Studi per la definizione di compromessi tra requisiti, alternative progettuali ed altri aspetti;
- Attività di gestione del rischio in grado di identificare potenziali fonti di rischi tecnici relativi alle tecnologie utilizzate, alla progettazione, produzione e altro ancora, allo scopo di mitigarne gli effetti;
- Gestione della configurazione per mantenere sotto controllo tutti i componenti del sistema, ossia: i prodotti del sistema, i processi che lo riguardano e la documentazione relativa;
- La gestione dei dati per mantenere un insieme di dati tecnici, con relativa tracciabilità, necessario per coordinare le varie attività e per sviluppare correttamente il sistema;
- La definizione di metriche prestazionali per poter misurare la reale evoluzione dello sviluppo e della progettazione rispetta quanto pianificato;
- L’impostazione di controlli di interfaccia per garantire che tutte le modifiche sulle interfacce interne ed esterne siano opportunamente registrate e trasferite a tutti gli oggetti in configurazione che ne possono essere interessati;
- Riesami strutturati del programma per dimostrare e confermare il raggiungimento degli obiettivi di programma o di milestone.
La definizione del miglior insieme di risorse logistiche da pianificare per un sistema è lo scopo primario della logistica dell’acquisizione intesa come una branca dell’ingegneria dei sistemi. Ciò avviene mediante l’analisi di quelle caratteristiche progettuali che possono generare una necessità o che sono associate ad una necessità che implichi il dover fornire un supporto operativo al sistema nel suo insieme.
Queste caratteristiche progettuali sono sviluppate da numerose discipline e in un ampio contesto di attività. Singolarmente possono essere considerate come caratteristiche progettuali relative ad hardware, software o di supporto ma, nel insieme esse rappresentano la “supportabilità” di un sistema completo.
La Supportabilità
Per supportabilità si intende il grado con cui le caratteristiche progettuali del sistema e le risorse logistiche pianificate soddisfano i requisiti sia in tempo di pace che di guerra.
La supportabilità è la capacità del progetto di un sistema completo di soddisfare, ad un costo ragionevole, i requisiti operativi di prontezza nell’intera vita di servizio del sistema.
La supportabilità fornisce i mezzi per valutare l’adeguatezza del progetto di un sistema completo a un insieme di requisiti operativi all’interno di un preciso ambiente di operazione e di supporto (inclusivo, tra l’altro, dei vincoli di costo).
Le caratteristiche di supportabilità in genere includono molte misure prestazionali degli elementi individuali di un sistema. Esempi tipici sono il tempo di un ciclo di riparazione (Repair Cycle Time o RCT), il tempo medio tra due guasti (Mean Time Between Failures o MTBF) e il tempo medio di riparazione (Mean Time To Repair o MTTR). Queste tre metriche sono delle caratteristiche di affidabilità e manutenibilità ma, in virtù del loro impatto sul supporto operativo del sistema completo, diventano anche caratteristiche di supportabilità.
Le caratteristiche di supportabilità del sistema completo vanno a relazionare tra loro le singole caratteristiche progettuali fornendone una sintesi di alto livello in grado di dare una valutazione complessiva del progetto del sistema.
La disponibilità operativa e il costo del ciclo di vita sono due grandezze normalmente utilizzate nella misura della supportabilità del sistema completo.
Un altro importante criterio di supportabilità, comune praticamente a tutti i programmi di acquisizione, è, ovviamente, il costo.
Il costo nella supportabilità
I vincoli di costo sono inevitabili. Ottenere sistemi a fronte di un processo di acquisizione significa tenere in considerazione, ineludibilmente, i costi legati agli investimenti, alle operazioni e al supporto.
Le stime del costo del ciclo di vita devono confrontare tra loro i costi delle differenti alternative di sistema sia in tema di investimenti che di costi ricorrenti di gestione.
Le analisi di costo devono tenere in massima considerazione le risorse del supporto logistico necessarie per ottenere i previsti livelli di prontezza, tra l’altro secondo i vari punti di vista derivanti dalle assunzioni fatte sull’affidabilità del sistema, su suoi tassi d’utilizzo, sugli scenari operativi e sulle caratteristiche di manutenibilità.
La stima dei costi di alcune risorse (ad esempio la manodopera e l’energia) è soggetta ad una certa alle aleatorietà e ciò implica la necessità di effettuare analisi di sensitività, in modo da identificare e pesare adeguatamente i vari fattori che concorrono alla formazione del costo del ciclo di vita.
Conoscere i costi è la chiave per comprendere e gestire i rischi legati al programma di acquisizione.
Di conseguenza tutti gli elementi principali del costo del ciclo di vita devono essere identificati e considerati parte delle attività di analisi di sistema e di controllo. Tutto ciò con l’obiettivo di minimizzare i costi all’interno dei vincoli più importanti quali, ad esempio i requisiti di prontezza o di disponibilità operativa.
Una continua valutazione dei costi del ciclo di vita durante la fase di acquisizione e anche durante la fase di servizio nel Sistema forniscono un’importante analisi di quanto sia efficace la gestione del ciclo di vita. Queste valutazioni devono essere effettuate non solo perché i costi cambiano il tempo ma anche perché quello che inizialmente ritenuto accessibile nel tempo può cambiare e quindi, ad esempio al variare delle condizioni economiche complessive, ciò che era accettabile inizialmente potrebbe diventare non più accettabile. Inoltre è importante tenere costantemente sotto controllo le possibilità e le opportunità di ridurre i costi di gestione del sistema attraverso tutte le fasi della sua vita.
Equipment readiness
La prontezza (readiness) è la misura della capacità di un’organizzazione di assolvere determinate responsabilità di missione nel momento in cui è chiamata a farlo.
Una combinazione della disponibilità operativa e della frequenza di missione è, in genere, un’eccellente misura di prontezza.
I requisiti di prontezza per un sistema variano da sistema a sistema, così come tra il tempo di pace e quello di guerra, ma la predizione delle prestazioni di questa metrica sono importanti per valutare l’accettabilità dal punto di vista operativo di un prodotto prima della sua immissione in servizio.
Vincoli in termini di manodopera personale
La riduzione della manodopera e l’aumentata complessità dei sistemi della difesa (ma vale in generale per sistemi complessi) si è rivelata una sfida molto significativa con cui confrontarsi per ottenere sistemi difensivi (ma anche sistemi complessi per uso civile o duale) accettabili.
Stime molto anticipate dei requisiti di manodopera e di personale sono molto importanti e devono essere confrontati con i vincoli derivanti, in genere, da aspetti legati ai costi o all’ambiente operativo.
I vincoli sulla manodopera e sul personale, poiché vanno ad impattare sulle prestazioni, sulla prontezza e sui costi, devono essere identificati ed esaminati molto presto, valutando più alternative possibili.
I sette principi dell’ingegneria dei sistemi
L’ingegneria dei sistemi dovrà quindi basarsi su sette principi fondamentali che sono:
- Conoscere il problema, il cliente e l’utilizzatore, conoscenza che può aversi solo con un loro diretto coinvolgimento e immedesimandosi nelle loro aspettative e nelle loro necessità;
- Prendere decisioni efficaci, considerando criteri decisionali che siano misurabili, ossia obiettivi e quantificabili;
- Stabilire e gestire i requisiti, in particolare assicurandosi che il cliente e l’utilizzatore finale comprendano e accettino i requisiti;
- Identificare valutare le alternative per poter convergere verso una soluzione ottimale, mediante l’utilizzo di una metodologia progettuale sistematica;
- Verificare e validare i requisiti e le soluzioni prestazionali, ponendo massima attenzione alla progettazione in qualità e alla predizione dei risultati attesi detesta;
- Mantenere l’integrità del sistema, mantenendo una costante presenza dell’ingegneria dei sistemi per tutta la durata del programma;
- Utilizzare processi documentati e articolati, possibilmente con un forte aiuto da strumenti automatizzati, ove opportuno.
Conclusioni
Questa seconda parte ha introdotto quello che sarà uno degli argomenti più importanti di questa serie di articoli e cioè le analisi di supportabilità. In questo articolo la supportabilità è stata inquadrata nell’ambito dell’ingegneria dei sistemi come la misura del grado di capacità del supporto logistico di soddisfare i requisiti richiesti. Come si è potuto vedere, la supportabilità è strettamente connessa alle soluzioni progettuali adottate e dovrà quindi essere fortemente coordinata con il loro procedere.