MIL-HDBK-502:il processo di acquisizione e l’ingegneria di sistema (1^ parte)

Il processo di acquisizione secondo la MIL-HDBK-502

In questo articolo viene iniziata la trattazione del rapporto che esiste tra il processo di acquisizione e l’ingegneria di sistema secondo quanto indicato nella norma MIL-HDBK-502 “Acquisition Logistics”.

La logistica dell’acquisizione viene definita come una disciplina tecnico gestionale multifunzionale associata con la progettazione, lo sviluppo, il test, la produzione, il passaggio operativo, il mantenimento e le modifiche migliorative relative ad un sistema economicamente sostenibile in grado di soddisfare i requisiti di prontezza dell’utente, sia in tempo di pace sia in tempo di guerra.

Sebbene la norma sia una norma militare e tratti di aspetti legati comunque ad un contesto bellico, è importante sottolineare che i principi, molti dei processi e i risultati ottenibili seguendo quanto indicato nella MIL-HDBK-502 possono essere facilmente, e con grande vantaggio, applicati ad altre realtà che abbiano le seguenti caratteristiche:

• significativa complessità del sistema
• alternanza di periodi operativi con requisiti molto più performanti e di periodi di riposo con requisiti più permissivi
• vita attesa del sistema significativamente lunga
• rapporto costo prestazioni desiderato il più ottimale possibile

In sistemi con queste caratteristiche è molto proficuo applicare la norma suddetta, mutatis mutandis, in particolare se ciò avviene nel settore aerospaziale così come in quello navale o in quello degli impianti industriali.

I principali obiettivi della logistica dell’acquisizione sono garantire che:

• i requisiti del supporto divengano parte dei requisiti di progettazione del sistema
• il costo del supporto del sistema attraverso il suo ciclo di vita sia sostenibile dal punto di vista economico
• tutti gli elementi di infrastruttura necessari, sia per le prime attività sul campo sia per il supporto operativo del sistema, vengano identificati, sviluppati e acquisiti per tempo

Come si può notare questi obiettivi sono comuni a praticamente tutti i sistemi complessi o critici e questo rende la norma un’utile fonte di informazioni e di riflessioni in moltissimi casi, soprattutto se si considera che la frazione più significativa del costo del ciclo di vita di un sistema è in genere relativa ai costi operativi e di supporto una volta che il sistema è stato dispiegato sul campo. Poiché tali costi sono fortemente determinati già nelle prime fasi di sviluppo del sistema è indispensabile che gli sviluppatori siano in grado di valutarli il più anticipatamente possibile, esaminando anche i costi operativi di supporto di differenti soluzioni progettuali.

La logistica dell’acquisizione è molto più efficace se le attività relative vengono svolte coinvolgendo sia il Cliente (nella norma riferito come il Governo) sia il Fornitore in tutti i processi gestionali e tecnici dell’ingegneria di sistema. La ragione di questo vantaggio è insita nella possibilità di trovare rapidamente i migliori compromessi possibili che necessariamente andranno definiti per poter soddisfare tutti i vincoli operativi e gli obiettivi del processo di acquisizione.

Il processo di acquisizione dei sistemi per la Difesa (secondo il DoD)

Il processo di acquisizione di un sistema secondo la norma deve innanzitutto tenere in considerazione il ciclo di vita di un sistema. Esso deve inoltre prendere in considerazione il fatto che la sua natura è intrinsecamente ciclica in quanto, molto spesso, l’acquisizione di un nuovo sistema deriva dall’incapacità del suo predecessore di soddisfare determinati requisiti operativi, economici o di altra natura. Di conseguenza è opportuno immaginare il processo dell’acquisizione come una serie di iterazioni in cui un sistema viene sostanzialmente migliorato nelle proprie capacità o sostituito da uno o più performante.

In quest’ottica tutte le informazioni acquisite nel ciclo di vita del sistema precedente possono essere molto utili per lo sviluppo del nuovo sistema.

Oltre ad essere ciclico, il processo di acquisizione deve essere sufficientemente flessibile da poter affrontare l’ampia gamma di potenziali soluzioni a fronte di evidenti necessità, opportunità o carenze emerse durante il ciclo di vita.

Ai fini della Logistica dell’Acquisizione, nel processo di acquisizione le analisi di supportabilità diventano un aspetto importantissimo e dovranno essere condotte con due obiettivi fondamentali:

• garantire che la supportabilità sia a tutti gli effetti un requisito prestazionale del sistema
• assicurare la definizione di un’infrastruttura e di un progetto del sistema ottimali dal punto di vista del supporto

Le analisi di supportabilità che dovranno essere eseguite saranno ovviamente molto diverse da caso a caso e da fase a fase.

