CARABINIERI

Arturo INTELISANO
Laureato in Fisica presso l'Univesrità degli Studi di Roma. Capo Progetto del Satellite BISSAT nell'ambito della missione ASI "SABRINA" dell'Alcatel Alenia Space Italia.

Questa nota introduttiva all'attività di procurement ha lo scopo di fornire una panoramica sommaria degli aspetti principali che la riguardano. In realtà si tratta di una descrizione "concettuale" e non didascalica; si è scelta questa formulazione con l'intento di delineare più le problematiche che incontra chi tale attività svolge che non i dettagli che cambiano a seconda dell'area di ingegneria interessata o della singola azienda.
Come spesso accade per i termini anglosassoni entrati per consuetudine nel vocabolario di uso corrente, la traduzione letterale che verrebbe spontaneo attribuire al termine "procurement", quella di "approvvigionamento", non risulta propriamente calzante all'attività che qui si intende introdurre nelle sue linee basilari.
In effetti l'idea alla quale la terminologia italiana rimanda non esprime la correlazione diretta che il procurement ha con la disciplina progettuale, nell'ambito dello sviluppo di tecnologie avanzate.
Reperire forniture non è semplicemente un'attività negoziale in cui ciò che si acquisisce è perfettamente ben delineato e occorra definire solo i termini economici e contrattuali della transazione. Quanto più infatti un componente o un'intera unità sono in fase di progetto, tanto più è necessario seguire in più fasi il suo avanzamento.
Non si parla più solo dell'aspetto contrattuale, ma dello sviluppo di un processo che è un elemento chiave per la realizzazione di un progetto complesso.
Forse, più che reperimento o approvvigionamento, sarebbe più corretto parlare di "gestione delle forniture". I puristi potrebbero obiettare che si gestisce qualcosa che già si ha e che non occorre reperire; in questo senso, allora, potremmo parlare di "forniture" in senso lato; ciò però è vero nell'ottica dello sviluppo di un progetto in itinere, come si mostrerà più avanti.
L'approvvigionamento di componenti o di unità di alto contenuto tecnologico ha mutato metodologie e concetti di base nell'era del mercato globale. Nei fatti è il mercato globale che ha trasformato la classica visione autarchica o locale del prodotto tecnologico, visto come risultato finale di un insieme chiuso (nazionale o regionale) di competenze.
Immaginare un progetto come un insieme di parti da integrare, sviluppate magari in aziende o in Paesi diversi, pone la questione dell'"integrazione" all'interno di un "sistema".
Integrazione e sistemistica sono termini che, a partire più o meno dagli anni '50 (L. Von Bertalanffy) hanno cominciato ad essere inseriti nell'ingegneria progettuale attraverso metodologie sempre più classificate e controllate. All'inizio tali metodologie rappresentavano (e per certi versi rappresentano ancora) il DNA aziendale, uno degli elementi chiave caratterizzanti la specifica cultura aziendale.
Successivamente l'integrazione o il riuso di componentistica già sviluppata ha portato alla necessità di definire degli standard metodologici in grado di;
- minimizzare i rischi;
- condividere un "linguaggio" comune nello scambio delle informazioni;
- definire criteri di compatibilità.
Per cercare di capire da cosa in realtà emerga questa necessità che ho appena abbozzato, ricorriamo ad un esempio concettuale piuttosto semplice. Immaginiamo di dover realizzare un progetto complesso, composto da più parti. Tipicamente, nel tentativo di definire un primo schema evolutivo delle componenti essenziali di ciò che ci accingiamo a fare, pensiamo a una serie di blocchi del tipo:

Lo schema evolutivo di un qualunque processo dinamico (economico, sociale, fisico, biologico) rappresentato in questo modo, che indichi la freccia del tempo nell'evoluzione del processo, pecca della mancanza di un ingrediente fondamentale alla sua più completa rappresentazione: il concetto di feedback (o retroazione). Per quanto completo o dettagliato possa essere il progetto che si voglia portare avanti, non si può immaginare che il processo in atto non si sviluppi piuttosto secondo una dinamica che è la seguente:

è chiaro che la tendenza temporale primaria rimane, ma le componenti retroattive sono ineliminabili per principio; un loro razionale controllo è l'elemento chiave di una corretta prevenzione del rischio e, più in generale, di una corretta attività di management. Ho usato un termine importante: controllo. La "Teoria del Controllo" sta sempre più uscendo dai suoi domini classici, ingegneristici, legati alle macchine, per entrare nelle dinamiche progettuali a un livello più alto. Controllare significa, di fatto, avere accesso a una serie di variabili (osservabilità) e modificarle in funzione del grado di retroazione che si intende ottenere.

