Approfondimento di Alfonso Pisani                                                                                           

Appalti Software e Quinto d’obbligo…il mondo pubblico e privato uno scenario interessante

Alfonso Pisani[i]

Il ciclo di procurement di lavori, servizi e forniture nella PA deve essere sempre improntato ad una corretta valutazione dei fabbisogni dell’ente possibilmente fin dalla fase di programmazione (programma biennale degli acquisti di beni e servizi e il programma triennale dei lavori pubblici ex art. 21 codice dei contratti pubblici d.lgs. 50/2016), in linea generale, e poi in dettaglio nei relativi capitolati d’appalto.

In ciò una PA non è molto differente da un’azienda privata nella quale in fase strategica vengono prodotti i cd Main Requirement Specification o Product Roadmap cioè documenti in cui per grandi linee vengono descritti i requisiti da implementare per determinati prodotti  in uno o più progetti e poi  i Detailed Requirement Specification, cioè documenti di requisiti di dettaglio da implementarsi in progetti ben definiti con delle deadline (tempi di consegna).

Si potrebbe creare una corrispondenza del genere a livello molto grossolano:

Non a caso nella moderna letteratura il RUP delle procedure di gara viene definito anche come “Project Manager” dell’appalto, cioè una figura analoga nel mondo delle PA a colui che prende in cura la fase 3 della tabella di cui sopra nel mondo aziendale. In alcune grosse realtà aziendali è anche prevista una figura denominata Technical Coordinator che per molti versi richiama quella del direttore dei lavori o del direttore dell’esecuzione.

Ciò che ci interessa in questa fase è capire come vengono gestiti i cambiamenti che inevitabilmente capitano durante l’esecuzione di un appalto in ambo i mondi.

Spesso, e soprattutto nei progetti che abbracciano un orizzonte temporale ampio difficilmente la fase esecutiva procede in maniera lineare e senza imprevisti, ciò in ossequio non solo alla cosiddetta legge di Murphy («Se qualcosa può andar male, lo farà.») che relaziona l’esecuzione di un progetto ad un accadimento negativo, ma anche all’insorgenza di nuovi requisiti che, in un modo o nell’altro non sono stati previsti in fase di definizione del progetto (e dei relativi capitolati di gara).

E’ da precisare che nella PA l’insorgenza di requisiti non previsti (ma prevedibili) in fase progettuale può essere causa di responsabilità del progettista esterno a norma dell’art. 106 comma 2 del codice dei contratti di cui si riporta stralcio:

“Qualora la necessità di modificare il contratto derivi da errori o da omissioni nel progetto esecutivo, che pregiudichino in tutto o in parte la realizzazione dell'opera o la sua utilizzazione, essa è consentita solo nei limiti quantitativi di cui al presente comma, ferma restando la responsabilità dei progettisti esterni”

Indipendentemente dalle responsabilità, vero e proprio spauracchio nel mondo pubblico (ma ci sono conseguenze naturalmente anche in quello aziendale), nel mondo aziendale ed in articolare dello sviluppo software la necessità di un cambiamento rispetto ai requisiti iniziali, qualunque sia la sua origine, è gestito tramite il meccanismo delle cosiddette “Change Request” ossia un processo in cui il cambiamento viene identificato, valutato economicamente ed in termini di tempistiche richieste e, in caso di approvazione da parte dei responsabili viene realizzato e tracciato.

Se un’azienda per implementare un cambiamento obbedisce unicamente a regole di budget e di deadline  progettuali e a strategie di mercato in una PA, di contro, interviene anche e soprattutto il vincolo normativo che impone il rispetto dei principi di economicità, efficacia, tempestività, correttezza, libera concorrenza, non discriminazione, trasparenza, proporzionalità. Il principio di economicità, cruciale nel mondo aziendale, nella PA può essere subordinato, nei limiti in cui è espressamente consentito dalle norme vigenti a esigenze sociali, nonché alla tutela della salute, dell’ambiente, del patrimonio culturale e alla promozione dello sviluppo sostenibile, anche dal punto di vista energetico (esigenze che per molti versi il legislatore impone anche alle aziende).

Nel nostro codice dei contratti, d.lgs. 50/2016, la parte relativa ai cambiamenti, e forse è bene non chiamarli sempre varianti in corso d’opera, è rinvenibile nella parte III al Titolo V e precisamente all’articolo 106 “Modifica di contratti durante il periodo di efficacia”.

In tale articolo sono specificate una serie di casistiche in base alle quali si possono modificare in fase di esecuzione ed entro certi limiti le condizioni contrattuali. In talune casistiche è necessaria una comunicazione all’Osservatorio Regionale dei contratti pubblici relativi a lavori, servizi e forniture di cui all’art. 213 del codice.

Il comma 12 dell’art. 106 sul quale ci soffermeremo riguarda il cd quinto d’obbligo

“12. La stazione appaltante, qualora in corso di esecuzione si renda necessario un aumento o una diminuzione delle prestazioni fino a concorrenza del quinto dell'importo del contratto, può imporre all'appaltatore l'esecuzione alle stesse condizioni previste nel contratto originario. In tal caso l'appaltatore non può far valere il diritto alla risoluzione del contratto.”