Allo scopo di governare il processo di acquisizione è necessario che sia definito un processo di gestione dell’acquisizione. Grazie al processo di acquisition management, il processo di acquisizione verrà suddiviso, come anticipato, in fasi di logiche sequenziali, ciascuna con specifici obiettivi e specifiche questioni da affrontare, in genere correlate con uno degli stati ingegneristici di progettazione. Una fase potrà dirsi conclusa quando avrà fornito una risposta a tutte le questioni in essa previste e avrà raggiunto tutti gli obiettivi desiderati. Completata una fase si potrà passare alla successiva.

Il passaggio da una fase all’altra è però sottoposto a dei punti decisionali in cui vengono effettuati dei riesami a livello di intero sistema che valuteranno se la fase precedente è stata completata con successo o meno e permetteranno di stabilire se passare alla fase successiva o ritornare su quella che si pensava appena completata.

Come può essere facilmente intuibile, il numero e le caratteristiche delle fasi varieranno da programma a programma e la loro definizione è uno dei primi obiettivi del processo di management.

Le tipologie di acquisizione

In genere le acquisizioni vengono classificate in base alla complessità dell’attività progettuale che richiedono per completare un sistema. Molto spesso si usano quattro tipologie base che sono, in ordine crescente di preferenza (per il DoD):

• di un sistema esistente
• acquisizione di un componente commerciale
• acquisizione di un componente non-developmental (NDI o non-developmental item), ossia di un oggetto già sviluppato in precedenza
• sviluppo ex novo

Stabilire il tipo corretto di programma di acquisizione da implementare è il primo e il più importante passo nella determinazione dei quali attività dell’ingegneria di sistema dovranno essere incluse nella strategia di un programma di acquisizione.

Per effettuare tale scelta la norma propone un processo decisionale (acquisition decision process) così fatto:

1. vengono identificati i requisiti operativi
2. ci si chiede se tali requisiti richiedano un qualche equipaggiamento o una qualche fornitura (nel gergo militare e in quello logistico ciò viene indicato come “Materiel”). Se la risposta è no significa che non è necessario un processo di acquisizione e quindi il processo decisionale termina
3. se invece necessario acquisire un materiel si verifica se già esiste un sistema che soddisfi o possa soddisfare i requisiti richiesti. In caso affermativo l’acquisizione procede come un’acquisizione d’uso o modifica di un sistema esistente
4. in caso contrario viene fatta un’analisi di quanto offre il mercato e si valuta se esiste un componente commerciale in grado di soddisfare i requisiti. Se la risposta è positiva si procede con un iter di acquisto
5. in caso contrario si valuta se è disponibile un NDI. In caso affermativo si procede, anche qui, con un processo di acquisto
6. in caso contrario si procede con il processo di sviluppo di un sistema ex novo

La preferenza accordata dal DoD ai componenti commerciali rispetto a quelli NDI risiede fondamentalmente sull’aspetto economico che, per molteplici ragioni, è molto più appetibile nel caso dei componenti commerciali. Ovviamente qualora il requisito economico fosse secondario l’ordine di preferenza potrebbe essere differente.

Nel caso in cui il processo decisionale di acquisizione portasse alla scelta di sviluppare un nuovo sistema è comunque opportuno ripetere lo stesso processo decisionale per tutti i componenti dei sottosistemi del nuovo sistema (e via ricorsivamente).

La strategia di acquisizione

A prescindere dalla tipologia di programma di acquisizione identificata, è indispensabile definire una strategia di acquisizione che dettagli i requisiti, l’approccio e gli obiettivi del programma. Lo sviluppo di tale strategia dovrà iniziare immediatamente dopo la definizione della tipologia di acquisizione, ossia al termine del processo decisionale di acquisizione.

La norma definisce come preferibili le strategie che puntano a “sistemi aperti” ossia basati su prodotti non proprietari dei Cliente e su sistemi di elaborazione non isolati. Sebbene tale conclusione sia ampiamente condivisibile non è detto che debba essere la soluzione migliore in tutti i casi e andrà riesaminata di volta in volta.

La flessibilità della progettazione

La disponibilità di ampi margini di manovra in fase di progettazione del sistema (supporto incluso) è essenziale per definire quali analisi di supportabilità potranno e dovranno essere eseguite.

L’obiettivo della maggior parte delle attività di progettazione del sistema di supporto è in genere focalizzato nell’identificare degli aspetti del supporto (ad esempio i vincoli) che possano influenzare la selezione delle soluzioni progettuali del sistema, così come delle varie alternative di supporto, in grado di influenzare la prontezza, la supportabilità e il costo.