Controllare significa definire pesi e guadagni, secondo gerarchie che sono basate sul grado di definizione dei sottoprocessi (WBS - Work Breakdown Structure) e sulla condivisione di un linguaggio comune. L'articolazione in sottoprocessi è un problema connaturato alle metodologie utilizzate in azienda e alle competenze presenti. La condivisione di un linguaggio comune non è un problema che può rimanere circoscritto all'ambito aziendale ma che, come indicato precedentemente, è legato al fatto che stiamo parlando di "sistemi aperti" in interscambio reciproco.
Riguardo alla standardizzazione è compito di organismi internazionali mediare e uniformare gli standard; aderire alle direttive di tali organismi è divenuto un requisito che riveste un peso contrattuale sempre maggiore; è l' Agenzia internazionale a fissare le linee guida dei processi che possono poi comunque arricchirsi degli standard in uso nelle singole aziende.
Prima però di portare un esempio pratico di direttiva a livello internazionale torniamo all'analisi del meccanismo di controllo nell'ambito del procurement.
Il livello di controllo avviene attraverso un'unità di informazione fondamentale: quella di "requisito". In fondo qualunque progetto nasce da un'idea di massima che viene poi specializzata in più componenti: esisteranno quindi "requisiti padre" da cui discendono in scala requisiti di grado inferiore. Un requisito padre potrebbe essere "Ho la necessità di mangiare entro un'ora"; un requisito figlio potrebbe essere "l'ora di riferimento è basata sull'orologio Big Ben di Londra" o "è possibile nutrirsi solo di vegetali". L'arte del definire i requisiti sta nel capire le loro relazioni gerarchiche: ad esempio, i due sottorequisiti citati possono essere considerati allo stesso livello? In ogni caso, quanto sono correlati?
A prima vista sembrerebbero completamente scorrelati e quindi situati sullo stesso piano.
Tuttavia il contesto potrebbe definire gradi di correlazione imprevisti; se fossi dalle parti del Parlamento Britannico e fossi obbligato dal primo requisito a tenere gli occhi sulla torre dell'orologio, tra i tanti squisitissimi (si fa per dire) ristorantini nelle adiacenze sarei obbligato "di conseguenza" a scegliere quello indiano, con vista sulla torre, che offre solo menù vegetariani. Il nutrirsi di vegetali è un vincolo secondario rispetto alla necessità di tenere d'occhio l'orologio. D'altra parte se avessi in tasca una mela avrei comunque risolto il problema. è secondaria l'importanza ma non esiste una correlazione stretta tra i due vincoli. Viceversa se il requisito fosse "è possibile nutrirsi solo allo scoccare dell'ora segnata dalla torre dell'orologio", questo secondo requisito sarebbe di tipo vincolare.
Come esiste la Work Breakdown Structure, esiste anche una scalabilità strutturale dei requisiti che impone di conseguenza una loro organizzazione gerarchica.
La definizione e il controllo dei requisiti è divenuto talmente specializzato che è nata di recente una disciplina, insegnata anche presso alcune università americane, chiamata "ingegneria dei requisiti". In un testo classico sull'argomento ("Requirements Engineering" - Hull, Jackson, Dick. Ed. Springer) si fa menzione del cosiddetto "modello a V":

