La transizione digitale rappresenta un percorso che coinvolge al giorno d’oggi imprese di tutti i settori, e non a caso quelli informatici sono una delle tipologie di contratti più diffuse nei rapporti business to business, ovvero tra imprese (manifatturiere, di servizi, commerciali, etc.) e professionisti che offrono prodotti e servizi “informatici”. A tal proposito, basti pensare ai contratti aventi ad oggetto la personalizzazione di software, la realizzazione di siti internet o di portaliper la vendita e-commerce, la vendita di un software o di servizi erogati nella soluzione cloud computing e SAAS (Software as a service). La diffusione di tali contratti ha determinato (purtroppo) anche l’insorgere di un elevato numero di controversie di non facile gestione e risoluzione, con la conseguenza che le imprese si trovano (sempre più) spesso costrette ad abbandonare i progetti inizialmente condivisi (cercando di salvare il salvabile) ed eventualmente ad avventurarsi in lunghi e costosi contenziosi giudiziari dall’esito incerto. A quest’ultimo proposito, si consideri che (nella maggior parte dei casi) i relativi procedimenti giudiziari richiedono consulenze tecniche di ufficio (cd CTU), con la conseguenza che i tempi del processo si dilatano, così come aumentano i relativi costi, dovendo questi ultimi necessariamente comprendere anche quelli per tecnico incaricato dall’Autorità Giudiziaria e dei consulenti nominati dalle parti.
Il presente articolo, senza pretese di esaustività, descrive le caratteristiche dei contratti relativi alla fornitura di software, ne analizza alcune delle principali cause di controversie e fornisce alcuni accorgimenti utili da adottare in fase di negoziazione, al fine gestire in maniera più efficiente il rapporto e tentare di prevenire contenziosi. Ricordiamo che i contratti aventi ad oggetto la realizzazione / personalizzazione di un software sono quelli con cui un soggetto (generalmente denominato committente) affida ad un altro (detto professionista) il compito di identificare, realizzare e/o personalizzare software per la gestione di alcune fasi della propria attività (ad es., relazioni con i clienti, vendite, marketing, profilazione dei clienti, tracciamento delle varie attività svolte, e così via).
In tali occasioni spesso il professionista suggerisce l’utilizzo di un determinato format già reso disponibile sul mercato da parte di importanti case madri (V. per esempio Microsoft), provvedendo poi alla relativa personalizzazione in base alle esigenze dell’azienda committente ed occupandosi della cosiddetta migrazione dei dati dal precedente portale a quello di nuova realizzazione. A titolo di corrispettivo, quindi, al committente potrebbe essere richiesto il pagamento di un canone per le licenze, nonché di un corrispettivo per la per progettazione iniziale del lavoro, la personalizzazione del software e la formazione del personale. Già da questa sommaria definizione appare evidente quanto complesso per certi aspetti il contratto in oggetto possa presentarsi.
Le principali problematiche connesse a questa tipologia di contratto sono riconducibili (da una parte) alla mancanza di una fonte normativa chiara, organica ed esaustiva e (dall’altra) all’utilizzo di contratti NON sufficientemente dettagliati, o comunque mancanti di quella regolamentazione necessaria affinché le parti possano gestire efficacemente il rapporto. Ricordiamo, tra l’altro, che in questi contesti l’attività dei professionisti NON può prescindere da una più o meno marcata collaborazione fornita da parte del committente. Ecco quindi di seguito alcune delle possibili cause di problemi. Come anticipato, una prima difficoltà riguarda l’inquadramento giuridico di questi contratti. NON è prevista infatti né nel codice civile né in leggi speciali una disciplina specifica di questo contratto. Dal canto suo, la giurisprudenza identifica questi rapporti “nell’ambito della categoria dei contratti atipici, o alternativamente nell’ambito del contratto di appalto o di un contratto misto di compravendita e di prestazioni d’opera ovvero del contratto d’opera con prestazione di materia e garanzia del risultato”. La scelta tra le ipotesi identificate NON è di poco conto. Basti pensare che la normativa di detti contratti differisce (e non di poco) in termini per la denuncia di vizi e di garanzie che il professionista deve fornire. È quindi evidente che, in caso di controversie, sarà necessario individuare la disciplina normativa più funzionale, attività NON sempre è così agevole, per l’appunto.
(tipo di prestazione del professionista)
Un secondo ordine di problemi è dato dalla difficoltà nel qualificare le attività del soggetto professionista come obbligazioni di mezzi (ovvero obbligazioni valutabili sono in termini di diligenza adottata nello svolgimento delle attività) o di risultato (ovvero obbligazioni valutate in termini di risultato raggiunto). Anche in questo caso, la differenza NON è di poco conto, potendo determinare l’insorgere di controversie in punto al corretto adempimento. NON a caso spesso si assiste a controversie in cui (da un lato) la software house rivendica di aver svolto le attività in maniera corretta, facendo riferimento ad certo numero di ore lavorate, mentre (dall’altro lato) l’impresa committente eccepisce il mancato raggiungimento degli obiettivi programmati. Ebbene, sul punto la giurisprudenza è ormai concorde nel ritenere che, a prescindere dall’inquadramento giuridico del contratto,il fornitore del prodotto informatico assume nei confronti del committente un obbligo di risultato, “vincolandosi alla realizzazione di un software pienamente rispondente alle specifiche e funzionali richieste dal committente”. Ad ogni buon conto, tali principali andranno sempre trasposti nel caso specifico, sul quale ovviamente possono assumente una qualche rilevanza anche le pattuizioni eventualmente contrarie intervenute.
(Mancanza di analisi preliminari)
Un terzo ordine di problemi riguarda il non effettuare una attenta analisi iniziale dello state dell’arte, sulla base della quale strutturare il progetto. Ecco quindi che, dopo una consulenza iniziale, dopo l’acquisto delle licenze del software, nella fase di personalizzazione ci si rende conto che il progetto NON è realizzabile. Ciò, per esempio, capita quando risultano mancanti o errati i dati input da acquisire in fase di analisi preliminare (v. effettive necessità del cliente, tipi di dati da trattare, strumentazione hardware o software già a disposizione del committente, figure professionali presenti all’interno dell’azienda di quest’ultimo).
(Mancanza di un cronoprogramma di attività)
Ancora, una causa di problemi è rappresentata dalla mancanza di una previsione delle tempistiche del progetto. L’attività, come anticipato, è complessa e strutturata necessariamente in diverse fasi, tutte collegate funzionalmente tra esse. Le “patologie” di una di tali fasi potrebbe quindi ripercuotersi sulle altre o sul proseguo dell’intero progetto. Di qui nascono una serie di problematiche afferenti per esempio: l’individuazione di responsabilità di inadempimento per una specifica fase, ovvero l’importanza di tale fase rispetto all’intero progetto, la tollerabilità o meno di determinati ritardi, l’essenzialità o meno di alcuni termini previsti.
Al fine di rendere i rapporti aventi ad oggetto la fornitura di software più efficienti e tentare di contenere i rischi di contenzioso, si ritiene opportuno fornire alcune indicazioni relative soprattutto alla redazione del contratto tra le parti. Ricordiamo infatti che il contratto NON solo ha una funzione di tutela della posizione delle parti, ma dovrebbe avere anche quella di strumento organizzativo, contenente una serie di prescrizioni alle quali le parti si devono conformare al fine di corretto proseguo del lavoro. Invece, nella pratica, si utilizzano spesso formulari predisposti da una sola parte, NON negoziati, e contenenti disposizioni non specifiche in relazione alle parti ed alle relative necessità, e spesso anche invalide da un punto di vista legale.
Dunque, ecco alcune indicazioni:
Riccardo Avv. Valleri