Ad esempio se il progetto dell’hardware è fissato (come accade in un componente commerciale o NDI) un’elevata flessibilità può essere poco utile mentre nel caso di un programma di miglioramento di prodotto, ad esempio, essa può rivelarsi essenziale. In altri casi, ad esempio, la flessibilità può essere possibile a livello della progettazione del supporto ma non del sistema.

Inoltre, l’integrazione dei requisiti di supportabilità nella fase di progettazione di un sistema e dell’equipaggiamento necessario implica che i progettisti siano orientati verso gli obiettivi di supportabilità sin dall’inizio.

La disponibilità delle risorse

Le analisi di supportabilità costano in termini di tempo e di risorse. È privo di senso imporre dei requisiti di supportabilità che dipendano da analisi i cui risultati non saranno disponibili in tempo utile per contribuire alle scelte progettuali su cui dovrebbero avere effetto (anche se in alcune situazioni ciò può essere corretto, ad esempio in presenza di futuri programmi di miglioramento).

Più in generale le analisi di supportabilità dovranno fare i conti con le risorse economiche e temporali disponibili. Di conseguenza potrà accadere (accade sempre) che siano possibili solo alcune analisi e non tutte. Tale limitazione potrà dipendere da fattori economici (in tal caso solo variazioni di budget possono superarla) così come da altri fattori. Nel caso in cui determinate analisi non vengano condotte perché, pur esistendo le risorse finanziarie, non esistono quelle di altra natura, si potrà allora ipotizzare il ricorso ad un programma di supporto in cui vengano reclutati fornitori con la disponibilità delle risorse necessarie (expertise, attrezzature, …).

Un altro approccio, quando le risorse sono insufficienti, consiste nello sfruttare le relazioni tra le differenti analisi in modo da ottenere il massimo dei risultati possibili mediante analisi esatte, ad esempio, e stime su di esse basate. In questo modo sarà possibile, al costo di una maggiore approssimazione dei risultati, ridurre il numero di analisi di supportabilità necessarie e, di conseguenza, rientrare nelle risorse disponibili.

Risultati di lavori precedenti

Lavori svolti in precedenza possono avere un grosso impatto sulla selezione delle analisi di supportabilità necessarie in quanto i fattori più importanti del supporto e le varie azioni migliorative possibili potrebbero essere già state identificate e sviluppate sia in studi precedenti sia, soprattutto, nella documentazione preparatoria all’avvio del programma su cui si sta lavorando.

Non sempre questi risultati sono sufficientemente aggiornati o di qualità adeguata per cui tali aspetti dovranno essere presi in considerazione nel selezionare quali lavori potranno essere riutilizzati e quali no.

Molto spesso questi risultati rappresentano un punto di partenza che, fatte le opportune verifiche e i necessari aggiornamenti, può risultare utile e più avanzato che se si partisse da zero.

Esperienza e dati disponibili

La disponibilità di esperienze e di dati storici su sistemi simili è in genere indispensabile per poter condurre in porto determinate analisi di supportabilità.

I dati disponibili dovranno essere esaminati per valutare lo sforzo necessario per poterli utilizzare nello sviluppo del nuovo sistema, verificando al contempo che possano essere utilizzati per questo scopo.

Se i dati disponibili non sono sufficienti è possibile utilizzare tecniche di stima statistica che, a partire da un campione, permettano di ottenere delle stime dei valori desiderati.

Un altro aspetto importante relativo ai dati disponibili è un rischio che spesso si corre nei programmi di acquisizione e cioè il fatto che si prendano delle decisioni prima di avere una sufficiente conoscenza degli elementi progettuali, con un conseguente incremento del rischio di modifiche o fallimenti.

Considerazioni legate alla fase in cui ci si trova

Come già detto, ognuna delle fasi di acquisizione è normalmente caratterizzata da delle questioni da affrontare e da degli obiettivi da raggiungere. Tali questioni e tali obiettivi dipendono dal livello di progettazione a cui si è giunti (concettuale, funzionale, allocata, fisica).

L’esperienza ha insegnato che in molti casi è più opportuno che la struttura delle fasi si adatti ai requisiti del programma in modo, ad esempio, da condurre le analisi di supportabilità al momento giusto e quindi, per esempio, distribuendole su più fasi o collassando più fasi in un’unica fase.

Conclusioni

In questo primo articolo è stato esaminato il processo di acquisizione di un sistema per la difesa secondo lo standard MIL-HDBK-502. Sebbene in forma sintetica, è stato possibile impostare le premesse per entrare più nel merito dell’ingegneria di sistema e delle analisi di supportabilità.

Cliccate sul link per la seconda parte di questo articolo su MIL-HDBK-502:il processo di acquisizione e l’ingegneria di sistemi (2^ parte).