Una disamina interessante di tale istituto, di cui si consiglia la lettura, è rinvenibile al link:

https://www.iusinitinere.it/modifiche-contrattuali-in-aumento-o-diminuzione-attuali-profili-critici-posti-dallart-106-co-12-d-lgs-n-50-2016-16731

nel quale viene giustamente posto in rilievo come tale comma, differentemente rispetto alla normativa precedente, sia di portata molto più generale (e talvolta da interpretarsi con estrema cautela) e indipendente dagli altri commi dello stesso articolo: per esso non si prevede espressamente la comunicazione all’Osservatorio di cui sopra e viene sottolineato come nella disciplina attualmente vigente la medesima modifica in aumento o in diminuzione entro il quinto appare assumere autonoma rilevanza, non sembrando più rientrare nel concetto di variante in senso stretto.

Analizziamo adesso un caso specifico di appalto di servizi, generalmente in un orizzonte temporale medio-lungo come quello dei servizi di manutenzione software.

Anzitutto in tale tipologia di prestazioni una gestione oculata imporrebbe affidamenti di termini medio-lunghi (3-5 anni) tutte le volte in cui il cambi di un software imporrebbe cambiamenti pesanti ai processi delle PA ed agli attori coinvolti. Si pensi, ad esempio ad un software per la gestione documentale con le proprie regole di fascicolazione, scrivanie virtuali, smistamenti, gestione dei flussi per particolari tipologie di atti come determine e delibere oppure ad un software per la contabilità.

La minimizzazione degli impatti rende opportuno un orizzonte temporale adeguato, ma è anche e spesso causa dei cosiddetti “lock in”, cioè l’impossibilità da parte della PA di rendersi indipendente da un dato fornitore. Sugli appalti che riguardano il software e la gestione dello stesso molto è stato detto e sicuramente scriveremo ancora. Richiamiamo a tal proposito le linee guida ANAC nr. 8 “Ricorso a procedure negoziate senza previa pubblicazione di un bando nel caso di forniture e servizi ritenuti infungibili” che identificano proprio il software ed i servizi connessi come tipologia di affidamenti a lungo termine e a rischio lock in in particolare quando in esse si dice:

“Nel settore dell’ICT, come in molti altri settori strategici, la programmazione deve essere di lungo periodo e deve partire dalla corretta identificazione dei propri fabbisogni, verificando le soluzioni che possono essere offerte dal mercato e interagendo con le altre amministrazioni con cui è necessaria l’interoperabilità. Nella scelta delle possibili opzioni occorre privilegiare quelle che hanno una minore probabilità di legare l’acquirente al fornitore prescelto.

Nella valutazione commerciale delle scelte occorre considerare non solo i costi immediati

dell’acquisto, ma avere a riferimento l’intero ciclo di vita del prodotto, che include la manutenzione, l’aggiornamento, l’utilizzo e l’eventuale uscita, nel caso si renda necessario passare a un nuovo prodotto.”

Evidentemente gli appalti relativi ai servizi connessi al software (gestione, manutenzione, conduzione ecc.) sono quelli per i quali potrebbe essere maggiormente richiesto il cambiamento in fase di esecuzione. A titolo di esempio si pensi ai casi in cui due sistemi software di case diverse (es. contabilità e documentale) devono interloquire allo scopo di migliorare l’efficacia e l’efficienza dei processi di una PA.

In tutte le casistiche in cui simili eventualità non siano previste nei capitolati iniziali, potrebbe essere opportuno valutare l’applicabilità del quinto d’obbligo di cui al comma 12 dell’art. 106 del codice dei contratti.

Per fare ciò bisogna tener presente quanto segue:

Le “prestazioni” di cui parla il comma 12 possono variare in aumento o diminuzione, ciò significa che bisogna parlare di concetti omogenei, cioè di prestazioni dello stesso tipo; ad esempio la necessità di far interloquire due sistemi sopra descritta per migliorare l’efficacia e l’efficienza delle operazioni non può porsi come requisito realizzabile con un quinto d’obbligo se il capitolato iniziale parlava solo di manutenzione correttiva (pura correzione di malfunzionamenti sulla base delle funzioni fornite dal software all’atto dell’acquisizione) o di manutenzione adeguativa (casistica tipica di quanto il software deve aggiornarsi solo per riflettere vincoli normativi altrimenti non rispettabili dall’Ente).

Bisogna, per tale ragione, in fase di scrittura dei capitolati descrivere le prestazioni anche tenendo conto di simili eventualità, peraltro non realizzabili da diversi fornitori se un contratto di manutenzione per lo stesso software è appaltato ad uno differente, se si vuole evitare un nuovo affidamento diretto.

Giova anche ricordare che nel caso in cui la PA preveda espressamente nel capitolato il ricorso al quinto d’obbligo deve anche valutare lo stesso nel calcolo della base d’asta (art. 35 comma 4 codice dei contratti).

Nella determinazione dirigenziale o nell’atto in cui si decide di avvalersi del quinto d’obbligo risulta opportuno evidenziare cosa era richiesto dal capitolato e per quale ragione le prestazioni richieste sono dello stesso tipo di quelle previste dal capitolato stesso. In allegato un modello di determinazione.