Questo schema mostra come i requisiti vengano calati gerarchicamente verso i livelli di controllo di dettaglio e come i singolo livelli siano correlati ai relativi test di verifica. Anche per questo schema valgono le considerazioni sopra menzionate a proposito del principio di retroazione. è buona norma pertanto considerare la possibilità che modifiche ai requisiti di livello inferiore possano generare modifiche a quelli di livello superiore. In effetti però la struttura concettuale nella quale ci si muove è quella mostrata ed ha rilevanza anche a livello contrattuale. Poiché infatti ciò che si acquista non è qualcosa di compiutamente definito, le fasi contrattuali (milestones) seguono anche in termini di pagamenti le varie fasi del progetto. Lo schema va inoltre letto in termini di scala (scaling); le sottostrutture in cui si articola ciascun blocco seguono percorsi concettuali analoghi.
Per quanto attiene alla tracciabilità, ogni singolo requisito è identificato da un codice numerico specifico; i requisiti figli riportano anche il grado di "parentela" con quello immediatamente superiore; ad esempio:
- requisito padre #Req-SyS-001: Ogni unità avrà un interfaccia di input a 4 ingressi;
- requisito figlio #Req-SubSys-001; (Par. Req-Sys-001): Ogni interfaccia d'ingresso sarà del tipo RS422.
I documenti sui quali sono tracciati tali requisiti sono detti genericamente "Specifiche"; esistono pertanto "Specifiche di Sistema", "Specifiche di Sottosistema", ecc.
Tutti insieme essi sono i "Documenti Applicabili" sui quali è tracciata, a ogni livello di dettaglio, l'ossatura del progetto.
Da un punto di vista negoziale, c'è sempre una certa condivisione di scelte nella definizione dei requisiti; tale necessità deriva dal fatto che il committente da un lato non conosce a fondo i dettagli del progetto, dall'altro non può essere troppo vago nel generare i requisiti che indicherà nelle Specifiche di Progetto; questi ultimi sono i documenti con i quali, come ho indicato in precedenza, egli fornisce i requisiti fondamentali da soddisfare. (Rimane comunque il produttore l'unico responsabile sia del design sia della verifica completa). Per modellizzare correttamente il contesto è bene allora schematizzare le problematiche. Alcune di loro attengono al "Dominio del Problema": sono le fasi iniziali, in cui vengono valutate le caratteristiche di fattibilità e i trade-off.
A valle di queste fasi iniziali si entra nel "Dominio della soluzione", nel quale gli elementi del progetto sono dettagliati a un livello maggiore.
Il meccanismo dell'accordo può essere sintetizzato nel modo seguente:

Uno schema di massima della dinamica decisionale in questa fase può essere delineato così: dopo incontri preliminari, il committente definisce la seguente documentazione:
- uno Statement of Work (SOW) in cui chiarisce la terminologia contrattuale usata, i tempi richiesti nelle varie fasi, quali sono le Review da effettuare e cosa si aspetta da ciascuna di esse;
- un documento di specifica, che riguarda l'unità in oggetto, e che definisce i requisiti in termini di prestazione e di design;
- una serie di "Documenti Applicabili" che costituiscono il background completo del progetto di cui la singola unità fa parte, in termini di requisiti di compatibilità (ad esempio meccanici, termici, di qualità, elettromagnetici). L'unità insomma vista nel contesto del sistema di cui farà parte.
Il fornitore risponde attraverso la definizione di un SOC (Status of Compliance) ai requisiti generati. Tipicamente ciò avviene attraverso l'emissione di documenti specifici detti VDC (Verification Control Document) per i documenti applicabili e una DVM (Design Verification Matrix) per la specifica di unità. Si tratta solitamente di matrici in cui si risponde ad ogni singolo requisito con la dichiarazione di una "compliance" completa (C), "parzialmente completa"(PC), "non compliance" (NC) o "non applicabilicabilità" (NA). Ciascun requisito è così tracciato e discusso singolarmente e i vari casi costituiscono materia di discussione durante le Review di progetto pianificate.
Insisto con il sottolineare che quanto sopra indicato non è universalmente accettato nella forma sopra esposta, essendo le procedure decisionali stesse oggetto della trattativa (tanto è vero che sono dettagliate nel SOW). In ogni caso la corretta tracciabilità dei requisiti costituisce lo strumento di comunicazione privilegiato per questo tipo di negoziazioni.
L'uso è diventato così comune da essere persino stato oggetto di standardizzazioni, come si è già detto. Esitono addirittura dei prodotti software commerciali (CAD - Computer Aided Design) che permettono la gestione elettronica dei requisiti attraverso le varie fasi di progetto, con la generazione automatica della documentazione a corredo delle varie Review. Il più noto tra questi è il DOORS® della Telelogic.
In effetti, per il motivo della retroazione di cui si è già discusso, una delle componenti più difficili da gestire riguarda gli impatti dei cambi sui requisiti correlati. Il fornitore può richiedere dei cambi ai requisiti che possono ripercuotersi a catena in altri contesti, in termini sia ingegneristici sia economici. I singoli percorsi critici che possono delinearsi sono una delle componenti dell'analisi del Risk Management.
Tra gli anni '80 e '90 emersero nell'ambito dell'Information Technology una serie di metodologie dette "Object-Oriented" (O-O) per l'ottimizzazione degli schemi progettuali del software. Scrivere software è, di fatto, uno degli esercizi migliori per apprendere le tecniche di problem-solving da applicare ai più svariati contesti. Tali metodologie sono state poi trasportate nell'ingegneria dei requisiti.
Ognuno di questi metodi (l'OMT di Rumbaugh - 1991, il metodo di Booch -1994, l'Objectory di Jacobsen -1993) sono confluiti in quello che è allo stato attuale il metodo più usato: l'UML (Unified Modelling Language -2003). Attraverso lo sviluppo di diagrammi "strutturali", "comportamentali" e di "interazione", chi studia il progetto è in grado di modellizzarlo in maniera fine, senza tralasciare le dinamiche "interne" ed "esterne" che possono perturbarne la struttura nel corso del tempo.
L'iter procedurale da seguire dipende molto dalla categoria dell'unità che si intende acquisire.
Ogni disciplina ingegneristica definisce le proprie categorie; ad esempio in ambito aerospaziale esistono le seguenti:
- categoria A: unità già sviluppata per altri programmi e testata secondo criteri di severità pari o maggiori a quelli del programma per cui è acquisita;
- categoria B: unità già sviluppata per altri programmi ma che necessita di test di qualifica supplementari in base alle mutate esigenze del nuovo programma;
- categoria C: unità già sviluppata per altri programmi ma che necessita di qualche modifica di design, con conseguente qualifica aggiuntiva;
- categoria D: unità da sviluppare ex-novo.
Nei casi in cui il design fosse completamente nuovo, la verifica delle funzionalità e l'attività di qualifica possono avvenire attraverso lo sviluppo di modelli ingegneristici (EM, EQM) o prototipi vari, le cui risposte ai test permettono di verificare o le modifiche da introdurre nei requisiti o i cambi di design.
Chiariti il concetto di requisito e la categorizzazione del procurement, si può passare ad esaminare l'iter procedurale che guida il confronto tra il fornitore e il cliente.
Ogni azienda può specificare l'iter che preferisce. Questo aspetto riveste un'importanza contrattuale fondamentale da definire in partenza; per la stragrande maggioranza dei casi ciò avviene in quella che, dopo gli incontri preliminari, è la prima "milestone" di rilievo: il Kick Off.
Gli aspetti che vengono trattati nel meeting di Kick Off riguardano le grandi linee del progetto: il numero di review che verranno effettuate, la documentazione che verrà prodotta nelle varie fasi, i costi e le unità che verranno consegnate, le date (schedule).
Il cliente, dopo una fase di incontri preliminari, fornisce quello che è il documento di sintesi fondamentale di questa review: lo Statement of Work. Tale documento tiene traccia delle linee guida basilari del progetto, oltre a una definizione di dettaglio di ciò che ogni review futura dovrà prevedere e produrre. L'analisi dei rischi (Risk Management) è uno degli aspetti principali da considerare. Per ogni aspetto (Certificazioni di Qualità, standard aziendali, classe e categoria dei componenti utilizzati), vengono valutati i documenti applicabili di riferimento.
Sempre in questa fase preliminare il cliente fornisce un gruppo (Data Package) di "documenti applicabili" che sintetizzano le richieste in una forma di dettaglio maggiore attraverso il già menzionato strumento dei requisiti. Ci saranno "Specifica di Ingegneria", "Specifiche di qualità", "Specifiche di Sistema", ecc., a seconda del grado di articolazione del progetto.
Anche la tipologia del progetto influenza l'iter procedurale; se un'unità deve essere progettata ex-novo necessiterà di una fase di studio preliminare (fase 0 o di fattibilità); a questa farà seguito una "fase A" con lo scopo di consolidare i requisiti chiave; seguiranno via via le varie fasi utili alla realizzazione di dettaglio del design. La gestione di queste fasi preliminari presenta delle criticità che possono ripercuotersi in tutte quelle successive. In generale è comunque difficile stabilire un "linguaggio comune" per riassumere in forma chiara e concisa i termini degli accordi.
A livello internazionale, enti e agenzie (possibilmente riconosciute a livello governativo), definiscono una normativa di base per facilitare questo compito. Per fare un esempio, in Europa l'Agenzia Spaziale Europea (ESA): la normativa di base è contenuta negli standard ECSS (European Cooperation for Space Standardization); ogni aspetto o livello procedurale viene definito con indicazioni di massima sullo scopo e gli iter da seguire. Per le "fasi 0/A" menzionate, ad esempio, l'ECSS prescrive uno schema del tipo:

Il termine "SE" sta per System Engineering; lo schema è stato infatti tratto da ECSS-E-10 Part 1B, che riguarda l'ingegneria di sistema. Gli schemi vengono via via articolati sempre più, secondo uno schema "top/bottom"; ad esempio, per il Risk off:

Oppure, per meglio identificare anche l'attribuzione dei compiti, vengono riportate tabelle di dettaglio; la figura di sotto riporta l'estratto di una tabella concernente la fase A di un progetto.

Nella fase B vengono studiati trade-off e fattibilità.
è nelle review successive (C-D) che i requisiti vengono congelati e si parte con una descrizione tecnica di dettaglio. Una tipica review di questa fase può essere la PDR (Preliminary Design Review) per design in fase di definizione e la CDR (Critical Design Review) per "congelare" un design portato a compimento. Tutto ciò che seguirà riguarderà l'integrazione e i test di accettazione o qualifica. Il numero delle fasi o la loro caratterizzazione può variare a seconda del contesto o della complessità progettuale sottostante, così come varieranno anche la documentazione a corredo di ogni review e il livello dei requisiti. Componenti già usati in altri programmi e che hanno subito già un processo di qualifica (COTS, Commercial Off The Shelf) seguiranno degli iter ridotti, a meno di piccole variazioni nel design o di nuovi processi di qualifica.
Tra l'altro può capitare una diversa interpretazione delle fasi in funzione del livello di scala considerato (diverse cioè a livello di sistema,di sottosistema, di unità, di componente). Per fare un esempio, per definire una fase B di sistema può occorrere lo sviluppo di modelli preliminari (EM - Engineering Model), che costituiscono già la fase C/D a livello di sottosistema.
Per dare un esempio delle review tipiche:
- Kick-Off Meeting (KOM): in questa riunione viene definito il piano di lavoro per il fornitore relativamente alla fase iniziale del progetto. Vengono presi in considerazione lo stato di qualifica, il design, la storia passata dell'unità (heritage);
- Qualification Test/Status review (QSR): necessaria, come dice il nome, a confermare l'eventuale stato di qualifica dell'unità;
- Preliminary Design review (PDR): in questa fase contrattuale il design concettuale e il piano di sviluppo vengono analizzati. La verifica della comprensione dei requisiti, nonché della loro completezza è fondamentale per lo sviluppo delle fasi successive;
- Critical Design review (CDR): in questa fase il design definitivo di progetto viene congelato, assieme allo stato dei componenti dichiarati e alla lista dei materiali e dei processi. Senza l'approvazione, da parte del cliente, di questa review, lo sviluppo dell'unità non è autorizzato;
- Test Readiness review ( TRR): questa è una fase delicatissima. Il cliente prende visione del piano di test che verrà effettuato, tenendo conto dei controlli di qualità e performance, ma anche del fatto che l'unità non venga danneggiata qualora i livelli di test dichiarati fossero diversi da quelli concordati;
- Test review Board/Delivery review Board (TRB/DRB): tipicamente contestuali. Il produttore fornisce il data package completo a corredo dell'unità che verrà consegnata; in particolare i test report, con la sintesi dell'intera campagna di test, daranno evidenza delle performance richieste in accordo alle specifiche e al test plan.
Gli aspetti di spedizione contengono il controllo di aspetti riguardanti anche l'imballaggio e gli aspetti economici.
La reale complessità di queste fasi non emerge se ci si sofferma solo sugli aspetti ingegneristici del processo.
Ad esempio, il rispetto delle milestones e delle date fissate (schedule) è una capacità fondata sull'individuazione dei percorsi critici, sulla corretta valutazione delle risorse, sull'analisi dei rischi.
Valutare un progetto e ripartire la responsabilità tra le diverse aree di sviluppo è compito di più figure professionali. Gli esperti dell'ingegneria considerano gli aspetti tecnico/scientifici, gli esperti della qualità valutano l'applicazione degli standard, le categorie dei componenti e i flussi dei processi; gli addetti al program management valutano il rispetto dei tempi, dei costi e gli impatti commerciali. A un singolo responsabile del procurement, in genere scelto nell'ambito dell'Ingegneria, viene devoluto il compito di armonizzare i vari aspetti presiedendo le singole review; egli comunque si avvale di almeno due figure di riferimento, una per la qualità e una per il program management, per avallare decisioni e firmare documenti di review.
L'albero dei requisiti, le sue ramificazioni e le specificità degli aspetti che li riguardano stabiliscono poi le responsabilità "locali" sulle varie aree. Dal punto di vista dell'ingegneria, ad esempio, ci saranno responsabili degli aspetti termici, meccanici, di compatibilità elettromagnetica, di sistema ecc… Analogamente, per quanto attiene alla qualità, ci possono essere responsabili dei processi, dei componenti, dell'affidabilità.
Quanto esposto dovrebbe aver indicato, più che i confini, i piani concettuali nei quali si articola l'attività di procurement.