CLASSIFICAZIONE DEL DOCUMENTO: CONSIP PUBLIC
CLASSIFICAZIONE DEL DOCUMENTO: CONSIP PUBLIC
GARA A PROCEDURA APERTA PER LA CONCLUSIONE DI UN ACCORDO QUADRO, SUDDIVISO IN 7 LOTTI, CON PIÙ OPERATORI ECONOMICI AI SENSI DELL’ART. 54, COMMA 4 LETT. C), D. LGS. N. 50/2016 E DELL’ART. 2, COMMA 225, LEGGE N. 191/2009, AVENTE AD OGGETTO L’AFFIDAMENTO DEI SERVIZI APPLICATIVI IT PER LE PUBBLICHE AMMINISTRAZIONI. ID 1881
ALLEGATO 5 CAPITOLATO TECNICO
INDICE
2.1 Contesto applicativo e tecnologico della Pubblica Amministrazione Locale 6
2.2 Contesto applicativo e tecnologico della Pubblica Amministrazione Centrale 9
3 DEFINIZIONE DELLA FORNITURA 12
3.2 Obblighi di comunicazioni 13
3.3 Luogo di esecuzione dei servizi e spese di trasferta 13
4 DESCRIZIONE DELLA FORNITURA 15
4.1.1 Sviluppo, Manutenzione evolutiva, adeguativa e migliorativa di Software ad hoc 16
4.1.2 Personalizzazione e parametrizzazione di soluzioni commerciali o di software open source o di software in riuso 17
4.1.3 Servizi di Gestione del portafoglio applicativo 18
4.1.3.1 Gestione applicativi e basi dati 18
4.1.3.2 Gestione dei contenuti di Siti, Portali e canali Web 19
4.1.3.3 Servizio Manutenzione Xxxxxxxxxx 00
4.1.4 Servizi Tecnico-Specialistici 23
4.3.1 Servizio Assistenza in remoto 24
4.3.2 Formazione ed Addestramento 25
5 REQUISITI E COMPETENZE GENERALI PER L’EROGAZIONE DEI SERVIZI 27
5.1 Requisiti Minimi dei servizi realizzativi 27
5.1 Competenze Funzionali, metodologiche, applicative e tecnologiche 28
5.1. Competenze funzionali e tematiche 29
5.2. Competenze metodologiche 29
5.3. Competenze applicative 29
5.4. Competenze tecnologiche 30
6 METRICHE E DIMENSIONAMENTO DELLA FORNITURA 31
6.1 Risorse Professionali e Gruppi di lavoro 33
6.2 Misurazione dello sviluppo software in Punti Funzione 33
6.3 Misurazione dei servizi in giorni persona 34
6.3.1 Servizi di gestione del portafoglio applicativo 36
6.3.2 Servizi Tecnico - Specialistici 38
7 REQUISITI GENERALI PER TUTTI GLI APPALTI SPECIFICI 40
7.2 Attività Propedeutiche all’erogazione dei servizi 40
7.3 Requisiti Organizzativi 42
7.4 Requisiti di Qualità Della Fornitura 42
7.5 Orario di erogazione dei servizi 43
7.6 Luogo di erogazione dei servizi 44
7.7 Strumenti a supporto dell’operatività della fornitura 45
7.8 MODALITA’ DI EROGAZIONE 45
7.8.3 Accettazione/approvazione prodotti della fornitura 47
7.8.4 Verifiche di conformità 48
7.10 Flussi FEE e Flussi Informativi di Monitoraggio Forniture 49
7.11.2 Indici di prestazione 50
7.12 STRUMENTI A SUPPORTO IN FASE DI AS 50
1 PREMESSA
Il presente documento costituisce il capitolato tecnico dell’Accordo Quadro ex art. 54 comma 4 lettera c) del D. Lgs. 50 del 2016 e dell’art. 2 comma 225 della Legge 23 dicembre 2009 n. 191, avente ad oggetto l’affidamento di Servizi Applicativi IT, da erogarsi attraverso Appalti Specifici che le Amministrazioni potranno indire nel periodo di vigenza del presente Accordo quadro.
Il documento è unico per tutti i lotti e fornisce la descrizione dei servizi ed i requisiti minimi imprescindibili. Costituisce, pertanto, il framework di riferimento sul quale le Amministrazioni definiscono il proprio contesto tecnologico ed applicativo e compongono le proprie esigenze di servizi applicativi.
Sinteticamente, per servizi applicativi si intendono:
- i servizi realizzativi di software e di gestione del portafoglio applicativo ovvero la realizzazione di nuove applicazioni e/o funzioni, modifica, personalizzazione, parametrizzazione e il mantenimento e la correzione del software di proprietà od in uso dell’Amministrazione, il monitoraggio e l’assistenza sulle applicazioni/sistemi/siti e relative basi dati, interfacce, file, siti, ec.., l’assistenza tecnica e funzionale all’utenza ed all’Amministrazione, la verifica della corretta esecuzione delle procedure, la disponibilità dei sistemi, il monitoraggio della sicurezza applicativa, del corretto aggiornamento dei siti e dei database, e tutte le attività necessarie alla corretta esecuzione delle procedure e dei programmi ivi incluse attività di analisi qualitativa del software sia statica sia dinamica;
- i servizi tecnico-specialistici ICT: forniscono risorse con competenze tecniche specifiche di alto livello sulle tecnologie, pacchetti, infrastrutture, metodologie, ec.. al fine di predisporre relazioni tecniche, studi di fattibilità, documenti di architettura, analisi comparata di soluzioni/pacchetti/tecnologie/strumenti, analisi d’impatto in caso di upgrade, modifica, cancellazione di soluzioni applicative e tecnologiche esistenti; analisi make or buy di sistemi/applicazioni sw, studio di fattibilità anche in ambito di portabilità delle applicazioni in Cloud. Possono inoltre svolgere task di natura sistemistica e analisi preventive di compatibilità di sistemi ed assistenza specialistica per la risoluzione di problematiche di alto livello.
I servizi applicativi possono essere affiancati da servizi di supporto finalizzati alla definizione e ridisegno/re- ingegnerizzazione dei Processi, Demand Management, supporto tematico scientifico e metodologico: le Amministrazioni possono dover potenziare le proprie risorse interne attivando task propedeutici e preliminari all’avvio di progetti informatici e/o nella gestione del proprio portafoglio applicativo attraverso task di analisi organizzativa e/o revisione dei processi e/o Demand management. Inoltre alcune attività tipicamente applicative possono richiedere esperti di tematica (es. esperti di comunicazione per i servizi di publishing, esperti di modelli econometrici e/o consulenti scientifici per tematiche verticali connesse ai processi amministrativi).
Queste attività per la loro natura propedeutica e/o complementare all’attivazione dei servizi applicativi non possono essere richiesti autonomamente dai servizi applicativi (siano essi realizzativi e/o di gestione) e non possono superare il 20% dei servizi applicativi.
Le amministrazioni potranno prevedere ulteriori attività connesse ai predetti servizi, introducendo i servizi accessori ovvero i servizi di natura informatica che l’Amministrazione definirà nella documentazione di AS per completare il proprio oggetto della fornitura: tali servizi non potranno superare il 20% della base d’asta totale e dovranno essere definiti in termini di requisiti, specifiche, modalità di erogazione, di misurazione, di valutazione e remunerazione nonché l’Amministrazione dovrà definire la quantità e le tariffe unitarie a base d’asta.
Sono parti integranti del capitolato le seguenti appendici:
• Appendice 1 Profili Professionali: contenente i requisiti professionali minimi delle risorse da impiegare nell’erogazione dei servizi;
• Appendice 2 Indicatori di qualità: contenente i principali indicatori di qualità.
La fornitura è suddivisa in 7 lotti
1. Lotto 1 Contratti Grandi – Nord (Piemonte, Valle d’Aosta, Liguria, Xxxxxx Xxxxxxx, Lombardia, Trentino Alto Adige, Veneto, Friuli Venezia Giulia);
2. Lotto 2 Contratti Grandi – Centro Sud (Toscana, Marche, Umbria, Molise, Lazio, Sardegna, Abruzzo, Puglia, Campania, Basilicata, Calabria, Sicilia);
3. Lotto 3 Contratti Piccoli Medi – Nord1 (Piemonte, Valle d’Aosta, Liguria, Xxxxxx Xxxxxxx);
4. Lotto 4 Contratti Piccoli Medi – Nord2 (Lombardia, Trentino Alto Adige, Veneto, Friuli Venezia Giulia);
5. Lotto 5 Contratti Piccoli Medi – Centro1 (Toscana, Marche, Umbria);
6. Lotto 6 Contratti Piccoli Medi – Centro2 (Lazio, Sardegna, Abruzzo, Molise);
7. Lotto 7 Contratti Piccoli Medi – Sud (Puglia, Campania, Basilicata, Calabria, Sicilia).
Al termine della I fase con gli aggiudicatari della procedura aperta verrà concluso un AQ per ciascun lotto. Successivamente le Amministrazioni aggiudicatrici riaprono il confronto competitivo (II fase) come previsto dall’art. 54 comma 5 del D.Lgs, 50/2016, procedendo:
• alla definizione dell’oggetto del singolo AS (selezione dei servizi necessari e contestualizzazione , delle relative quantità, dello specifico contesto applicativo e tecnologico, di eventuali specifiche modalità di erogazione, di standard/linee guida/best practice applicabili alla fornitura, strumenti/sistemi interni da utilizzare, ecc… ), alla definizione della relativa base d’asta, dei criteri di aggiudicazione, delle condizioni contrattuali di AS;
• la combinazione dell’importo della base d’asta o dell’importo complessivo e della sede dell’Amministrazione determina il Lotto di riferimento;
• all’invio della Richiesta di offerta agli aggiudicatari dell’AQ relativo al Lotto di riferimento, nel rispetto dei termini e delle condizioni previsti nell’AQ;
• all’analisi e alla valutazione delle offerte, in ragione del criterio di aggiudicazione e dei criteri di valutazione stabiliti dall’Amministrazione medesima nella Richiesta di offerta, secondo quanto stabilito nell’AQ;
• all’aggiudicazione dell’AS ed alla stipula del relativo contratto di fornitura in favore dell’Impresa che avrà presentato la migliore offerta e che, pertanto, risulterà essere l’aggiudicatario del confronto competitivo tra i Fornitori parti dell’AQ.
La presente procedura si svolgerà, ove non diversamente espressamente previsto, attraverso l’utilizzo di un sistema telematico come dettagliatamente descritto nel capitolato d’oneri.
1.1 Definizioni
Nel corpo del presente capitolato tecnico, si intende con il termine:
• “AQ”: l’Accordo Quadro;
• “AS”: l’Appalto Specifico basato sull’AQ;
• “Fornitore/i AQ”: l’Impresa/le Imprese Fornitrice/i aggiudicatarie dell’Accordo Quadro per il singolo Lotto;
• “Fornitore AS” o genericamente Fornitore: l’Impresa Fornitrice aggiudicataria dell’Appalto Specifico;
• “Amministrazioni/Enti” ciascuna singola Amministrazione appaltante, ovvero l’Amministrazione che utilizza l’AQ, predisponendo la richiesta d’offerta e aggiudicando il singolo AS;
• “Fornitura”: il complesso dei servizi oggetto della presente iniziativa- declinati nelle attività specificate dall’Amministrazione -che vengono richiesti in AS;
• “Software ad hoc”: l’insieme degli elementi software integrati, con relativi dati e documentazione sia tecnica sia utente realizzati specificatamente per l’Amministrazione che ne acquisisce la proprietà. E’ ricompreso in tale definizione anche il codice di test automatizzato;
• “Applicazione”: una qualsiasi realizzazione software tesa a fornire all’Amministrazione un insieme di funzionalità strettamente collegate. Solitamente un’applicazione è composta da uno o più moduli software e da un database a cui l’applicazione fa riferimento;
• “Obiettivo”: unità organica di lavoro, affidabile al fornitore, in cui si scompongono i servizi erogati in modalità progettuale. Dal punto di vista del Fornitore l’obiettivo è assimilabile a un “progetto”, la cui esecuzione è suddivisa nelle fasi indicate dal ciclo di vita applicato che richiedono la realizzazione di specifici prodotti.
• “Baseline del sistema”: versione formalmente approvata degli elementi della configurazione del sistema, indipendentemente dal supporto di registrazione, formalmente descritta e fissata in un momento specifico del ciclo di vita del sistema.
• “Richiesta di offerta”: l’atto di avvio della procedura di confronto competitivo che verrà inviato dall’Amministrazione ai Fornitori, per il rilancio del confronto competitivo per l’aggiudicazione di un Appalto Specifico.
2 CONTESTO DI RIFERIMENTO
Nel corso degli ultimi anni la Pubblica Amministrazione ha avviato un complesso percorso di rinnovamento e di innovazione basato sul ricorso alla tecnologia come fattore abilitante per adempire la propria missione istituzionale e per erogare servizi a cittadini ed imprese, in maniera più efficace ed efficiente, anche in considerazione della riduzione delle risorse disponibili e pertanto della spesa in ambito ICT.
Tale percorso è stato attuato anche grazie al Codice dell’Amministrazione Digitale (di seguito anche CAD), in cui, in particolare al Capo I - Principi generali, Sezione III, art. 15, comma I, viene specificato che la riorganizzazione strutturale e gestionale delle Amministrazioni Pubbliche avviene anche attraverso il migliore e più esteso utilizzo delle tecnologie dell'informazione e della comunicazione, nell'ambito di una coordinata strategia che garantisca il coerente sviluppo del processo di digitalizzazione. In quest’ottica la PA, anche in coerenza con l’Agenda Digitale Europea, ricorre all’informatizzazione dei processi e delle tecnologie telematiche: le Amministrazioni investono per rendere disponibili, internamente e verso l’esterno, nuovi servizi fruibili on-line in sostituzione o in aggiunta a quelli più tradizionali. Emerge pertanto chiaramente come la tecnologia, intesa come strumento, costituisca la leva fondamentale per proseguire il cammino già avviato.
2.1 Contesto applicativo e tecnologico della Pubblica Amministrazione Locale
Nel corso degli ultimi anni la PAL in generale ha avviato progettuali di “switch off” digitale e realizzato numerose iniziative volte a implementare progetti di informatizzazione dei servizi e delle funzioni, orientando maggiormente i servizi offerti agli utenti finali, ossia cittadini ed imprese. Un esempio concreto sono le iniziative progettuali di seguito riportate, a titolo indicativo e non esaustivo, che vari Enti Locali stanno conducendo o hanno intenzione di avviare:
• organizzazione dei servizi in ottica digitale, “senza carta”, superando quindi la logica dei procedimenti a favore di quella centrata sui servizi multicanale;
• innalzamento del livello delle competenze digitali, per offrire servizi on-line accessibili;
• impiego delle tecnologie dell’informazione e comunicazione in modo innovativo, per rispondere alle sfide emergenti in campo ambientale, sociale, sanitario, della mobilità, smart cities, ecc.;
• interoperabilità e cooperazione tra i sistemi informativi dei vari Enti, puntando sulla circolarità del “dato” come elemento essenziale del cambiamento, dalle modalità della sua raccolta, registrazione, conservazione, sino al suo utilizzo, interscambio e riuso;
• transizione dei servizi pubblici, come quelli privati, verso il digitale attraverso il miglioramento del livello di affidabilità e sicurezza delle reti e allargamento a tutti i cittadini ed imprese della connettività (banda larga e ultra larga);
• ulteriori progetti nell’ambito dell’Agenda digitale nazionale, con un coordinamento all’interno della Conferenza delle Regioni e delle Province autonome.
Il contesto della PAL si caratterizza per un elevato grado di eterogeneità sia dal punto vista della tipologia di
Amministrazione, e pertanto dei servizi applicativi da realizzare o innovare, che dal punto di vista normativo, dal punto di vista tematico, funzionale ed organizzativo ed infine dal punto di vista geografico, con differenze di digitalizzazione tra gli Enti appartenenti alle aree territoriali del Nord, del Centro e del Sud del Paese.
Inoltre, ulteriori differenziazioni sono presenti all’interno della PAL tra le iniziative tecnologiche realizzate o in corso e tra gli ambiti funzionali ed il contesto applicativo esistente.
In considerazione dello scenario sopra indicato, i fornitori aggiudicatari dell’AQ dovranno garantire la capacità di operare presso Amministrazioni caratterizzate da varietà di casistiche e numerose differenze, dipendenti peraltro anche da:
• funzioni e servizi applicativi da realizzare/modificare;
• dimensioni ed assetti organizzativi e distribuzione delle responsabilità;
• capacità e propensione delle Amministrazioni all’innovazione;
• limitate risorse economiche disponibili per la digitalizzazione;
• differente ambito di copertura funzionale ed informatizzazione dei processi;
• grado di maturità delle soluzioni implementate;
• livello di parametrizzazione e personalizzazione delle soluzioni;
• grado di interoperabilità con altre soluzioni applicative;
• eterogeneità della cultura organizzativa in ambito IT.
Gli aggiudicatari di ciascun AQ, dunque, dovranno disporre di risorse adeguate per gestire l’eterogeneità organizzativa, tecnologica ed applicativa, garantendo disponibilità di competenze IT, flessibilità nella struttura organizzativa e di approccio per rispondere ad esigenze potenzialmente molto diversificate.
Dal punto di vista dell’assetto organizzativo e di responsabilità di gestione in merito all’IT, nelle Amministrazioni
della PAL emergono sostanziali differenze nell’organizzazione delle funzioni dedicate all’ICT tra enti più piccoli e realtà grandi e complesse.
Sintetizzando, si riconoscono principalmente le seguenti modalità:
- Enti in larga misura autonomi sia in termini di “governance” che di esecuzione di programmi e progetti, nonché nell’esercizio di infrastrutture tecnologiche e applicative (tutte le Regioni e la maggior parte delle Province e Province Autonome (86,9%) dichiarano di disporre nella propria struttura di uno o più uffici autonomi di informatica; solo il 15,5% dei Comuni dispone di strutture dedicate);
- Associazioni di Amministrazioni istituiscono un ufficio di informatica in gestione associata al fine di condividere le competenze ICT: ciò avviene soprattutto nei Comuni delle Regioni del Nort-est (in particolare quelli dell’Xxxxxx-Romagna, della Provincia Autonoma di Bolzano e del Friulli-Venezia Giulia) e nelle Comunità montane;
- in altri casi, per lo svolgimento delle loro funzioni in ambito IT, le Amministrazioni Locali si avvalgono di società in-house, per lo più interamente possedute o costituite in consorzi, alle quali sono demandate le attività di progettazione, sviluppo, gestione e manutenzione dei sistemi informativi dell’Ente, sia in termini di parco applicativo e dotazione infrastrutturale, mantenendo generalmente all’interno dell’Ente un presidio di alto livello dell’intero servizio, per le attività di governo e pianificazione e gestione delle esigenze.
A titolo di esempio, le Amministrazioni Locali più grandi risultano dotate di un ufficio dedicato alle tecnologie dell’informazione ed alla digitalizzazione, in particolare tutte le Regioni, e l’85,5% dei comuni con più di 60.000 abitanti; il dato scende proporzionalmente con la diminuzione delle dimensioni degli Enti, mediamente circa 5 comuni su 100 con popolazione sino a 5.000 abitanti sono dotati di una struttura organizzativa dedicata all’ICT1. Relativamente alle società in-house, a titolo di esempio indicativo e non esaustivo, si citano a livello regionale:
• Lombardia Informatica, la società di servizi ICT della Lombardia che svolge un ruolo di collegamento tra la domanda della PA, le imprese ed i cittadini e svolge un ruolo strategico nella digitalizzazione della PA lombarda;
• CSI-Piemonte, l'ente strumentale della Pubblica Amministrazione regionale in campo informatico e telematico;
• Liguria Digitale, che fornisce servizi e soluzioni per la Regione ed il sistema regionale;
• Informatica Trentina, opera presso la Provincia autonoma di Trento per fornire soluzioni in ambito IT;
• LAit, che si occupa della realizzazione e della gestione del sistema informativo della Regione Lazio;
• Sardegna IT, società della Regione Autonoma della Sardegna a supporto della realizzazione del Sistema Informativo Regionale;
• InnovaPuglia, società della Regione Puglia impegnata in attività a supporto della programmazione strategica regionale a sostegno della innovazione digitale.
1 “Le tecnologie dell’informazione e della comunicazione nella PAL”, anno 2015, ISTAT.
Le iniziative IT nella PA locale sono principalmente finalizzate alla riduzione dei costi della PA e la semplificazione dei processi. Infatti, aumentano i servizi offerti dalle amministrazioni locali tramite il web.
Si registra un sensibile miglioramento della percentuale di enti che offrono la possibilità di avviare e concludere online l’intero iter del servizio richiesto: che passa dal 19,1% del 2012 al 33,8% del 2015. I comuni di maggiore dimensione sono più virtuosi (63,1%) delle Regioni e delle Province Autonome (59,1%).
I servizi più offerti via web – al livello massimo di disponibilità on-line – sono quelli connessi allo Sportello Unico per le Attività Produttive (24%) e la Dichiarazione di inizio attività produttiva (14%). Una percentuale significativa di Comuni sopra i 60mila abitanti, delle Regioni e Province Autonome utilizzano strumenti alternativi al sito web quali app e social media.
Sono sempre più informatizzate (in oltre 7 enti su 10) alcune attività correnti quali la gestione di contabilità, pagamenti, tributi, protocollo e, per i soli Comuni, anagrafiche. Dalla rilevazione del 2015 risulta ancora carente l’informatizzazione delle relazioni con il pubblico, la gestione dei concorsi e delle gare di appalto.
Pertanto in coerenza con la differenziazione sopra descritta, il fornitore è chiamato ad interloquire in alcuni casi direttamente con le Amministrazioni Locali e/o con le relative società in-house, tenendo conto delle normative di riferimento, dei vincoli nonché delle opportunità indotte dagli assetti organizzativi vigenti. Saranno altresì da considerarsi le caratteristiche peculiari dell’assetto organizzativo di ciascun Ente Locale, caratterizzato in alcuni casi dalla presenza di Strutture e/o Funzioni con totale o parziale autonomia organizzativa e di responsabilità in ambito ICT.
Non ultimo, si dovrà tenere in considerazione dei principi costituzionali, che regolano l’Ordinamento della Repubblica al Titolo V, ed in particolare all’autonomia attribuita ad alcuni Enti Locali, come a titolo di esempio le Regioni a statuto speciale e le Province Autonome.
La complessità organizzativa e tecnologica di tutte le Amministrazioni Locali dovrà pertanto essere adeguatamente considerata nell’elaborare la risposta di Offerta Tecnica.
2.2 Contesto applicativo e tecnologico della Pubblica Amministrazione Centrale
Da un punto di vista territoriale la PAC si concentra prevalentemente a Roma e dunque è ricompresa nel Lotto 2- Contratti Grandi e Lotto 6- Contratti –Medi-Piccoli.
Dal punto di vista dell’assetto organizzativo e di responsabilità in merito all’ICT, le Amministrazioni della PAC risultano autonome sia in termini di governo che di esecuzione dei programmi e dei progetti, nonché nell’esercizio delle infrastrutture tecnologiche e applicative.
Fanno eccezione in qualche misura:
• Il Ministero dell’Economia e delle Finanze e le Agenzie Fiscali che, attraverso la società “in-house” Sogei, condividono con tale entità esterna all’Amministrazione le responsabilità e le deleghe operative relative all’informatica, secondo regole e procedure a norma di legge;
• Il Ministero infrastrutture e trasporti (MIT), seppur nell’ambito più circoscritto relativo alla piattaforma logistica nazionale, con Uirnet;
• Il Ministero delle politiche agricole, alimentari e forestali (MIPAAF) con la SIN;
• L’ICE Agenzia con Retitalia;
• Unioncamere e il mondo camerale in generale con InfoCamere e DigiCamere.
L’interlocuzione con tali Amministrazioni e le relative società in-house, all’interno dell’Accordo Quadro, dovrà quindi tener conto delle normative di riferimento, nonché dei vincoli e delle opportunità derivate dalle disposizioni vigenti.
Dovranno essere considerate inoltre le caratteristiche peculiari dell’assetto organizzativo di ciascun Ministero, caratterizzato sovente dalla presenza di numerosi Dipartimenti con diversa autonomia organizzativa e responsabilità in ambito informatico.
All’interno del perimetro della PAC, oltre ai Ministeri, sono incluse ulteriori Amministrazioni, eterogenee per dimensione e struttura tra cui gli Enti di regolazione dell'attività economica, gli Enti produttori di servizi economici e le Autorità amministrative indipendenti. Sono ricompresi pertanto organismi di grande dimensione e diffusione capillare sul territorio nazionale e internazionale, e di contro entità di ridotte dimensioni ma con elevata specializzazione su temi strategici (es. Autorità).
Particolare attenzione andrà rivolta anche agli Enti nazionali di previdenza e assistenza sociale, in quanto erogatori di un gran numero di servizi essenziali a tutta la popolazione nazionale. Tali Enti sono da anni promotori di vasti programmi di trasformazione digitale al servizio del cittadino, e sono considerati attori chiave per la realizzazione di molti obiettivi di diffusione della fruizione digitale dei servizi da parte della popolazione nazionale.
Tra gli enti centrali si cita in particolare l’Agenzia per l’Italia Digitale (di seguito AGID), responsabile dell’attuazione delle strategie di digitalizzazione del Paese e di numerose iniziative di innovazione digitale.
La complessità organizzativa e tecnologica di tutte le Amministrazioni dovrà pertanto essere adeguatamente considerata nell’elaborare la risposta di Offerta Tecnica e la risposta all’Offerta Economica, tenendo nella dovuta considerazione il meccanismo bifasico dell’Accordo Quadro e che la puntuale progettualità e la definizione degli ambienti tecnologici ed applicativi sarà definita in Appalto Specifico.
La dotazione informatica, e in particolare applicativa, in esercizio presso le Amministrazioni Centrali si caratterizza per una presenza molto significativa di sistemi ad hoc realizzati sulle più diverse tecnologie a supporto dell’azione amministrativa propria di ciascun ente.
Un’indicazione seppur parziale rispetto alla eterogeneità e al grado di articolazione delle soluzioni adottate dalla PAC, può essere estrapolata dal “Catalogo delle basi di dati della Pubblica Amministrazione”, strumento realizzato
da AGID in ottemperanza dell’art. 24-quater, comma 2, del D.L. n. 90/2014, convertito in Legge 11 agosto 2014, n.
114. Il Catalogo è consultabile sul sito internet dell’AGID. Al netto delle attività correnti di aggiornamento e normalizzazione dei dati contenuti nel Catalogo, a mero titolo esemplificativo estraendo le basi dati per la categoria PCM, Ministeri e Avvocatura dello Stato si ottengono 1859 basi dati.
In questo contesto frammentato ed eterogeneo, si evidenziano alcune iniziative di standardizzazione trasversale, in corso di evoluzione e diffusione tra le Amministrazioni, con previsione di ulteriore integrazione tra i sistemi informativi della PAC. Se ne riporta di seguito un elenco indicativo e non esaustivo di:
• NoiPA: è il sistema realizzato dal Dipartimento dell’Amministrazione Generale del Ministero dell'Economia e delle Finanze, per gestire il trattamento economico del personale centrale e periferico della Pubblica Amministrazione. Con un approccio che risponde alle esigenze delle Amministrazioni “clienti” e assicurando l’aggiornamento in base all’evoluzione normativa per tutti gli aspetti previdenziali, fiscali e contrattuali, il sistema eroga un servizio unificato di elaborazione e gestione del cedolino, di gestione delle competenze fisse ed continuative, di gestione delle competenze accessorie, di trattamento delle presenze e assenze ed infine di aggiornamento dei dati variabili individuali;
• XX.XX.XX.: è il sistema informativo per la gestione integrata della contabilità economica e finanziaria che
consente alle Amministrazioni di effettuare sia le registrazioni di carattere economico-patrimoniale-analitico sia quelle di tipo finanziario. Il sistema è stato realizzato dalla Ragioneria Generale dello Stato del Ministero dell’Economia e Finanze e consente in particolare di: supportare il processo di formazione e gestione del bilancio finanziario, gestire tutte le fasi in ci si articola il processo di spesa sia da parte degli ordinatori primari che da parte degli ordinatori secondari (Funzionari Delegati), alimentare in modo omogeneo, attendibile e tempestivo le scritture di contabilità economica analitica per centri di costo delle Amministrazioni centrali dello Stato ed infine fornire dati per il controllo di gestione;
• Pago@PA: è il sistema dei Pagamenti elettronici a favore delle PA e dei gestori dei servizi di pubblica utilità che
nasce per dare la possibilità a cittadini e imprese di effettuare qualsiasi pagamento verso le Pubbliche Amministrazioni e i gestori di servizi di pubblica utilità in modalità elettronica. Il sistema permette a cittadini e imprese di scegliere liberamente il prestatore di servizi di pagamento (es. banca, istituto di pagamento/di moneta elettronica), scegliere tra più strumenti di pagamento (es. addebito in conto corrente, carta di credito, bollettino postale elettronico), scegliere il canale tecnologico di pagamento preferito per effettuare l'operazione (es. conto Web, ATM, mobile), conoscere preventivamente i costi massimi dell'operazione da effettuare e contemporaneamente avere garanzia della correttezza dell'importo da pagare, ottenere una ricevuta con valore liberatorio. Il sistema permette alle P.A. di velocizzare la riscossione degli incassi, ottenendone l'esito in tempo reale e potendo effettuare la relativa riconciliazione, ridurre i costi e ottimizzare i tempi di sviluppo delle nuove applicazioni online, grazie anche all'utilizzo di soluzioni ed esperienze riusabili, eliminare la necessità di stipulare specifici accordi con i prestatori di servizi di riscossione;
• FatturaPA: sulla base di quanto stabilito dalla Legge Finanziaria 2008 e reso operativo dal D.M. 55 del 2013, è
stata introdotta la fattura elettronica obbligatoria nei rapporti economici tra Pubblica Amministrazione ed i fornitori, con l’obiettivo di semplificare le procedure amministrative in un’ottica di trasparenza, monitoraggio e rendicontazione della spesa pubblica. È stato pertanto realizzato il progetto FatturaPA, con il quale la trasmissione delle fatture elettroniche destinate alle Amministrazioni dello stato avviene attraverso il Sistema di Interscambio, realizzato da Sogei e gestito dall’Agenzia delle Entrate, che funge da “snodo” tra gli attori interessati dall’intero processo.
Gli aggiudicatari, in fase di esecuzione contrattuale degli Appalti specifici, dovranno tenere conto della presenza e della diffusione delle iniziative progettuali trasversali sopra citate e delle linee di intervento all’interno del Modello strategico di evoluzione del Sistema Informatico della Pubblica Amministrazione tra cui lo sviluppo di ecosistemi di settore basati su servizi applicativi verticali, definendo ed implementando nuove soluzioni tecnologiche in una logica di compatibilità e, se possibile, di riuso, al fine di assicurare l’interoperabilità e la cooperazione applicativa.
Al di fuori della categoria dei Ministeri in cui prevalgono grandi sistemi applicativi proprietari e stratificati nel tempo, si registra una presenza più diffusa di soluzioni di mercato, adottate da diverse tipologie di Amministrazione. Tale presenza è caratterizzata da elevata disomogeneità in termini di copertura funzionale, grado di diffusione presso gli utenti, e livello di integrazione applicativa tra i moduli.
Ulteriore elemento di eterogeneità è rappresentato dai differenti livelli di personalizzazione e parametrizzazione delle soluzioni applicative implementate, generalmente dipendente da:
• aderenza delle soluzioni adottate ai processi gestionali e di supporto delle specifiche Amministrazioni;
• efficacia delle azioni di reingegnerizzazione ed efficientamento dei processi e dei sistemi.
Inoltre il fornitore dovrà porre particolare rilevanza alle Linee guida e regole tecniche emesse dall’AGID in merito alla Gestione dei Procedimenti Amministrativi, in cui sono stati definiti: il modello di riferimento, l’architettura tecnologica ed i requisiti funzionali e non funzionali dei Sistemi di Gestione dei Procedimenti Amministrativi della Pubblica Amministrazione.
Infine il fornitore dovrà operare tenendo conto di quanto previsto dal Codice dell’Amministrazione Digitale in relazione alla pratica del riuso del software, in un’ottica di razionalizzazione della spesa pubblica. In particolare, il riuso rappresenta la possibilità per una P.A. di riutilizzare gratuitamente programmi informatici, o parti di essi, sviluppati per conto e a spese di un’altra Amministrazione, adattandoli alle proprie esigenze.
Il contesto applicativo-tecnologico in uso presso la singola Amministrazione e gli obiettivi di digitalizzazione che si intendono raggiungere saranno rappresentato dettagliatamente nella documentazione di Richiesta d’offerta al fine di permettere agli aggiudicatari di AQ la predisposizione di un’Offerta Tecnica ed Economica di AS mirata e contestualizzando, declinando gli impegni trasversali assunti in I fase.
3 DEFINIZIONE DELLA FORNITURA
Il presente Accordo Quadro prevede i seguenti servizi:
1) servizi applicativi IT che rappresentano l’oggetto primario della fornitura, comprendono i macro ambiti dei:
a. servizi realizzativi di software ovvero sviluppo, manutenzione evolutiva, adeguativa, personalizzazione e parametrizzazione di software, manutenzione correttiva, dunque tutti i servizi che modificano la baseline del software e/o le funzionalità applicative;
b. servizi di gestione del portafoglio applicativo
c. servizi tecnico-specialistici ICT;
2) servizi di supporto ovvero servizi propedeutici o preliminari od integrativi ad uno o più attività richieste all’interno dei servizi applicativi quali: supporto al Ridisegno dei Processi, BPR e Demand Management, supporto tematico scientifico e metodologico; nella presente iniziativa i servizi di supporto, per il ruolo subordinato rispetto ai servizi applicativi, non possono superare il 20% dei servizi applicativi;
3) servizi accessori ovvero servizi collegati ai servizi applicativi IT di cui al punto 1 funzionali al completamento delle esigenze ICT dell’Amministrazione con puntuale riferimento ai sistemi applicativi su cui sono richiesti i servizi oggetto dell’AQ. In nessun caso i servizi accessori possono integrare o modificare i servizi applicativi di cui al punto 1 né le relative offerte di I fase. L’Amministrazione potrà definire in AS servizi ICT del tutto nuovi rispetto all’AQ che siano correlati con l’oggetto della fornitura richiesta dall’Amministrazione nel proprio specifico contesto (es. help desk, formazione, servizi di hosting, etc..). I servizi accessori non possono superare il 20% della base d’asta totale.
In ciascun AS, l’Amministrazione comporrà la propria specifica fornitura partendo dalla selezione dei servizi applicativi necessari, o parte di essi, integrando con eventuali servizi di supporto ed eventualmente aggiungendo i propri servizi accessori: tutti necessari al raggiungimento degli obiettivi applicativi ed ICT dell’Amministrazione.
Essendo la presente iniziativa rivolta al soddisfacimento delle esigenze applicative degli enti della PA, essa potrà coprire i vari ambiti tecnologici supportando i diversi processi operativi ed amministrativi degli Enti, quali a titolo esemplificativo:
• i processi di gestione delle risorse umane,
• il Back-office (affari generali, contabilità e tributi, assistenza, urbanistica, polizia, lavori pubblici, patrimonio ed ambiente),
• i processi del Front-office e di Supporto al cittadino,
• la gestione dei contenuti-documentazione-sistema di conoscenza,
• lo sviluppo di servizi gestiti condivisi (shared services),
• le applicazioni a supporto delle smart city,
• i sistemi di e-Procurement,
• i modelli innovativi quali e-Government e Mobile-Government.
Si sottolinea che i Fornitori concorrenti devono disporre di ampie competenze tecniche per svolgere i servizi applicativi nei diversi ambiti tecnologici-applicativi-funzionali.
In considerazione della necessità di aggregare, in fase di AQ, per macro tipologie i progetti e le caratteristiche dei sistemi mediamente in uso nelle amministrazioni, le principali classi di progetto sono rappresentate da:
- sistemi gestionali: supportano i processi amministrativi e sono particolarmente critici; sono caratterizzati da complessità funzionale, ed utilizzano spesso grandi basi dati; il software è generalmente stratificato nel tempo; possono essere sviluppati ad hoc o richiedono la personalizzazione di funzionalità di un pacchetto commerciale, open source, in riuso, ecc… integrato o da integrare nei sistemi informativi dell’Amministrazione; un caso particolare è rappresentato dai sistemi documentali che personalizzano il workflow, le tematiche di protocollo,
archivistiche, di indicizzazione, di gestione dei volumi, ecc.. prevalentemente attraverso l’uso di piattaforme specializzate;
- siti Web e applicazioni web/mobile: massimizzano l’usabilità e l’accessibilità da parte degli utenti, la tempestività, la sicurezza applicativa;
- sistemi conoscitivi, Business Intelligence e Analytics: vengono alimentati da sistemi gestionali e/o aggregando dati da diverse fonti (interne ed esterne) ottimizzando i processi di acquisizione, gestione e fruizione dei dati, i sistemi conoscitivi devono offrire strumenti di analisi e sintesi dei fenomeni amministrativi – nelle varie tematiche
– garantendo qualità dei dati ed affidabilità dei processi e dei risultati.
I raggruppamenti utilizzati – ai soli fini di aggregare le varie richieste e raccogliere le diverse caratteristiche – non sono indipendenti ma spesso i nuovi progetti informatici o di reingegnerizzazione di sistemi esistenti richiedono competenze ed esperienze tali da permettere che i team che possano operare su più ambiti al fine di ottimizzare i processi dell’amministrazione agendo su tutti gli strumenti e piattaforme disponibili. In particolare, la multicanalità, l’accessibilità, l’usabilità sono ormai un elementi imprescindibile delle applicazioni aperte all’utenza.
I concorrenti devono pertanto disporre delle competenze tecniche e professionali per supportare le Amministrazioni nei vari ambiti tecnologici, applicativi e funzionali descritti a livello generale in AQ.
In sede di Appalto Specifico l’Amministrazione definirà puntualmente le caratteristiche del proprio ambiente tecnologico e applicativo, il dettaglio dei servizi richiesti dettagliandone tutte le caratteristiche e le modalità di erogazione, di misurazione e di monitoraggio delle attività, aggiungendo, modificando e integrando le previsioni di AQ al fine di rendere la richiesta d’offerta completamente aderente ai puntuali requisiti specifici del progetto ed attività richieste.
3.1 Durata
La durata dell’Accordo Quadro è di 12 mesi, prorogabile per ulteriori 12 mesi.
La durata dell’Appalto Specifico è a discrezione dell’Amministrazione, entro i seguenti vincoli:
• la durata dell’erogazione dei servizi deve essere pari od inferiore a 60 mesi, ivi inclusa la manutenzione correttiva in garanzia a fine contratto;
• la manutenzione correttiva in garanzia a fine contratto non può superare i 12 mesi (cfr. 4.4. Garanzia);
• le attività di subentro/presa in carico dei servizi antecedenti all’erogazione dei servizi sono generalmente pari a due mesi per i “contratti grandi”, in funzione della criticità delle applicazioni e dei progetti per i contratti “piccoli-medi”-
In caso di attivazione del Lotto 3 dell’AQ Servizi Applicativi edizione 1 si rinvia alle disposizioni del capitolato d’oneri.
3.2 Obblighi di comunicazioni
I Fornitori aggiudicatari di ogni Accordo Quadro si obbligano a fornire le informazioni necessarie al monitoraggio dell’AQ, al controllo dell’erosione dell’importo complessivo da parte di Consip. In fase di attivazione dell’Accordo Quadro - o in un momento successivo - Consip comunicherà la tipologia e la periodicità dei flussi dati - ulteriori rispetto ai dati per la FEE – relativi ad informazioni non presenti sul sistema di e-procurement.
A titolo di esempio potrà essere richiesto a ciascun fornitore aggiudicatario di AS la compilazione di dati relativi alle date effettive di aggiudicazione, di stipula, di decorrenza dell’AS nonché la durata e l’importo contrattuale.
3.3 Luogo di esecuzione dei servizi e spese di trasferta
I servizi oggetto del presente AQ dovranno essere erogati, come indicato al paragrafo 7.6, presso le sedi dell’impresa e/o dell’Amministrazione e/o della Committente – qualora diversa dall’Amministrazione (es. Ente che
opera a favore di altre amministrazioni, es. Sogei S.p.A. può richiedere servizi per i propri progetti/attività o per progetti/attività per Ministero dell’Economia e delle Finanze, quest’ultimo, inoltre, dispone di più sedi).
Le sedi effettive e puntuali per l’erogazione di ciascun servizio/attività potranno essere definite a livello di AS.
In sede di AQ non sono previsti oneri per rimborso di spese di trasferta in quanto non si dispone delle informazioni puntuali di esecuzione dei possibili AS che potrebbero essere attivati.
Fermo restando che le attività da svolgersi presso le sedi dell’Amministrazione e/o della Committente (generalmente presenti nella stessa città e/o provincia) dichiarate in AS non ammettono spese di trasferta, qualora ci sia l’esigenza di svolgere attività almeno al di fuori della provincia di riferimento della sede indicata, l’Amministrazione potrà prevedere in AS la disciplina puntuale delle spese di trasferta.
4 DESCRIZIONE DELLA FORNITURA
4.1 Servizi applicativi IT
I servizi applicativi comprendono i servizi realizzativi di software, i servizi di gestione del portafoglio applicativo ed i servizi tecnico-specialistici.
I servizi realizzativi sono così differenziati:
• Sviluppo, manutenzione evolutiva, adeguativa, migliorativa di software ad hoc ovvero di software specifico realizzato/modificato su esigenze funzionali e tecniche dell’Amministrazione (e dunque di proprietà dell’Amministrazione stessa);
• Personalizzazione e parametrizzazione di soluzioni commerciali o di software open source o di software in riuso.
Ciascuna Amministrazione dovrà predisporre il documento di contesto tecnologico ed applicativo con la puntuale indicazione delle competenze tecniche ed esperienziali necessarie all’erogazione della fornitura.
Ciascun AS dovrà caratterizzare i servizi realizzativi sulle proprie necessità siano esse relative alla realizzazione/modifica/personalizzazione di un unico progetto realizzativo oppure quale sommatoria stimata di più esigenze progettuali sull’arco temporale definito in AS.
In quest’ultimo caso, il servizio sarà dimensionato quale somma degli interventi progettuali stimati/pianificati – definiti anche “Obiettivi” che dovranno essere organizzati attraverso un piano di lavoro.
In ragione della propria organizzazione ICT le attività progettuali realizzative potranno essere affidate con la modalità “ciclo intero o completo”– a partire dall’analisi dei requisiti e sino all’avvio in esercizio – sia “cicli realizzativi” qualora l’Amministrazione affidi al fornitore di AS la sola realizzazione del sw. A titolo esemplificativo, l’Amministrazione può disporre di risorse interne che presidiano le attività informatiche e in particolare mantengono un forte controllo delle fasi alte del ciclo di vita (definizione dell’architettura applicativa, dell’analisi dei requisiti e dell’analisi funzionale) dando in affidamento unicamente la fase realizzativa.
Qualsiasi sia il ciclo e l’ambito applicativo, il fornitore ha già garantito con la partecipazione all’AQ che ciascun rilascio di software sarà pienamente rispondente ai requisiti/funzioni richieste dall’Amministrazione, performanti nell’ambiente di esercizio richiesto, accessibili, usabili, affidabili, sicure (100% delle vulnerabilità note) e manutenibili.
A tal fine, il fornitore dovrà autonomamente disporre di idonei strumenti, risorse ed organizzazione per prevenire, misurare, testare, correggere il software e le funzionalità affidategli.
In ogni caso il sw realizzato o modificato deve essere pienamente testato in ciascuna fase di sviluppo e per tutte le tipologie di test necessarie (dallo unit test ai test di sistema, ai test di performance, di sicurezza, ec..) nonché rispondente alle linee guida, standard e best practice di tecnologia, dimostrando l’assenza di “non conformità tecniche”.
La mancata accessibilità delle applicazioni web è causa di nullità del contratto di AS come previsto dalla legge.
L’Amministrazione dovrà trasmettere a Consip tutti i casi di mancato adempimento rispetto ai requisiti espressi in AQ al fine delle necessarie valutazioni relative al monitoraggio dell’AQ.
In sede di AS l’Amministrazione può richiedere la compatibilità con gli strumenti di testing adottati dall’Amministrazione stessa.
L’utilizzo di specifici strumenti – adottati dall’Amministrazione – può essere valutata in specifici criteri di aggiudicazione di AQ.
4.1.1 Sviluppo, Manutenzione evolutiva, adeguativa e migliorativa di Software ad hoc
Il servizio si riferisce alla realizzazione, all’evoluzione, all’adeguamento, alla modifica di un prodotto/sistema/applicazione software ad hoc volto a soddisfare le esigenze espresse dall’Amministrazione.
Nella fattispecie, i sotto casi inclusi in questo servizio sono:
• Sviluppo di software, che comprende:
▪ gli sviluppi di interi nuovi sistemi informativi o applicazioni, o parti autonome degli stessi;
▪ rifacimento di sistemi informativi o applicazioni;
• Manutenzione evolutiva di software ad hoc, che comprende gli interventi volti ad arricchire le applicazioni esistenti di nuove funzionalità, o comunque a modificare e/o integrare le funzionalità già esistenti. In questa fattispecie è ricompresa la manutenzione migliorativa ovvero Piccoli interventi di breve durata finalizzati ad aumentare la fruibilità dell’applicazione (es. la modifica di una transazione o di un tabulato per una diversa prospettazione dei dati, la modifica di una segnalazione, ecc.). I Piccoli interventi possono comportare una variazione, di norma molto limitata, della consistenza della baseline.
• Manutenzione Adeguativa: comprende l’attività volta ad assicurare la costante aderenza delle procedure e dei programmi all’evoluzione dell’ambiente tecnologico del sistema informativo e al cambiamento dei requisiti (organizzativi, normativi, d’ambiente). Normalmente viene innescata dall’esigenza di :
• adeguamenti dovuti a cambiamenti di condizioni al contorno (ad esempio per variazioni al numero utenti, per migliorie di performance, per aumento delle dimensioni delle basi dati, ecc.);
• adeguamenti necessari a seguito di innalzamento di versioni del software di base;
• adeguamenti intesi all’introduzione di nuovi prodotti o modalità di gestione del sistema;
• migrazioni di piattaforma;
• modifiche, anche massive, non a carattere funzionale, alle applicazioni (ad esempio cambiamento di titoli sulle maschere, ecc.).
Sempre più si riscontra la necessità dell’Amministrazione di implementare sistemi integrati con funzionalità vicine al cittadino usabili su dispositivi mobili (tablet, smartphone e altri) e che possono richiedere principalmente la progettazione e realizzazione di interfacce grafiche di tipo touch screen garantendo la portabilità su diversi browser e/o l’integrazione con sistemi di georeferenziazione e/o l’integrazione con Google application, ecc..
Pertanto, le imprese aggiudicatarie dovranno possedere tali competenze e garantire nell’erogazione un approccio innovativo, integrato in tutte le attività realizzative.
Con riferimento ai siti WEB, lo sviluppo riguarda la possibilità di creare diverse tipologie di siti/portali, per i quali alcuni requisiti sono imprescindibili, come ad esempio:
• siti internet istituzionali: canale di comunicazione sia per veicolare l’immagine dell’Amministrazione sia per fornire informazioni al pubblico; la correttezza, la tempestività e la tracciabilità delle informazioni pubblicate sul sito sono i requisiti fondamentali;
• siti temporanei per iniziative e/o esigenze specifiche: la velocità ed il costo di creazione del sito sono i principali requisiti;
• siti transazionali: consentono al pubblico di effettuare operazioni via Internet in modalità “self service”, evitando spostamenti e file agli sportelli; i requisiti principali sono la facilità d’uso e l’affidabilità del servizio;
• siti Intranet: facilitano il rapido accesso alle informazioni, la collaborazione e la condivisione di conoscenze da parte del personale interno.
• siti extranet per l’accesso a servizi operativi, di collaborazione, condivisione di dati e materiale informativo da parte di utenze abilitate all’accesso, esterne alla rete locale dell’Amministrazione; aspetti preponderanti sono: la sicurezza di accesso al sistema e alle sorgenti informatiche, il controllo e il monitoraggio delle attività effettuate nell’utilizzo delle funzionalità presenti.
Caratteristiche ormai basilari per l’Amministrazione digitale sono la sicurezza applicativa, la multicanalità, la versatilità, l’usabilità al fine di facilitare l’accesso dei servizi ai cittadini.
La migrazione di un sito web su nuove tecnologie è da considerarsi sotto tutti i punti di vista come lo sviluppo di un nuovo sito. Alle attività previste andranno comunque decurtate quelle che non necessitano di una riscrittura del codice oggetto di migrazione, come ad esempio eventuali procedure funzionali (form di ricerca, assistenza e modulistica online, job di allineanti del database, ecc.), layout e/o bozzetti grafici.
Con riferimento ai progetti di sviluppo, evoluzione, manutenzione adeguativa, di personalizzazione e parametrizzazione di sistemi conoscitivi ci si riferisce sia ad attività di evoluzione di DW “interni”, di cruscotti, sistemi di supporto alle decisioni, soluzioni di Business Intelligence ed Analytics tradizionali sia alla progettazione ed implementazione di tecniche e strumenti evoluti.
In generale la digitalizzazione dei processi amministrativi ha comportato e comporterà sempre di più l’acquisizione di dati strutturati, semi-strutturati e non strutturati aggiuntivi alla tradizionale acquisizione dei dati dai sistemi gestionali.
L’aumento dei dati disponibili e rilevanti richiede l’implementazione di sistemi analitici evoluti che si affiancano ai tradizionali Data Warehouse.
Assumono sempre maggiore diffusione nelle Pubbliche Amministrazione – in particolare le Amministrazioni Centrali - le piattaforme di Big Data, Streaming Anaytics, Predictive ed Advanced Analytics. Così come a valle dei sistemi gestionali viene richiesta la produzione di Open Data.
Progetti di modernizzazione di Data Warehouse tradizionali richiedono la conoscenza di DBMS SQL e NOSQL, moderne tecniche di progettazione, rappresentazione e visualizzazione dei dati, di Machine Learning, tecniche di “self-service BI”, di Agile Data Modeling, di Fast data, ecc..
I fornitori aggiudicatari dovranno pertanto disporre di risorse professionali, strumenti, know how specifici e costantemente aggiornati al fine di supportare le Amministrazioni in questo processo evolutivo.
4.1.2 Personalizzazione e parametrizzazione di soluzioni commerciali o di software open source o di software in riuso
Il servizio consiste principalmente nella personalizzazione e parametrizzazione di software commerciale ed in attività volte al riuso, adeguamento, customizzazione ed integrazione di software già disponibile in base agli obiettivi, funzionali o meno, richiesti dall’Amministrazione.
Per "riuso di programmi informatici o parti di essi" si intende la possibilità per una Pubblica Amministrazione di riutilizzare gratuitamente programmi informatici o parti di essi quando:
• il software è di proprietà di una Pubblica Amministrazione ovvero sviluppato per conto e a spese di un’altra Amministrazione ;
• appartengono alla categoria del software libero o a Codice sorgente aperto. Nel dettaglio, per il servizio in oggetto:
• per parametrizzazione si intende l’utilizzo di funzionalità native, accessibili tramite menù decodificati, in cui è possibile impostare determinati parametri o configurare il funzionamento del programma senza necessità di sviluppo e conoscenza di codice o linguaggi informatici. In questo caso, il fornitore dovrà disporre di competenze approfondite relative allo specifico pacchetto software presente presso l’Amministrazione e che sarà indicato all’interno del singolo AS.
• la personalizzazione è finalizzata a coprire ulteriori esigenze funzionali non originariamente offerte dalla soluzione con una limitata attività di sviluppo software, come per esempio la predisposizione di interfacce con altri sistemi, la realizzazione di funzionalità non presenti nel pacchetto/sw esistente, nuovi rapporti di stampa, o altro. In questo caso valgono, dunque, i requisiti generali espressi per il servizio realizzativo di sw ad hoc e laddove necessario integrati dalla conoscenza del pacchetto/sw open source od in riuso al cui contorno devono essere sviluppate le personalizzazioni.
In questo servizio verranno dunque comprese le attività sui software commerciali quali ad esempio ERP, CRM, SRM, PLM, SCM, e-procurement, Knowledge and Content Management, Business Intelligence, sistemi di gestione documentale (Filenet, Documentum, SharePoint, ecc.) e package specifici dei vari comparti (sanità, ecc..), nonché sui sistemi open source quali Open CMS, Moodle, documentale Alfresco, ecc..
4.1.3 Servizi di Gestione del portafoglio applicativo
Tipicamente le attività di gestione si differenziano nei seguenti servizi:
• Gestione applicativi e basi dati
• Gestione dei contenuti di Siti Web
• Manutenzione Correttiva
Tali raggruppamenti permettono di identificare caratteristiche e modalità di erogazione comuni. Sarà comunque l’Amministrazione, in ciascun Appalto Specifico, a definire il contesto puntuale e la strutturazione dei servizi maggiormente rispondente alle proprie esigenze.
Pertanto, i raggruppamenti proposti non sono vincolanti. L’amministrazione potrà richiedere anche l’attività con un unico gruppo di lavoro che dispone di professionalità che a questo livello vengono suddivise nei diversi gruppi. A titolo di esempio, in un AS di limitate dimensioni – lotti 3,4,5,6,7 – che richiede servizi per la gestione di un numero limitato di applicazioni, l’Amministrazione può contestualizzare il proprio servizio di gestione con un unico gruppo di risorse che abbiano i profili necessari (es. Analista Funzionale, Publisher, DBA, programmatore).
4.1.3.1 GESTIONE APPLICATIVI E BASI DATI
Il servizio di Gestione applicativi e basi dati comprende l’insieme di attività, risorse e strumenti di supporto per la gestione delle applicazioni e delle loro relative basi dati. In funzione dell’organizzazione dell’Amministrazione, il servizio può includere il contatto diretto con gli utenti delle applicazioni che potranno rivolgersi direttamente al servizio via telefono e/o via e.mail o portale web oppure indirettamente tramite un Help Desk di I livello. Laddove previsto il colloquio con l’utenza, oltre alla tempestività ed efficacia dell’assistenza fornita, acquista particolare rilevanza la professionalità nella gestione della relazione con l’utenza.
Le risorse del Fornitore preposte al servizio dovranno acquisire e mantenere un’ottima preparazione sia funzionale sia tecnica sui sistemi, sulle applicazioni ed in genere sul patrimonio applicativo dell’Amministrazione. Tali risorse dovranno lavorare in sinergia con il team dei servizi realizzativi e con i restanti team sugli altri servizi al fine di rispondere prontamente ed efficacemente alle diverse attività contenute nel servizio stesso.
I livelli di servizio minimi sono presenti nell’Appendice 2 - Indicatori di qualità.
Le principali attività che il Fornitore può essere chiamato ad eseguire nell’AS sono:
• Gestione delle funzionalità in esercizio:
▪ servizio di help desk (se non attivato separatamente) su postazioni attrezzate dall’Amministrazione;
▪ risoluzione delle richieste di intervento aperte dall’utente;
▪ intercettazione e registrazione dei problemi alla fonte, classificazione, eventuale riproduzione dell’errore e, se necessario, conseguente attivazione del servizio di garanzia software e/o di Manutenzione Correttiva, laddove previsto, e verifica dell’esito dell’intervento effettuato. A tale proposito il Fornitore registrerà le informazioni utili alla verifica degli indicatori di qualità del servizio e alla produzione della necessaria reportistica, anche attraverso un opportuno strumento di Trouble Ticketing sia esso messo a disposizione dall’Amministrazione o richiesto al Fornitore nell’ambito dell’Appalto Specifico;
▪ validazione tecnica e controllo dei risultati delle elaborazioni, al fine di assicurare l’integrità e la correttezza dei dati presenti sulla base informativa, del contenuto dei flussi informativi provenienti o destinati ad organismi esterni e dei dati esposti negli elaborati del sistema;
▪ ripristino base dati (non determinata da malfunzionamenti di software in garanzia od in manutenzione correttiva);
▪ modifiche di parametri di esecuzione o di tabelle di riferimento o decodifica;
▪ verifica ed aggiornamento di eventuale documentazione specifica della gestione applicativa contenente FAQ, modi d’uso, modalità di esecuzione di particolari attività del servizio di gestione (ad esempio manutenzione preventiva, ecc.);
▪ gestione della configurazione;
▪ realizzazione di prodotti informatici o erogazione di servizi “ad hoc”, per soddisfare particolari e puntuali esigenze dell’utente, non risolvibili con le funzionalità disponibili nel sistema informativo e che di norma non entrano a far parte stabile del parco applicativo. Tipico esempio può essere un intervento la realizzazione di un prospetto informativo “usa e getta”.
• Presa in carico di nuove funzionalità in esercizio:
▪ schedulazione e pianificazione del rilascio in esercizio di nuove funzionalità;
▪ attività di parametrizzazione specifiche su procedure, parametri e tabelle, manuale utente, manuale di gestione, definizioni relative ai dati, ecc..;
▪ supporto alla predisposizione dell’ambiente di esercizio, e quanto necessario a consentire l’inizio delle attività da parte degli utenti;
▪ gestione della nuova configurazione;
▪ affiancamento all’utente finale volto ad istruirlo all’uso delle funzionalità sia nuove che già presenti in esercizio.
• Supporto agli utenti, per l’uso appropriato delle funzioni secondo le modalità previste nei manuali d’uso:
▪ Assistenza tecnico/funzionale agli utenti;
▪ preparazione di documentazione aggiuntiva rispetto a quella a corredo dei sistemi in esercizio, (es. documenti di sintesi, demo, presentazioni, ecc.);
▪ predisposizione dell’ambiente dimostrativo (es. base dati, utenze specifiche, ecc).
• Pianificazione funzionale del servizio:
▪ movimentazione giornaliera dei batch, se applicabile;
▪ disponibilità del servizio on line (funzionalità TP);
▪ controllo e fasatura dell’introduzione di nuove versioni di software di base (anche in via estemporanea e/o transitoria) nell’ambiente gestionale;
▪ pianificazione ed esecuzione di elaborazioni di prova, con relativa ripresa di dati reali, a scopo di manutenzione preventiva, per anticipare l’esito dell’elaborazione di procedure critiche per l’Amministrazione.
L’Amministrazione potrà richiedere in AS:
▪ Attività di manutenzione correttiva su sw pregresso (in alternativa ad attivare un servizio specifico);
▪ Attività di manutenzione migliorativa e/o adeguativa di limitato impatto (normalmente inferiore a 10 giorni lavorativi)
▪ Affiancamento per il trasferimento di know how necessario al corretto svolgimento del servizio: l’attività consiste in una fase di “training on the job” a terzi individuati dall’Amministrazione, finalizzata a trasmettere il know how funzionale applicativo e tecnico-sistemistico necessario alla gestione del software in esercizio. All’attivazione verranno concordate le risorse professionali impegnate nell’attività che potranno appartenere anche a diversi servizi, ad es. l’operatore di publishing, ecc.. Potranno essere attivati anche più obiettivi per trasferimenti parziali relativamente a specifiche attività/applicazioni, ecc.
▪ Attività di data entry e di archiviazione: finalizzata all’alimentazione iniziale o al recupero di dati/documenti o attività di supporto alle migrazioni e/o all’archiviazione digitale dei documenti.
4.1.3.2 GESTIONE DEI CONTENUTI DI SITI, PORTALI E CANALI WEB
In caso di pluralità e complessità di siti, portali e canali web, si può impostare un servizio di gestione specificatamente per la Gestione dei Contenuti di siti Web.
Vi possono essere richieste le attività necessarie per eseguire i processi di seguito specificati per i siti (Internet, Intranet, Extranet, portali e motori di ricerca, community, social network e forum, ecc… ) che verranno indicati dall’Amministrazione in Appalto Specifico:
• creazione, classificazione e archiviazione dei contenuti del sito, mediante una stazione editoriale di facile uso per gli Autori e uno strumento di workflow per supportare i flussi di aggiornamento e approvazione dei contenuti;
• pubblicazione dinamica dei contenuti su Internet e/o sulla Intranet, mediante l’estrazione dei contenuti dall’archivio e la produzione in linea di pagine web applicando template, fogli di stile e interfacce di navigazione (in modo da garantire la separazione fra contenuti e presentazione). Inoltre, la pubblicazione può utilizzare un motore di regole per filtrare e personalizzare le pagine in base ai profili utente e/o in base al canale di fruizione (personal computer, palmare, telefonino, carta, ecc.);
• aggiornamento e fine-tuning del sito, mediante strumenti di analisi dell’uso del sito da parte dei suoi utenti, ovvero analisi dei contenuti, degli accessi e del traffico;
• realizzazione di news, focus, newsletter, servizi audiovisivi e altri prodotti informativi anche multimediali da pubblicare sui canali social istituzionali;
• monitoraggio e analisi del flusso di informazioni social;
• supporto alle implementazioni progettuali dell’architettura delle informazioni del portale Internet/Intranet (mappatura, indicizzazione, taggatura e correlazione dei contenuti);
• gestione redazionale delle web community e dei canali interni di social collaboration e social enterprise.
I servizi di Gestione dei Contenuti siti Web possono essere erogati da una soluzione autonoma oppure da una soluzione di Enterprise Content Management. L’Amministrazione in Appalto Specifico indicherà la modalità richiesta.
Il fornitore è tenuto a conoscere le principali piattaforme, framework e soluzioni di Enterprise Content Management.
Segue una descrizione delle principali attività per i sottogruppi Content Management, Publishing e Monitoraggio e Tuning. Tale elenco non è esaustivo e dunque potrà subire variazioni nel corso della fornitura.
Content Management
E’ richiesto al Fornitore di eseguire i processi di creazione, classificazione e archiviazione dei contenuti di un sito web, mediante una stazione editoriale e uno strumento di workflow per supportare i flussi di aggiornamento e approvazione dei contenuti. Pertanto, le principali attività sono:
• Gestione del repository dei contenuti: gestione del ciclo di vita e delle versioni dei contenuti, gestione dei metadati, gestione della granularità e delle strutture di componenti elementari di contenuto, gestione della configurazione, gestione dei link, gestione degli accessi, supporto per contenuti multimediali (p.e.: testi; linguaggi HTML, XML, VoiceXML, SGML; immagini; Macromedia flash, audio download e streaming, video download e streaming, applet, contenuti con gestione dei diritti);
• Gestione della presentazione: template, fogli di stile, architettura informativa, navigazione, ecc.;
• Supporto alla migrazione di contenuti da siti e/o archivi già esistenti;
• Stazione editoriale per la creazione e modifica dei contenuti;
• Stazione editoriale per la gestione della struttura delle pagine e del sito;
• Supporto alla creazione e gestione di workflow editoriali per l’approvazione e modifica dei contenuti;
• Supporto alla creazione e alla gestione della tassonomia di contenuti;
• Supporto XML per la generazione/modifica/archiviazione dei contenuti;
• Supporto multicanale (PC, palmare, telefoni cellulari, SMS, WAP, XHTML, carta/PDF, ecc.), strumenti per trasformazione/adattamento dei contenuti, server di staging, versioning del sito e dei contenuti, possibilità di rollback delle modifiche;
• Servizi di collaborazione: forum, bulletin board;
• Indicizzazione e ricerca dei contenuti testuali.
Servizi redazionali, di web publishing e di progettazione editoriale
Le attività dei servizi redazionali sono relative alla gestione del ciclo di produzione, contribuzione e pubblicazione di contenuti web.
Comprende l’esecuzione di processi di pubblicazione dinamica dei contenuti su Internet e/o sulla Intranet, mediante l’estrazione dei contenuti dall’archivio e la produzione anche manuale in linea di pagine web applicando template, fogli di stile e interfacce di navigazione (in modo da garantire la separazione fra contenuti e presentazione). Inoltre, la pubblicazione può utilizzare un motore di regole per filtrare e personalizzare le pagine in base ai profili utente e/o in base al canale di fruizione (personal computer, palmare, telefonino, carta, ecc.).
Pertanto, le principali attività sono:
⮚ Gestione dei contenuti: a titolo esemplificativo e non esaustivo, comporta:
• analisi, creazione, modifica, aggiornamento, rimozione, approvazione e pubblicazione delle informazioni e dei contenuti: aggiornamenti automatici, supporto multicanale (PC, palmare, telefoni cellulari, SMS, WAP, XHTML, carta/PDF, ecc.), strumenti per trasformazione/adattamento dei contenuti, server di staging, versioning del sito e dei contenuti, possibilità di rollback delle modifiche;
• raccolta dei dati nella sezione di “Amministrazione trasparente” e individuazione delle modalità di presentazione delle relative informazioni in conformità al d.lgs. 33/2013 e s.m.i. e alla eventuale normativa sopravvenuta;
• trattamento editoriale dei contenuti redazionali e supporto alla implementazione dell’architettura delle informazioni ai fini della presentazione dei dati nella sezione “Open data”;
• valutazione di pertinenza e inserimento di metadati e taggatura per la correlazione dei contenuti, applicazione di regole per filtrare e personalizzare le pagine in base ai profili utente e/o al canale di fruizione;
• predisposizione e elaborazione di elementi multimediali a corredo dei contenuti (immagini, banner interattivi, audio, video, animazioni, con gestione dei relativi diritti di utilizzo);
• produzione di news, newsletter, dossier, tutorial e altri prodotti informativi;
• Servizi di collaborazione: forum, bulletin board;
• Indicizzazione e ricerca dei contenuti testuali e/o multimediali.
• supporto alla realizzazione di template e associazione a specifici contenuti, adattamenti e
⮚ integrazioni all’architettura delle informazioni, definizione di percorsi di navigazione;
⮚ mappatura dei contenuti a supporto della migrazione dai siti e/o archivi esistenti;
⮚ creazione e gestione di workflow editoriali per l’approvazione e la modifica dei contenuti;
⮚ creazione e aa gestione della tassonomia di contenuti;
⮚ definizione di linee guida ed editing di contenuti e metadati per ottimizzare l’indicizzazione e la ricerca dei contenuti testuali e multimediali sui motori interni ed esterni.
Monitoraggio e Tuning
Comprende l’esecuzione di processi di aggiornamento e fine-tuning del sito, mediante strumenti di analisi dell’uso del sito da parte dei suoi utenti, ovvero analisi dei contenuti, degli accessi e del traffico.
Pertanto, le principali attività sono:
• profiling e personalizzazione, gestione del processo di registrazione e del database utenti registrati, gestione profili e gruppi di utenti;
• gestione delle pagine del sito o portale: servizi nativi di “portal builder” e/o supporto all’integrazione con altri portali; compatibilità con le portlet standard Java (JSR 168); supporto per JSR 170 (API Java 2 Standard per l’accesso a “content repositories”);
• servizi e strumenti di verifica della qualità dei contenuti;
• gestione di siti multipli e/o distribuiti (home page multiple con accesso a contenuti condivisi e/o contenuti su più siti distribuiti);
• supporto multilingua ed eventualmente servizi di traduzione;
• analisi e reporting: analisi dei log e generazioni di report sul traffico e sull’uso del sito da parte degli utenti;
• storicizzazione ai fini di revisione e controllo (p.e., controversie legali, ecc.);
• gestione della sicurezza: controllo di accesso, gestione autorizzazioni, resistenza ad attacchi esterni, certificazione dell’integrità di contenuti da fornitori esterni.
4.1.3.3 SERVIZIO MANUTENZIONE CORRETTIVA
Per servizio di manutenzione correttiva si intende la diagnosi e la rimozione delle cause e degli effetti, sia sulle interfacce utente che sulle basi dati, dei malfunzionamenti delle procedure e dei programmi in esercizio ed in genere di tutti i componenti del sistema non in garanzia.
Infatti, la garanzia già copre completamente la rimozione degli errori su tutto il software sviluppato/modificato dai servizi realizzativi del medesimo AS. Inoltre, nel primo anno contrattuale è generalmente presente la garanzia del fornitore uscente.
Il servizio di manutenzione correttiva viene innescato da una segnalazione di impedimento all’uso dell’applicazione di una o più delle sue funzioni. Per impedimento si intende una malfunzione vera e propria dell’applicazione o gli effetti che tale malfunzione ha causato alla base dati (es. anomalie in un programma batch che corrompono la base dati).
I malfunzionamenti, le cui cause non sono imputabili a difetti presenti nel software applicativo, ma ad errori tecnici, operativi o d’integrazione con altri sistemi (ad esempio interruzione del collegamento TP, uso improprio delle funzioni, ecc.), oppure relativi a software in garanzia (del fornitore uscente), comportano, da parte del servizio di manutenzione correttiva, il solo supporto all’attività diagnostica sulla causa del malfunzionamento, a fronte della segnalazione pervenuta, ma sono poi risolti da altre strutture di competenza. Analogamente per il software realizzato/modificato nel corso del medesimo Appalto Specifico, i malfunzionamenti dovranno essere risolti nell’ambito dei servizi realizzativi in quanto coperto dalla garanzia.
Sono parte integrante del servizio di Manutenzione Correttiva le seguenti attività:
• contributi di competenza sistemistica e specialistica di prodotto necessari alla corretta soluzione del malfunzionamento;
• attivazione del gruppo di sviluppo per adeguare l’eventuale software in corso di sviluppo/modifica/collaudo;
• test in ambiente assimilabile all’ambiente di esercizio della soluzione realizzata;
• gestione della configurazione;
• in caso di malfunzioni su programmi di interfaccia verso l’esterno, validazione tecnica e controllo dei risultati del contenuto dei flussi informativi destinati a strutture esterne o dei dati esposti negli elaborati del sistema;
• allineamento della documentazione.
Nel caso in cui i sistemi dell’Amministrazione comprendano pacchetti e/o sw personalizzato o integrato, il servizio di manutenzione correttiva:
• in caso di malfunzionamenti sulla componente di pacchetto di mercato è finalizzato a diagnosticare la natura del malfunzionamento distinguendo se questo è:
a) all’interno del codice sorgente del pacchetto di mercato o
b) all’interno del software parametrizzato/personalizzato;
• nel caso a) il servizio è tenuto alla tempestiva apertura della segnalazione sul contratto di manutenzione dello specifico pacchetto ed alla successiva verifica dell’esito dell’intervento effettuato; le risorse deputate al servizio dovranno dimostrare un’approfondita conoscenza del pacchetto utilizzato dall’Amministrazione, tale da azzerare i rischi di apertura di segnalazioni di malfunzionamento errate ovvero segnalazioni che si risolvono con parametrizzazione del pacchetto;
• nel secondo caso b) vale quanto già indicato per le malfunzioni sul sw ad hoc.
Laddove applicabile, il servizio include la validazione tecnica ed il controllo dei risultati del contenuto dei flussi informativi da/per il pacchetto.
All’affidamento del servizio il fornitore è tenuto ad analizzare il software esistente – a campione o nella sua totalità
– al fine di determinare la qualità intrinseca del software in tutte le sue caratteristiche e sottocaratteristiche secondo la ISO 25010 e successivo, e determinare il debito tecnico per funzione/applicazione.
Queste misure non possono, in nessun caso, essere peggiorate dalle attività della fornitura.
4.1.4 Servizi Tecnico-Specialistici
I Servizi Tecnico-Specialistici comprendono progetti/attività/studi di natura ICT e di livello specialistico. Generalmente sono attività propedeutiche ovvero integrative ovvero di ausilio ai servizi sia applicativi ed in particolare ai servizi realizzativi al fine di rendere sinergici ed esaustivi tutti i componenti della fornitura. Come per gli altri servizi, l’Amministrazione può individuare attività puntuali – un singolo progetto definito nei contenuti e nei risultati attesi – oppure raccogliere le esigenze di intervento sull’arco temporale della fornitura dell’AS. Pertanto, in questo ultimo caso, le attiverà di volta in volta attraverso singoli obiettivi o singole attività.
Le attività Tecnico-Specialistiche non devono in nessun caso sovrapporsi alle attività richieste nelle fasi di definizione e analisi dei requisiti nei servizi realizzativi.
In una lista esemplificativa e non esaustiva si citano le seguenti attività:
• Know How specialistico e sistemistico
▪ problem solving di alto livello su tematiche tecniche, di progettazione dei sistemi;
▪ consulenza specialistica ingegneristica sul CAD;
▪ attività sistemistiche e specialistiche per l’utilizzo di prodotti software;
▪ predisposizione di relazioni tecniche per studi di fattibilità, redazione di documenti di architettura, individuazione dei requisiti di sistema, valutazioni make or buy, analisi d’impatto, ecc..
• Attività di analisi
▪ redazione di studi, analisi di fattibilità, stima dei tempi e costi, stima dei benefici, comparazione tra diverse possibili soluzioni, valutazione di soluzioni che prevedano l’utilizzo e l’eventuale personalizzazione di prodotti software presenti sul mercato;
▪ implementazione o revisione delle policy di sicurezza informatica (senior level);
▪ studi per la migrazione “da fisico a virtuale” dei CED e relativa disponibilità dei servizi applicativa in modalità cloud;
▪ esecuzione di sperimentazioni (che non producano software applicativo) che richiedono competenze tecniche-specialistiche senior;
▪ sviluppo di prototipi, di tipo “usa e getta”, per esigenze non direttamente collegabili ai servizi realizzativi;
▪ definizione di metodologie e/o processi e studi di fattibilità per la definizione e gestione dei sistemi conoscitivi ad esempio negli ambiti data quality, database normalization, etc;
▪ Metodologia per personalizzazione/implementazione di sistemi intelligenti di supporto alle decisioni (Xxxxxx, ..)
L’elenco non si può considerare esaustivo ed immutabile, ma ciascuna Amministrazione nel proprio Appalto Specifico potrà identificare al meglio le proprie necessità comunque orientate a supportare lo sviluppo, la manutenzione e la gestione dei propri sistemi informativi.
4.2 I Servizi di Supporto
I servizi di questo gruppo sono propedeutici o preliminari od integrativi ad uno o più attività richieste all’interno dei servizi applicativi di cui al precedente paragrafo 4.1, e sono finalizzati a garantire che la soluzione applicativa sia la migliore risposta al cambiamento organizzativo e/o di processo od a fornire un determinante contributo tematico specialistico, non presente presso l’Amministrazione stessa.
A tal fine le principali attività generalmente richieste dalle Amministrazioni sono: il supporto al disegno e/o Ridisegno dei Processi ovvero Business Process Modeling and Business Process Reingeneering, il Demand Management, il supporto tematico scientifico e metodologico.
All’interno della presente iniziativa i servizi di supporto sono minoritari rispetto ai servizi applicativi.
L’AQ infatti si rivolge al mercato IT, purtuttavia può richiedere la capacità di affiancare competenze organizzative e consulenziali preliminari e/o di verifica del successo e tale proporzione deve essere mantenuta in ciascun AS. Pertanto, l’Amministrazione richiedente l’AS potrà richiedere servizi di supporto in via subordinata ai servizi applicativi e per un valore economico non superiore al 20% rispetto a quello dei servizi applicativi.
4.3 I Servizi Accessori
I servizi accessori sono attività ICT collegate ai servizi applicativi di cui ai paragrafi 4.1., finalizzati al completamento delle esigenze di funzionamento del sistema informativo dell’Amministrazione, ma completamente indipendenti e nuovi rispetto ai servizi applicativi.
In nessun caso i servizi di supporto possono richiedere i medesimi servizi applicativi o parte di essi già remunerati nelle tariffe offerte di I fase (es. attività di test e/o progettazione e realizzazioni di componenti non funzionali, etc. già incluse in tutte le attività realizzative).
I servizi accessori sono dunque attività che non hanno alcuna sovrapposizione con quanto già richiesto in AQ e solo per economia procedurale ed una gestione unitaria contrattuale possono essere inseriti negli Appalti Specifici.
Tali servizi non potranno superare il 20% della base d’asta totale dell’AS, e dovranno sempre appartenere all’ambito ICT.
A titolo esemplificativo possiamo citare i servizi elencati nei seguenti paragrafi.
4.3.1 Servizio Assistenza in remoto
Il servizio di Assistenza in remoto deve fornire agli utenti interni o esterni all’Amministrazione un punto di accesso unificato e un insieme di funzioni di assistenza.
In relazione alla numerosità e distribuzione territoriale dei destinatari finali, si ha la necessità di avvalersi di un servizio dedicato di assistenza organizzato in modo da presentare un’interfaccia unica verso gli utenti (call center) ed assicurare la tracciabilità in termini di segnalazioni/azioni intraprese.
E’ inoltre indispensabile la capacità di relazione con le diverse strutture al fine di coinvolgere i supporti più adeguati, creando sinergie con gli altri gruppi coinvolti nella fornitura.
Il Fornitore è tenuto a strutturare il servizio di assistenza in remoto del sistema sopra definito in:
• un servizio di help desk telefonico orientato a problemi di accesso, nonché di utilizzo;
• un servizio di supporto via e-mail su quesiti specifici.
L’accesso al servizio sarà effettuato attraverso chiamata su numero verde in tempo reale o differito (phone call back) e via e-mail.
Indicativamente, il servizio prevede :
• la predisposizione, presso la propria sede, di un centralino multilinea e l’attivazione del numero verde;
• la messa a disposizione di strumenti che consentano la fruizione delle applicazioni operative sotto internet;
• il trasferimento del know-how in caso di sostituzione operatori;
• la piena operatività di strumenti che consentano la gestione di un archivio delle richieste di assistenza, quali:
• la registrazione delle richieste di assistenza;
• la gestione della risoluzione del problema ed eventuale inoltro al livello di back end;
• il monitoraggio delle recidive sui ticket;
• il monitoraggio delle richieste di assistenza (livelli di servizio);
• la reportistica di sintesi.
Normalmente l’assistenza complessiva viene articolata su due livelli di intervento:
• il 1^ livello rappresentante il front office, che riceve i quesiti, effettua un primo censimento del problema sottoposto: laddove non riesce a risolverlo, lo smista al 2^ livello
• Il 2^ livello svolge attività di problem solving e si attiva anche interagendo con specifiche strutture in modo da fornire al 1^ livello gli elementi richiesti/necessari.
In particolare, il 1^ livello interviene soprattutto su quesiti a valenza amministrativa (regole, modalità di trattamento di realtà specifiche) e su richieste riguardanti l’utilizzo del sistema di classificazione delle informazioni, oltre a rispondere su quesiti di natura tecnica circa l’applicazione. Nel caso specifico, le strutture di livello superiore sono rappresentate dalla “gestione applicativa” (per problematiche a valenza tecnica) e da eventuali altre strutture dell’Amministrazione (negli altri casi). Le informazioni relative alle richieste di assistenza dovranno essere tali da essere riutilizzabili come feed back per la elaborazione di frequently asked questions (FAQ), nonché di interventi sull’applicazione e sulla documentazione di corredo.
4.3.2 Formazione ed Addestramento
L’introduzione di nuove applicazioni o nuove modalità di interazione con la PA può richiedere l’attivazione di progetti di istruzione, formazione ed addestramento sia per gli amministrativi sia per gli utenti. Tale attività, in funzione della distribuzione territoriale o dell’organizzazione del lavoro, può avvenire in diverse forme: da sessioni di formazione in aula od a distanza, all’erogazione di corsi Web attraverso la predisposizione di WBT, attraverso aule virtuali, piattaforme di e-learning, ecc..
L’Amministratore potrà dunque richiedere la realizzazione di WBT o un servizio di piattaforma per l’erogazione dei corsi stessi.
4.4 Garanzia
Ogni prodotto sw realizzato/modificato deve essere pienamente rispondente ai requisiti funzionali espressi, alle normative vigenti (vedi accessibilità), ai requisiti non funzionali (sicurezza, usabilità, prestazionalità, manutenibilità, ecc.) nonché agli standard, linee guida e miglior prassi disponibile per lo sviluppo software.
Ne discende che eventuali anomalie, difettosità residua non intercettata durante le fasi di test del fornitore e di collaudo dell’ente, riscontrabili sulle funzionalità realizzate e/o modificate durante l’intera fornitura devono essere rimosse, come parte integrante dei servizi che li hanno realizzati, a totale carico del Fornitore. Pertanto, l’impresa dovrà garantire la tempestiva rimozione dei difetti del software nuovo e/o modificato nonché la correzione e/o il ripristino delle basi dati deteriorate come ripercussione dei difetti nei tempi indicati dall’indicatore TROI (o come indicato dall’Amministrazione in Appalto Specifico o migliorato dal Fornitore in Offerta Tecnica di AS).
Si precisa che gli interventi correttivi dovranno riguardare anche la documentazione a corredo.
Per tutto il software rilasciato il Fornitore deve produrre/aggiornare la relativa documentazione. La documentazione deve rispondere a requisiti di accuratezza, comprensibilità e più in generale usabilità.
Pertanto, deve essere garantita, come parte integrante dei servizi realizzativi, la correzione gratuita dei difetti riguardanti:
• gli oggetti software nuovi e/o modificati;
• le basi dati / flussi dati deteriorati come ripercussione dei difetti;
• la documentazione a corredo al software. La garanzia opera:
• per tutto il periodo di erogazione dei servizi relativamente a tutto il sw collaudato (o forma equivalente) in tale periodo (esempio: nel caso di un AS di 60 mesi di cui gli ultimi 12 di garanzia sul sw dell’ultimo anno, tutto il software realizzato/modificato dal fornitore dal 1° al 48° mese, sarà in garanzia per tutti i 48 mesi);
• per una durata massima di ulteriori dodici mesi successivi per tutti i prodotti collaudati (o forma equivalente) nel corso dei dodici mesi precedenti; tale durata viene fissata dall’Amministrazione in funzione della durata dell’AS con un criterio di ragionevolezza e proporzionalità rispetto all’ammontare degli sviluppi effettuati, alla qualità del software ed alla loro criticità (nell’esempio sopra riportato, il software rilasciato/modificato dal 37° al 48° mese sarà in garanzia per 12 mesi, dal 49° al 60°mese).
Le suddette garanzie devono essere prestate in proprio dall’Impresa anche per il fatto del terzo, intendendo l’Amministrazione restare estranea ai rapporti tra l’impresa e le ditte fornitrici.
In Appalto Specifico l’Amministrazione potrà motivatamente ridurre questi requisiti in funzione della tipologia, della dimensione e della durata dei servizi da erogare nonché della propria organizzazione e delle conseguenti modalità di erogazione richieste.
5 REQUISITI E COMPETENZE GENERALI PER L’EROGAZIONE DEI SERVIZI
5.1 Requisiti Minimi dei servizi realizzativi
Tutti i prodotti software sviluppati o modificati dal fornitore dovranno soddisfare i seguenti requisiti minimi. Quindi la progettazione e scrittura del codice dovrà incorporare i requisiti minimi di accessibilità e le caratteristiche minime di qualità del software, in modo nativo. Le risorse professionali, con il supporto di metodologie e di strumenti, devono essere addestrati allo sviluppo di software di qualità.
L’Amministrazione declinerà, preciserà ed integrerà tali requisiti in funzione delle caratteristiche e delle modalità organizzative dell’AS, fermo restando che questi requisiti non comportano oneri aggiuntivi per l’Amministrazione. Trattandosi di enti pubblici, con finalità di pubblico servizio, il fornitore deve rispettare la normativa sull’accessibilità da parte dei soggetti disabili, pena la nullità del contratto.
• COMPATIBILITA’
Il software realizzato/modificato dovrà essere compatibile con il release/livello effettivo degli ambienti di collaudo/esercizio attivi al momento in cui il software sarà utilizzato. E’ pertanto obbligo del Fornitore predisporre e mantenere costantemente adeguati i propri ambienti di sviluppo e testing alle configurazioni degli ambienti dell’Amministrazione, per minimizzare eventuali criticità derivanti da disallineamenti tra gli ambienti del Fornitore e quelli target.
Ciò comporta la verifica da parte del Fornitore degli effettivi release e dell’eventuale piano di evoluzione degli ambienti.
• DOCUMENTAZIONE DEL SOFTWARE (PROGETTUALE, BASI DATI, GESTIONE APPLICATIVA)
Il software realizzato/modificato dovrà essere documentato secondo gli standard dell’Amministrazione o in assenza secondo gli standard e best practices offerti dal fornitore. Il livello di documentazione, in ogni caso, deve permettere l’efficiente ed efficace presa in carico del progetto e/o dei sistemi in esercizio da parte dell’Amministrazione o da terzi da essa delegati nonché la rapida e affidabile diagnosi dei malfunzionamenti rilevati sul software.
Le modalità dipenderanno dal grado di criticità del software, dal modello di produzione adottato, dalle finalità e tipologie del sw stesso e degli utenti.
Non può essere rilasciato software non sufficientemente documentato. La qualità della documentazione dovrà essere dichiarata dal fornitore sia in fase di attivazione dell’obiettivo e/o del servizio sia in fase di rilascio in collaudo.
• QUALITA’ DEL SOFTWARE
Il Fornitore deve assicurare la qualità del software rilasciato o modificato in aderenza alla ISO IEC 25010 e successivi aggiornamenti, con particolare attenzione alle soglie ottimali (in funzione delle caratteristiche tecniche) richieste dagli specifici interventi previsti in Appalto Specifico.
Il Fornitore dovrà certificare l’esecuzione delle misurazioni ed il superamento delle soglie di qualità per le caratteristiche/sottocaratteristiche previste dal modello ISO 25010, partendo dalle misurazioni CISQ delle caratteristiche di qualità ed assicurando l’assenza di non conformità.
In caso di manutenzione evolutiva, il fornitore dovrà effettuare un assessment qualitativo del software e si impegna a migliorare il livello di qualità di partenza. In caso di peggioramento anche solo di una sola misurazione del software, il software non sarà accettabile.
PREDISPOSIZIONE e SUPPORTO in AMBIENTE DI COLLAUDO
Per ciascun progetto/obiettivo realizzativo di sw il Fornitore, senza oneri aggiuntivi, dovrà supportare le strutture tecniche dell’Amministrazione nella predisposizione dell’ambiente di collaudo (definizione e
caricamento della base dati, installazione del software applicativo, personalizzazione del software di base, ecc.) e alla predisposizione degli script per il testing proceduralizzato o automatico secondo quanto richiesto in AS.
Tale attività deve essere espressamente prevista nel Piano di Lavoro dell’obiettivo.
La fase di realizzazione (o equivalente) si intende chiusa solo quando le attività di verifica hanno dato esito positivo dei suddetti test.
L’obiettivo realizzativo comprende il supporto alle attività di collaudo.
In particolare il fornitore dovrà garantire la presenza on site nei tempi che saranno indicati in AS (in genere entro 1 giorno lavorativo) per garantire il passaggio di conoscenza sulle funzionalità rilasciate, il supporto all’esecuzione dei test proceduralizzati od automatici ed altre attività in funzione della specificità dell’obiettivo e richieste dall’Amministrazione per ottimizzare il collaudo ed il successivo rilascio in esercizio.
• SUPPORTO ALLA CONSEGNA IN GESTIONE
L’obiettivo realizzativo comprende il supporto alla consegna in gestione del software realizzato al fine di assicurare un appropriato passaggio di consegne ai Servizi di Gestione.
• SUPPORTO PASSAGGIO IN ESERCIZIO
L’obiettivo realizzativo comprende il supporto ai gruppi di gestione e alle strutture dell’Amministrazione finalizzato alla predisposizione dell’ambiente di esercizio. Si precisa che la messa in esercizio potrà avvenire anche in un momento differito rispetto all’avvenuto collaudo.
• SUPPORTO SISTEMISTICO
L’obiettivo realizzativo comprende il supporto sistemistico al fine di assicurare, in particolare:
- l’assistenza ad analisti e programmatori per lo sviluppo e la manutenzione;
- l’ottimizzazione delle prestazioni dei programmi;
- il tuning degli accessi alle basi dati;
- la predisposizione degli ambienti di test, delle banche dati di prova, del mascheramento dei dati, ecc..
• VERIFICA E VALIDAZIONE SOFTWARE
Tutto il software rilasciato o modificato deve essere stato sottoposto a processi di verifica e validazione al fine di assicurare la minor difettosità raggiungibile e ridurre anomalie e malfunzionamenti in esercizio.
Il Fornitore è tenuto alla progettazione dei test (test di modulo, di funzione, di integrazione o di sistema, di prestazione, di sicurezza applicativa, di compatibilità, di usabilità, di accessibilità, di stress o di carico del sistema, ecc.), al monitoraggio del grado di copertura degli stessi, alla verifica della completezza e della rispondenza dei test ai requisiti, al controllo- esecuzione e memorizzare i risultati: dovrà fornire tutti i report per le necessarie verifiche dell’Amministrazione e consentire il riutilizzo dei test in successivi contesti.
A tal fine Il Fornitore dovrà disporre di un prodotto di test management con cui gestire la fase di test relativa ai servizi oggetto della presente fornitura (test proceduralizzato).
Il prodotto dovrà garantire la possibilità di integrarsi completamente con il prodotto di test management eventualmente adottato dall’Amministrazione e dichiarato in AS.
Per ogni Obiettivo realizzativo la predisposizione e l’esecuzione di un piano di test esaustivo sotto tutti gli aspetti funzionali e non funzionali potrà essere richiesta come obbligo contrattuale, senza oneri aggiuntivi.
5.1 Competenze Funzionali, metodologiche, applicative e tecnologiche
I fornitori partecipanti all’AQ devono garantire competenze di natura funzionale, metodologica e tecnologica, tali da poter affrontare le eventuali problematiche e proporre, realizzare e gestire le relative soluzioni nei contesti specifici delle Amministrazioni.
5.1. Competenze funzionali e tematiche
Le competenze funzionali e tematiche che il fornitore deve rendere disponibili per i servizi oggetto della presente iniziativa sono, a titolo indicativo e non esaustivo:
• Conoscenza approfondita del contesto e delle tematiche inerenti la PA;
• Conoscenza delle normative di riferimento della PA (Codice degli appalti pubblici, Codice dell’Amministrazione Digitale (CAD), ecc);
• Conoscenza degli ambienti e degli strumenti per la gestione dei procedimenti amministrativi nella PA;
• Capacità di comprendere, analizzare e rappresentare le esigenze ed i requisiti funzionali e di business delle Amministrazioni della PA;
• Conoscenza delle tecniche di analisi organizzativa, business process re-engineering (di seguito BPR), demand management e change management;
• Conoscenza approfondita delle tecniche di assessment dei sistemi informativi, dal punto di vista funzionale, architetturale, qualitativo;
• Capacità di dimensionare il budget, il perimetro e l’ambito di iniziative progettuali informatiche di piccole, medie e grandi dimensioni;
• Conoscenza approfondita delle tecniche di project management e risk management.
5.2. Competenze metodologiche
Al fornitore si richiedono competenze in merito a metodologie, tecniche, strumenti, standard e linee guida relativi alle modalità di erogazione di tutti i servizi oggetto della fornitura, come descritto in dettaglio nel seguito.
Le competenze metodologiche offerte e proposte dal fornitore devono essere coerenti e riconducibili alle principali metodologie, quali a titolo indicativo e non esaustivo:
• ISO 9000 che raggruppa le norme che definiscono i requisiti per la realizzazione, in un organizzazione, di un sistema di gestione di qualità, al fine di condurre i processi aziendali, migliorare l’efficacia e l’efficienza nella realizzazione del prodotto e nell’erogazione del servizio, ottenere ed incrementare la soddisfazione del cliente;
• ISO 25010, e successive, il modello di qualità del software e dei dati ed indicatori, linee guida per la relativa misurazione;
• Approcci metodologici adottabili per il project management che includono gli approcci agili, interattivi, incrementali e basati sulla successione di fasi predefinite (quali ad esempio: PMI, PRINCE2, IPMA COBIT, CMMI, ITIL, RUP, Agile, Devops);
• Approccio metodologico per la realizzazione e gestione di sistemi informatici complessi ed integrati;
• Approccio metodologico per l’analisi, il disegno e la programmazione ad oggetti (OOA) e per servizi (SOA)
• Metodologie specifiche e verticali del prodotto e/o piattaforma e/o soluzione tecnologica e/o pacchetto applicativo;
• IFPUG: metodo di misurazione della dimensione funzionale del software.
5.3. Competenze applicative
Le competenze informatiche hanno una duplice valenza che combina la conoscenza degli ambiti funzionali, delle aree e delle tematiche delle Amministrazioni, con la capacità tecnica di realizzare ed implementare le soluzioni applicative di mercato o verticali o ad hoc secondo gli standard di personalizzazione e sviluppo e secondo quanto indicato dalla Amministrazione contraente.
Le principali competenze informatiche che il fornitore deve mettere in campo sono, a titolo indicativo e non esaustivo:
• individuare e rappresentare le soluzioni applicative maggiormente rispondenti alle esigenze ed ai requisiti della PA;
• disegnare e progettare l’architettura funzionale, applicativa e tecnologica;
• Competenza sull’intero ciclo di vita del software, dal disegno, alla realizzazione, test, integrazione, diffusione e conduzione in esercizio;
• Competenza specifica delle tecniche di parametrizzazione di sistemi;
• effettuare manutenzione evolutiva, correttiva, adeguativa su sistemi;
• Competenza specifica delle tecniche di realizzazione di procedure e programmi utilizzando il linguaggio di programmazione nativo dell’applicazione indicata e valutando correttamente gli impatti sui programmi già in uso;
• Conoscenza dei linguaggi ed ambienti di programmazione;
• Competenze specifiche sugli strumenti di test management;
• Capacità di formare gli utenti al corretto utilizzo dei sistemi.
5.4. Competenze tecnologiche
Le principali competenze tecnologiche richieste al fornitore sono di seguito elencate, a titolo indicativo e non esaustivo:
• Conoscenza avanzata dei principali sistemi operativi;
• Conoscenza di Web server;
• Conoscenza avanzata di tecniche di progettazione e di dimensionamento dei DBMS;
• Conoscenza avanzata di DBMS relazionali e non;
• Conoscenza dei sistemi operativi “mobile”;
• Conoscenza dei sistemi di Identity and access management system;
• Conoscenza dei protocolli di Comunicazione e navigatori Web;
• Conoscenza dei sistemi di CMS e ECM;
• Conoscenza dei sistemi Documentali;
• Conoscenza dei sistemi di Business Intelligence e processi ETL;
• Conoscenza dei Sistemi di CRM;
• Conoscenza dei motori di ricerca standard e semantici;
• Conoscenza dei prodotti per analisi e statistiche;
• Conoscenza delle tecnologie di Comunicazione unificata e collaborazione on-premise e in cloud;
• Tecnologie di virtualizzazione;
• Piattaforme ed architetture Big Data.
Ogni Appalto Specifico indicherà le specifiche tecnologie utilizzate o da utilizzare e contestualizzerà le competenze, conoscenze, certificazioni, ecc.., delle figure professionali necessarie all’erogazione dei servizi rispetto al modello minimo generale esposto nell’appendice 1 “profili professionali”.
6 METRICHE E DIMENSIONAMENTO DELLA FORNITURA
Nell'ambito dei servizi applicativi in oggetto, il dimensionamento di ciascun elemento della fornitura è necessariamente legato al volume delle attività e/o al volume del software realizzato.
Tale dimensionamento può essere riconosciuto solo se il servizio prestato e/o il software rilasciato soddisfano tutti i requisiti espressi dall'Amministrazione, fornendo funzionalità di valore per l’utenza, nei modi e tempi da essa indicati e rispettando tutti i livelli di qualità, di servizio e di obiettivo richiesti, intendendosi che gli standard e le best practices internazionali disponibili costituiscano elementi imprescindibili dell'esecuzione a regola d'arte.
Rispetto a quanto sopra premesso, le metriche considerate ai fini della presente acquisizione sono le seguenti:
• per i servizi di sviluppo e manutenzione evolutiva di software: i giorni persona e i Punti Funzione IFPUG (attualmente release 4.3) – laddove l’Amministrazione valuti ottimale utilizzare la metrica dei Function Point”.
• Per la parametrizzazione/personalizzazione, tutti i servizi realizzativi, i servizi di gestione del portafoglio applicativo, per servizi tecnico-specialistici e di supporto: i giorni persona e, per iniziative/obiettivi “a corpo” anche ulteriori metriche di risultato (ticket di gestione, pesi per fasi, canoni, ecc...).
• Per la manutenzione correttiva: i giorni persona, il canone per singolo Punto Funzione affidato al servizio, ed ulteriori metriche di risultato.
In particolare, le metriche di base per il dimensionamento della fornitura sono:
a) Xxxxxx persona (8 ore lavorative) per figura professionale;
b) Punto Funzione per un ciclo completo di sviluppo nelle seguenti tipologie:
I. ADD ciclo completo misurato come da metodologia utilizzata: valutato al 100% della tariffa FPADD_ciclo completo
offerta in 2*fase:
II. CHG ciclo completo misurato come da metodologia utilizzata: valutato al 50% della tariffa FP FPADD_ciclo completo
offerta
III. DEL ciclo completo misurato come da metodologia utilizzata, cancellato e non sostituito sarà convenzionalmente valutato al 10% della tariffa FP FPADD_ciclo completo offerta;
IV. DEL ciclo completo misurato come da metodologia utilizzata, cancellato e sostituito con un corrispondente elemento nuovo, non verrà computato e dunque sarà valutato pari a zero.
c) Punto Funzione per un ciclo realizzativo nelle seguenti tipologie:
I. ADDciclo realizzativo misurato come da metodologia utilizzata: valutato al 50% della tariffa FPFPADD_ciclo completo
offerta
II. CHG ciclo realizzativo misurato come da metodologia utilizzata: valutato al 50% della tariffa FPADD_ciclo realizzativo
calcolata come indicati al punto c.I);
III. DEL ciclo realizzativo misurato come da metodologia utilizzata, cancellato e non sostituito sarà valutato al 10% della tariffa FPADD_ciclo realizzativo calcolata come indicato al punto c.I)
d) Canone di manutenzione correttiva per singolo punto funzione gestito (unico, non in garanzia, difettabile).
Le Amministrazioni che dispongono di metodologie standardizzate e linee guida consolidate per una più precisa e controllata determinazione dell’effort possono modificare le regole cautelative sopra esposte.
Rispetto alle metriche di risultato, si precisa che sono fondamentalmente basate sull’effort statisticamente/storicamente rilevato nel tempo per le attività unitarie e specifiche richieste e su fattori di ottimizzazione dei processi sottostanti.
A livello di Accordo Quadro vengono, pertanto, identificate le sole metriche di base e i fattori che ne determinano la misura, lasciando all'Amministrazione la facoltà di declinare in AS tali fattori, anche eventualmente con riduzione del livello di servizio, laddove ritenuto necessario, rispetto ai livelli considerati in AQ.
Per tutte le attività a corpo in gg/pp: l’Amministrazione potrà definire l’effort stimato (ed offerto) per la metrica di risultato scelta, secondo il seguente modello:
- Mix medio di riferimento del team per l’attività richiesta (ticket, canone, ecc.)
- Nr di giorni o frazione riferito al mix medio necessari per il completamento di una unità di lavoro. L’Amministrazione utilizzerà la metrica che meglio risponde alle proprie esigenze, al proprio know-how interno (in primis, certificazioni Function Point), alla tipologia di progetti che affiderà in AS ed alla propria organizzazione e modalità di affidamento delle attività (es. attività svolte all’interno di gruppi misti o attività con responsabilità di risultato al fornitore).
Ciascuna Amministrazione dovrà definire il livello di qualità richiesto – migliorativo e contestualizzato rispetto agli standard internazionali e le best practices, specificando nell’appendice qualità dell’AS gli obiettivi di qualità (per AS pluriennali tali obiettivi verranno declinati nei singoli piani di qualità dei diversi progetti).
Pertanto, l’Amministrazione integrerà gli indicatori di qualità e/o definirà soglie puntuali per progetto/attività; espliciterà i vincoli di processo (punti di controllo intermedi, verifica di conformità, livello ottimale di documentazione del software, ecc,, ), i requisiti metodologici (agile, scrum, devops, ec..) ed il rispetto dei propri standard interni .
Attività previste a corpo od a consumo:
I servizi/sotto servizi/attività/progetto sopra definiti possono essere acquisiti sia in modalità a corpo sia a consumo.
Nella modalità a corpo: la responsabilità del risultato è affidata al fornitore, il quale organizza le proprie risorse professionali, tecniche e metodologiche per soddisfare le richieste: tipico esempio è l’affidamento di un obiettivo di sviluppo in cui l’Amministrazione fornisce gli elementi generali della “soluzione TO BE” in termini di macro esigenze da realizzare/modificare, utenza coinvolta, contesto tecnologico ed applicativo di partenza e vincoli di spesa/tecnologia (il contesto AS IS, nuovi adempimenti legati a leggi e normative, ecc..), il fornitore declina i requisiti funzionali e non funzionali oppure l’analisi d’impatto, disegna la soluzione e definisce tutti gli elementi del piano di lavoro, il dettaglio dei prodotti, tutti i costi in gg/pp o PF , fornendo tutti gli elementi per oggettivare la proposta ed i relativi costi. Con l’approvazione del piano, il fornitore ne è responsabile, e, pertanto, non potrà richiedere maggiori costi a fronte di ritardi nella consegna (errata valutazione dei tempi o errata allocazione delle risorse o incompetenza delle risorse, difettosità eccessiva del sw realizzato, o mancata comprensione dei requisiti utenti, ec..), o per rimediare ad un livello di qualità insufficiente, o rimediare a buchi di analisi o insufficiente attività di testing, ec..
La modalità a consumo invece presuppone una responsabilità limitata alla competenza tecnica-professionale ed alla risoluzione di task con ampiezza contenuta e dipendente anche da risorse dell’Amministrazione: a titolo di esempio l’affidamento di un obiettivo di sviluppo in team misti con Amministrazione in cui le modalità, i tempi, le soluzioni sono controllate prevalentemente dall’Amministrazione. In questo caso, la responsabilità del fornitore è limitata alle attività di volta in volta affidate, siano sprint o funzioni o oggetti più limitati, ma la soluzione globale viene guidata dall’amministrazione. In questo caso, il fornitore non può essere responsabile della soluzione totale, ma i fattori rilevanti sono l’adeguatezza ai profili professionali richiesti, la competenza tecnica e funzionale, il rispetto degli orari di lavoro e delle produttività richieste.
Nel caso dei servizi di gestione l’Amministrazione può richiedere il servizio a corpo fissando le unità di lavoro e le regole di determinazione del corrispettivo: ad es. l’Amministrazione può determinare – su base storica e fornendo evidenza in fase di AS, che ogni ticket di assistenza (od i ticket giornalieri medi) richiede un effort medio calcolato sulla base di una tariffa media ponderata definita e le numero/frazione di giorni necessari per completare una unità di lavoro.
Il controllo del servizio sarà sull’efficacia ed efficienza di risoluzione dei ticket e non sul controllo delle risorse.
Tipicamente e soprattutto per i grandi contratti, i servizi di gestione sono organizzati in team misti con l’Amministrazione, presso l’Amministrazione stessa che può indicare priorità, richiedere modifiche sulla composizione del team in funzione delle attività, dell’evoluzione delle applicazioni, delle scadenze amministrative e dunque si applica la metrica a consumo, misurando le ore/giorni effettivamente erogate per lo specifico profilo richiesto.
Anche in questo caso, il fornitore non può essere responsabile dell’organizzazione globale delle attività, ma i fattori rilevanti sono l’adeguatezza ai profili professionali richiesti, la competenza tecnica e funzionale, il rispetto degli orari di lavoro e delle produttività richieste.
6.1 Risorse Professionali e Gruppi di lavoro
L’appendice 1 “Profili professionali” fornisce la descrizione per ciascun profilo professionale associato ai servizi previsti nella fornitura di servizi applicativi delle capacità tecniche richieste (dal titolo di studio, alle certificazioni, alle competenze specifiche, alle esperienze lavorative e conoscenze per poter svolgere il proprio ruolo).
In AS l’Amministrazione declinando il contesto applicativo e tecnologico ed i servizi richiesti, procederà con:
1) la definizione della propria appendice profili professionali attraverso specializzazione dei profili sulle proprie esigenze, indicando le certificazioni richieste sia tra quelle obbligatorie sia prevedendo criteri tecnici migliorativi. L’amministrazione potrà aggiungere profili specifici aggiuntivi nei servizi accessori;
2) la definizione della composizione di ciascun servizio: i mix richiesti, le modalità di erogazione e di misurazione (gg/pp vs Tariffe Medie Ponderate, corpo vs consumo, cicli interi vs realizzativi).
Rispetto a questi profili professionali, l’Impresa offrirà le rispettive tariffe unitarie per singolo giorno persona (da intendersi comprensive della prestazione del servizio in orario esteso e della reperibilità). Queste tariffe unitarie per giorno persona si riferiscono ad 8 ore lavorative; pertanto, laddove la prestazione sia inferiore a 8 (otto) ore, la prestazione stessa sarà retribuita in modo proporzionale.
Inoltre, la tariffa si riferisce all’esecuzione dei servizi a perfetta regola d’arte e nel pieno adempimento delle modalità e delle prescrizioni contrattuali.
6.2 Misurazione dello sviluppo software in Punti Funzione
Le Amministrazioni, con competenze certificate e con strumenti di verifica e controllo della dimensione funzionale, laddove ritengano il metodo Function Point (IFPUG 4.3) idoneo a tracciare l’intero effort realizzativo –sulla base delle caratteristiche specifiche degli sviluppi da realizzare - possono prevedere di dimensionare lo sviluppo applicativo richiesto utilizzando tale metodo.
Sia in fase di AQ sia in fase di AS, i concorrenti dovranno offrire una tariffa unitaria che contempli pienamente i requisiti minimi richiesti nella documentazione di gara.
Le attività erogate in Punti Funzioni devono sempre garantire l’impiego di risorse pienamente rispondenti ai profili richiesti per le attività di sviluppo e per le attività che si devono svolgere presso l’Amministrazione (incontri con l’utenza, incontri con l’Amministrazione o personale da essa delegato, attività congiunte, supporto al collaudo, ecc..) devono garantire la presenza presso l’Amministrazione del Responsabile dell’obiettivo e della figura “guida” per la fase di riferimento: es. nella fase di requisiti e/o analisi funzionale: l’analista funzionale e/o l’architetto applicativo e/o lo specialista di tecnologia/prodotto, in caso di test/metriche qualità del software negativi/incompleti/insufficienti, il test specialist con l’Analista funzionale o lo specialista di tecnologia/prodotto, e via dicendo.
In relazione all’autonomia realizzativa del fornitore, ogni rilascio deve essere corredato da una certificazione attestante la qualità intrinseca e estrinseca del sw rilasciato, il raggiungimento del massimo livello di manutenibilità raggiungibile.
il Fornitore è tenuto a fornire tutti gli elementi di misurazione necessari a mantenere aggiornata la baseline ed il relativo effort progettuale sullo strumento per l’inventario funzionale dell’Amministrazione.
Nella seguente tabella si riportano i momenti generalmente previsti in cui deve essere effettuata una misura, stimata o effettiva, dell’effort realizzativo degli obiettivi e gli scostamenti massimi in eccesso consentiti tra le diverse fasi.
Per ogni misurazione viene indicata la fase del ciclo completo in cui essa deve avvenire, precisando che laddove venga utilizzato un ciclo di vita diverso dovrà essere utilizzata la fase equivalente.
Misura | Fase | Scostamento massimo |
Stima Iniziale (solo per nuovi progetti) Conteggio Iniziale (MEV) | Definizione del progetto – Dettaglio Funzionalità | In genere effettuata dall’Amministrazione (sempre nei cicli realizzativi) |
Conteggio di Revisione | Analisi (o equivalente) | 15% per sviluppi nuovi Ridotto al 50% per MEV |
Conteggio Consuntivo | Realizzazione (o equivalente) | 0% |
Per i cicli di vita per cui non è previsto il Conteggio di Revisione, lo scostamento massimo del Conteggio Consuntivo potrà essere del 15% rispetto alla stima iniziale nel caso di sviluppi nuovi ed il 50% in caso di Manutenzioni evolutive.
Il dimensionamento dell’obiettivo, a requisiti invariati, può subire delle variazioni al termine della fase di analisi (o equivalente). Tali variazioni, opportunamente giustificate dal Fornitore e approvate dall’Amministrazione, ai fini della fatturazione, devono essere contenute nello scostamento massimo consentito di cui alla tabella precedente. In ogni caso, lo scostamento del conteggio rispetto alla stima iniziale deve essere tenuto sotto controllo dal Fornitore e comunicato alla Amministrazione con la massima tempestività e comunque in tempo utile per intervenire sugli scostamenti.
Si precisa che al termine della fase di Realizzazione o equivalente, dovrà essere effettuata la consuntivazione dell’obiettivo, contestualmente al conteggio dei Punti Funzione di baseline.
Resta inteso che nel caso in cui i conteggi successivi risultino inferiori alla misurazione precedente, tale dimensione aggiornata sostituisce ai fini della fatturazione la misurazione precedente. Dunque, in nessun caso potranno essere addebitati all’Amministrazione oneri per Punti Funzione non realizzati anche se le stime precedenti erano state accettate dall’Amministrazione.
Il dimensionamento in Punti Funzione degli Obiettivi dovrà essere effettuato secondo le modalità di conteggio IFPUG, 4.3 e successive versioni e nel rispetto degli standard integrativi della Amministrazione.
6.3 Misurazione dei servizi in giorni persona
Laddove La metrica dei Punti Funzione non risultasse idonea a tracciare l'effort/il risultato dell'attività, l'Amministrazione potrà utilizzare la metrica dei giorni persona.
Tipicamente rientrano in questa fattispecie gli obiettivi/progetti di personalizzazione e parametrizzazione di soluzioni commerciali (tipicamente gli ERP, piattaforme documentali, ecc.) o di software open source o di software in riuso, di manutenzione adeguativa, la realizzazione di APP, sviluppi in ambito mobile, Internet of Thing, interfacce di cooperazione applicativa, microservizi, realizzazioni in modalità agile, ecc.
Quando l’Amministrazione svolge attività all’interno del ciclo di sviluppo (rispettivamente completo o realizzativo) o lo sviluppo si basa su pacchetto e/o sw in riuso non può essere utilizzata la metrica dei Punti Funzioni.
In generale, l’Amministrazione sceglierà la metrica (anche metriche di risultato derivanti dalle proprie misurazioni su progetti/attività interne ed esterne) maggiormente rispondente alle proprie tecniche e capacità di controllo dei
progetti al fine di garantire puntualmente per ogni attività il miglior investimento delle proprie risorse economiche, la remunerazione dell’impegno lavorativo necessario ed erogato (effort) riscontrabile e misurabile.
Ciò premesso, per ciascun servizio è stato stimato il team medio e l’effort medio necessario.
Tale mix non è vincolante per le Amministrazioni, rappresentando un impiego stimato globale per tutti i lotti. L’Amministrazione potrà rivedere il team od il mix con tutte le figure professionali previste.
In Appalto Specifico, le Amministrazioni dovranno:
1) definire le modalità di affidamento del ciclo di vita del software;
2) definire il mix necessario per il progetto richiesto, nel caso di un unico sviluppo (in questo caso definire se si tratta di remunerazione a corpo od a consumo);
3) definire il mix medio necessario per l’erogazione di più attività realizzative applicabili alla fornitura che meglio risponderanno alle esigenze rappresentate in AS: in questo caso con l’attivazione di ciascun singolo obiettivo l’Amministrazione potrà richiedere lo specifico mix all’interno di quello generale (la definizione a corpo od a consumo sarà possibile in questo caso solo in fase di attivazione dell’obiettivo, costituendo in fase di AS solo un massimale di impegno).
A livello di AQ i mix medi stimati sono:
Obiettivi di Progettazione e Sviluppo | Gestionale | Conoscitivi | Web |
Responsabile di progetto applicativo | 5% | 5% | 5% |
Architetto applicativo | 5% | ||
Visual Web Designer | 8% | ||
Data Base Administrator | 10% | ||
Analista Funzionale | 25% | 12% | 15% |
Progettista DW/BI | 18% | ||
Grafico Web | 8% | ||
Test Specialist | 5% | 5% | 5% |
Analista Programmatore | 28% | 20% | 25% |
Programmatore | 27% | 25% | 30% |
Specialista di prodotto tecnologia | 5% | 5% | 4% |
In caso di sviluppi ed in particolare manutenzione evolutiva su applicazioni già esistenti l’architettura del sistema, le scelte di prodotti/tecnologia, il disegno della basi dati, ecc.., sono già state effettuate: in genere non occorrono dunque, od in % inferiore, le figure di architetto applicativo, database administrator, specialista di prodotto/tecnologia.
Obiettivi di Personalizzazione e Parametrizzazione | Ciclo intero |
Responsabile di progetto applicativo | 5% |
Analista Funzionale | 15% |
Specialista di pacchetto | 20% |
Test Specialist | 5% |
Analista Programmatore | 23% |
Programmatore | 30% |
Specialista di prodotto tecnologia | 2% |
In caso di manutenzione adeguativa l’analisi funzionale è sostituita dall’analisi d’impatto guidata dallo specialista della tecnologia o del prodotto in evoluzione/sostituzione e sulla base degli strumenti automatici a supporto dell’adeguamento. Particolarmente importanti saranno i test automatici, in quanto tipicamente le funzionalità utente sono invariate. L’Amministrazione può svolgere le fasi alte del ciclo stilando le specifiche di intervento (o analogo deliverable) per l’attivazione di obiettivi in ciclo realizzativo.
Obiettivi di Manutenzione Adeguativa | Ciclo intero |
Responsabile di progetto applicativo | 2% |
Analista Funzionale | 5% |
Analista Programmatore | 28% |
Specialista di Tecnologia/Prodotto | 15% |
Programmatore | 42% |
Test Specialist | 8% |
6.3.1 Servizi di gestione del portafoglio applicativo
Generalmente nei grandi contratti (Lotti 1 e 2) e nei contratti comunque di affidamento di grandi sistemi informativi, le Amministrazioni richiedono un team di risorse con diversi livelli di seniority e che operano in gruppi misti con l’Amministrazione stessa che ne gestisce le priorità e assicura la competenza amministrativa, tematica e funzionale curando inoltre la gestione del rapporto con l’utenza.
In tal caso le indicazioni necessarie per la formazione del piano di lavoro, la congruità del mix di competenze, il monitoraggio della qualità del servizio svolto e della presenza delle risorse è effettuato dall’Amministrazione stessa ed il servizio viene erogato a consumo.
La composizione del gruppo viene richiesta attraverso un massimale di impegno di risorse su un arco temporale anche pluriennale, da contestualizzare con la pianificazione periodica in fase di erogazione in quanto le attività sono difficilmente pianificabili a priori ed a distanza di tempo.
Amministrazioni che sono dotate di strumenti di registrazione, misurazione e controllo delle richieste di intervento e che dispongono degli effort di risoluzione, sono in grado di strutturare il servizio anche a corpo, esponendo nella richiesta d’offerta tutte le caratteristiche del servizio (nr. ticket per tipologia, per effort stimato, picchi di attività, ecc..). il valore a base d’asta per ciascuna tipologia di ticket o fascia dimensionale di ticket o canone come previsto per le metriche di risultato. Gli indicatori di qualità e tutte le condizioni di accettazione dell’attività dovranno essere contestualizzate sull’unità di lavoro prescelta unitamente ad indicatori di misurazione della soddisfazione dell’utenza, del rispetto dei tempi e dei contenuti.
A livello di AQ si dimensiona il servizio sulla base dei profili professionali che normalmente ricorrono in questo tipo di forniture per permettere alle Amministrazioni di individuare in AS il team meglio rispondente alle proprie esigenze ed alla propria organizzazione e permetterle di costruire eventuali metriche derivate.
Pertanto i mix utilizzati per la costruzione dell’offerta economica rappresentano un insieme piuttosto ampio per poter ricomprendere in una visione globale le diverse e puntuali necessità che verranno espresse in AS.
Gestione Applicativi e basi dati:
Responsabile di progetto applicativo | 2,00% |
Specialista di prodotto/tecnologia | 5,00% |
Analista Funzionale | 5,00% |
Analista Programmatore | 40,00% |
Programmatore | 20,00% |
Operatore Data Entry | 15,00% |
Sistemista | 8,00% |
Data Base Administrator | 5,00% |
Gestione dei Contenuti di Xxxx, portali e canali Web:
Content Manager | 10,00% |
Visual Web Designer | 20,00% |
Analista Programmatore | 25,00% |
Operatore di Publishing | 30,00% |
Operatore Multimediale | 15,00% |
Servizio di manutenzione correttiva
In funzione delle caratteristiche dell’AS, le attività di manutenzione correttiva possono essere previste all’interno di un servizio già definito, ad es. nel servizio di gestione del portafoglio oppure anche in un team di sviluppo misto con l’Amministrazione.
Qualora la manutenzione correttiva abbia un peso significativo e richieda risorse dedicate tipicamente l’Amministrazione, dopo aver definito le funzioni o la dimensione del sw “difettabile”, ovvero software proprietario fuori garanzia con difettosità residua, procede con la scelta della metrica più congrua ed economica tra:
- Canone periodico per PF “unico” pregresso e difettabile;
- Gg/pp a consumo per intervento correttivo
- Tariffe derivate quali a titolo di esempio: tariffa media ponderata per intervento correttivo o per dimensione in Loc (od altra metrica utilizzata dall’Amministrazioni).
Generalmente nei grandi contratti (Lotti 1 e 2) e nei contratti comunque di affidamento di grandi sistemi informativi, le Amministrazioni affidano in manutenzione correttiva tutto il software gestionale “difettabile” ed “unico” antecedente all’ingresso del nuovo fornitore.
Trattasi di software stabile, in esercizio mediamente da più di un anno (la garanzia minima) e dunque con difettosità molto bassa e buon livello di documentazione.
Proprio per la bassa difettosità le Amministrazioni valuteranno la convenienza nel prevedere un canone (tipicamente per singolo PF “unico” e difettabile esercito al mese) rispetto ad attivare il servizio ad intervento.
Per l’attivazione del servizio in PF, l’Amministrazione deve disporre di sistemi di inventario funzionale e applicativo, in grado di distinguere le funzionalità legate al software pregresso sottraendo automaticamente le funzionalità riusate, ridondate, relative a sw open source o libero o librerie aperte, API, o di altri sistemi (o per garantire che il volume di software calcolato per il corrispettivo corrisponda al software esercito “unico”, non in garanzia (ovvero non modificato dal fornitore stesso)).
Le metriche base di dimensionamento del servizio previste in AQ sono:
⮚ Punti Funzione affidati al mese (con le caratteristiche sopra indicate).
⮚ Giorno persona: per gli interventi a gg/pp a consumo o TMP a corpo (secondo le successive specifiche dell’Amministrazione in sede di AS):
o in AQ il mix medio considerato è il seguente :
Analista Funzionale | 5,00% |
Analista Programmatore | 30,00% |
Programmatore | 60,00% |
Specialista di Tecnologia/Prodotto | 5,00% |
Come per i servizi dimensionati a gg/pp, l’Amministrazione potrà modificare la composizione o creare ulteriori composizione per tipologia di interventi utilizzando tutte le figure professionali previste dall’AQ.
Nel caso di definizione di misurazione a corpo, l’Amministrazione dovrà indicare l’effort medio stimato (sulla base di dati storici indicati in AS, della tipologia di sw, dell’utilizzo di tool a supporto, ecc..) per ciascuna tipologia di intervento.
6.3.2 Servizi Tecnico - Specialistici
Le attività richieste in questo servizio sono molto varie e verticali.
In AS, l’Amministrazione definirà i deliverable richiesti (studi di fattibilità, gap analysis, …) e le risorse necessarie, indicando le modalità di misurazione e di accettazione dei prodotti (attività a risultato (a corpo) vs consumo vs massimale di risorse da pianificare in erogazione dei servizi definendo di volta in volta, all’attivazione dell’obiettivo le specifiche modalità).
A livello di AQ si sommano i profili professionali generalmente impiegati nelle più diffuse attività considerate in questo insieme. In AS ciascuna Amministrazione individuerà le risorse necessarie, stimandone l’effort ed organizzandole se necessario in più gruppi in funzione delle attività richieste e delle modalità (es. supporto specialistico BI vs supporto specialistico documentale, ecc..).
Naturalmente potrà essere creato un unico gruppo solo in caso di risorse a consumo o massimale di risorse.
Data Scientist | 10% |
System Integrator | 10% |
Architetto Applicativo | 10% |
Specialista di prodotto/tecnologia Senior | 10% |
Specialista di prodotto/tecnologia | 20% |
Specialista di pacchetto | 10% |
Business Intelligent Expert | 10% |
Progettista Data Warehouse/BI | 10% |
Data Base Administrator | 10% |
6.3.3 Servizi di supporto
Le attività richieste in questo servizio sono funzionali e propedeutiche ai servizi applicativi: sono generalmente attivate in modalità progettuale al fine di analizzare la miglior soluzione per gestire il cambiamento ed in particolare la digitalizzazione dei processi e aumentare la fruibilità dei servizi per l’utenza. Obiettivi primari sono l’ottimizzazione dei processi organizzativi, amministrativi ed informatici, mediante la proposta di tecnologie e metodologie che ne migliorino l’efficacia e l’efficienza, garantendone l’economicità sia nella fase realizzativa sia nella gestione ordinaria. Possono inoltre essere attivati task specifici per analizzare soluzioni metodologiche e tecniche al fine di misurare e migliorare l’operatività dei servizi di gestione del portafoglio esistente per ridurre i costi di gestione ed aumentarne, l’efficacia e l’efficienza e la disponibilità del servizio.
In AS, l’Amministrazione definirà gli obiettivi ed i deliverable richiesti (disegno/ridisegno dei processi, piano di change, consolidamento e centralizzazione di processi amministrativi, ecc …) e le risorse necessarie, indicando le modalità di misurazione e di accettazione dei prodotti (attività a risultato (a corpo) vs consumo
Analista della domanda (Demand Manager) | 30,00% |
Consulente esperto di organizzazione e processi (BPRr) | 20,00% |
Analista di organizzazione e processi | 30,00% |
Specialista di tematica | 20,00% |
7 REQUISITI GENERALI PER TUTTI GLI APPALTI SPECIFICI
7.1 Obblighi del fornitore
▪ Per ciascun AS il Fornitore aggiudicatario dovrà garantire l’esecuzione della fornitura a regola d’arte attraverso il pieno rispetto dei requisiti minimi e dei livelli di qualità di servizio a partire dalla data di inizio attività e garantire l’efficacia dei servizi dall’avvio della fornitura.
▪ Il Fornitore deve inoltre garantire che ogni dimensionamento dei servizi sia rispondente all’effettivo effort impiegato ed impiegabile: sopravvalutazioni, conteggi di attività non eseguite o non necessarie od in garanzia determinano un danno erariale e comportano la risoluzione immediata ed in danno dell’AS. Il fornitore dovrà impiegare personale qualificato nel dimensionamento delle attività applicative, porre in essere procedure e meccanismi di controllo per garantire la trasparenza ed l’onestà dell’impresa.
7.2 Attività Propedeutiche all’erogazione dei servizi
In funzione del contenuto del singolo AS ed in base alle caratteristiche del portafoglio applicativo esistente – soprattutto in termini di criticità, l’Amministrazione può richiedere un periodo di presa in carico dei servizi, delle applicazioni, dei sistemi, della documentazioni comprendente anche attività da effettuarsi presso l’Amministrazione (a titolo di es. analisi del sw esistente, acquisizione della documentazione, predisposizione collegamenti agli ambienti, colloqui per verifica corrispondenza delle risorse proposte con i profili professionali e gli skill richiesti, verifiche baseline sw e/o difettosità, installazione strumenti a supporto offerti, affiancamento al fornitore uscente nelle attività di gestione, analisi delle FAQ e dei ticket di assistenza, simulazione di procedure periodiche che non pianificabili nel periodo temporale di affiancamento, ecc..).
Il fornitore dovrà pianificare formalmente nel piano di subentro le attività necessarie, sulla base dei tempi e della disponibilità indicati dall’Amministrazione. Anche nel caso di approvazione del piano di subentro da parte dell’Amministrazione, è responsabilità del fornitore prevedere tutte le attività necessarie, i momenti di controllo e di verifica, l’allocazione delle risorse con la necessaria competenza tecnica e funzionale e quanto necessario per garantire l’erogazione dei servizi della fornitura.
Tutte le spese e gli oneri del fornitore relativi alle attività propedeutiche alla erogazione del servizio oggetto di Appalto Specifico sono da intendersi ricomprese e compensate nel corrispettivo del servizio del relativo Contratto d'appalto.
Le attività di subentro sono generalmente richieste nei contratti grandi (lotti 1 e/o 2) e in tutti i contratti che affidano una pluralità di servizi sia realizzativi sia di gestione su un arco temporale significativo.
Nei casi di AS che si configurano come progetti realizzativi bene identificati, l’attività può essere concentrata da una fase di acquisizione della documentazione di studio di fattibilità e di predisposizione degli ambienti.
In considerazione della variabilità delle attività richieste e della completa dipendenza dai requisiti di II fase, in sede di AQ si sottolinea l’unico fondamentale requisito di disporre di know how tecnologico e applicativo trasversale e tale da poter rispondere efficacemente alle esigenze applicative degli enti del proprio territorio.
Pertanto, l’organizzazione della presa in carico non può essere oggetto di proposte in offerta tecnica di I fase, ma solo, qualora richiesta, in fase di AS.
In nessun caso possono essere contratti i tempi massimi richiesti dall’Amministrazione: che fisserà i tempi necessari sulla base delle proprie esigenze e delle schedulazioni delle proprie attività.
La riduzione dei tempi richiesti dall’Amministrazione comporterà l’esclusione del concorrente dal confronto competitivo.
Di seguito si rappresentano le attività generalmente previste in contratti ad ampia copertura di servizi e con ampio affidamento di responsabilità/autonomia nella gestione dei servizi ai fornitori aggiudicatari:
ATTIVITA’ DI SUBENTRO ED ACQUISIZIONE KNOW HOW
L’Amministrazione può richiedere in AS un periodo strutturato ed organizzato di presa in carico delle applicazioni/sistemi/procedure/processi. A propria tutela l’Amministrazione potrà indicare il periodo ritenuto congruo per lo svolgimento delle attività in funzione della classe di rischio delle applicazioni, della criticità dei servizi richiesti, del peso delle procedure di gestione, delle interfacce con sistemi interni ed esterni, ecc. Indicativamente per i grandi contratti, le Amministrazioni richiedono un periodo di presa in carico di due mesi, in caso di applicazioni gestionali particolarmente critiche anche 3 mesi; l’obbligo di impiegare le risorse che hanno fatto la presa in carico nei team dei servizi richiesti, una percentuale di risorse significativa rispetto ai servizi richiesti.
In nessun caso i fornitori possono ridurre le tempistiche minime richieste dall’Amministrazione.
Nei piccoli-medi contratti il periodo temporale è generalmente ridotto, ma deve essere assicurata la coerenza nell’impiego di risorse proporzionalmente ai servizi richiesti ed alla loro criticità e la continuità con i gruppi proposti per l’erogazione dei servizi.
L’addestramento potrà consistere, ad esempio, nell’esame della documentazione esistente con assistenza di personale esperto, affiancamento nell’operatività quotidiana condotta dal fornitore uscente e/o dall’Amministrazione. Durante le attività di training on the job la responsabilità delle operazioni continuerà ad essere in capo al Fornitore uscente e/o all’Amministrazione.
PIANIFICAZIONE INIZIALE
Qualora necessario, in Appalto Specifico verranno richiesti Il Piano della Qualità e/o il Piano di lavoro iniziale e/o il Piano di Subentro secondo le modalità indicate nella richiesta d’offerta e nel capitolato tecnico di AS.
PRESENTAZIONE CV
Il Fornitore dovrà presentare i CV delle risorse proposte per l’erogazione della fornitura unitamente alle certificazioni richieste, con particolare riferimento ai servizi erogati a giorni persona.
Il Fornitore dovrà consegnare i CV delle risorse che intende utilizzare per la fornitura dei servizi alla stipula del contratto salva diversa indicazione contenuta nel singolo Appalto Specifico per le risorse chiave.
CONTEGGIO BASELINE INIZIALE, CODICE VIVO E MANUTENIBILITA’
L’Amministrazione può richiedere il conteggio della baseline iniziale delle applicazione proprietarie. Inoltre è particolarmente importante la misurazione degli elementi necessari a determinare le effettive funzionalità e codice/dati utilizzati attraverso l’analisi statica e dinamica del sw (report di analisi del codice morto, del codice ridondato, del codice riusato, ecc..) ed il grado di manutenibilità del software.
Per i Lotti 1 e 2, i fornitori dovranno disporre di propri strumenti automatici specializzati nel calcolo dei PF automatici e nelle metriche di qualità del software. In sede di AS, le Amministrazioni potranno richiedere la conoscenza di specifici strumenti in uso presso l’Amministrazione stessa.
Per i Lotti 3,4,5,6,7 sarà l’Amministrazione a richiedere l’utilizzo di strumenti automatici per il calcolo dei PF automatici ove ritenuto necessario, ma tutti i fornitori devono disporre di strumenti per l’analisi della qualità del software.
Le misurazioni devono essere accurate e verificabili, potendo costituire il riferimento per il calcolo dei corrispettivi. Errori e sopravvalutazioni sono gravi violazioni contrattuali: tutte le spese e costi di riconteggio saranno a carico del fornitore anche qualora l’Amministrazione sia costretta ad affidare ad un fornitore terzo ed indipendente una nuova misurazione.
Specialmente nei grandi contratti, la manutenzione correttiva potrebbe essere affidata in punti funzione e pertanto il fornitore è responsabile dell’esatta determinazione della dimensione del software “vivo” affidato al servizio escludendo il software realizzato/modificato dal fornitore stessa od in garanzia. Il fornitore deve pertanto disporre del know how, degli strumenti, di procedure per mantenere aggiornata la baseline del software pre- esistente e la baseline del software realizzato o modificato in AS.
Nei casi di servizi che richiedono la presa in carico di applicazioni stimate in Punti Funzione (sia servizi realizzativi sia Manutenzione Correttiva) il Fornitore potrà effettuare, ad inizio della fornitura, il conteggio della baseline iniziale in Punti Funzione. Eventuali difformità rispetto al conteggio effettuato dall’Ente in Appalto Specifico, dovranno essere motivate e certificate da una risorsa certificata e sottoposte all’Ente prima dell’attivazione del servizio.
7.3 Requisiti Organizzativi
In sede di AQ, l’Impresa dovrà indicare il Responsabile del Servizio che dovrà rispondere del corretto esecuzione degli adempimenti di AQ, come indicati dallo schema di contratto di AQ.
Per ogni AS, il Fornitore dovrà designare il Responsabile del Servizio di AS denominato anche Responsabile unico delle attività contrattuali.
In funzione della dimensione e della rilevanza dell’AS, l’Amministrazione potrà richiedere altri referenti (xx.xx. Referente per la qualità, Referente tecnologico, ecc.).
Il Responsabile unico delle attività contrattuali, senza oneri aggiuntivi per l’Amministrazione, dovrà:
• farsi carico della gestione del personale componente i vari gruppi di lavoro (ad esempio ferie, malattie, indisponibilità in genere) al fine di garantire la regolare disponibilità delle risorse nell’orario di servizio. L’organizzazione del Fornitore dovrà essere tale da garantire l’autonomia delle proprie risorse dall’Amministrazione e pertanto, in caso di attivazione di servizi continuativi o che richiedono un presidio, sarà responsabilità del Fornitore proporre ed aggiornare i piani di presenza e di eventuale turnazione in funzione dello specifico piano di lavoro (copertura in caso di picchi di lavoro, ferie, reperibilità, extraorario, ecc..);
• riferire all’Amministrazione (in funzione delle specifiche competenze) su tutte le attività legate alla corretta esecuzione dei servizi quali, ad esempio, la corretta misurazione, la pianificazione e la consuntivazione degli Obiettivi, gli adempimenti legati alla qualità, il controllo dell’avanzamento lavori, la verbalizzazione degli incontri con l’utenza, le attività di valutazione e contenimento dei rischi, l’efficacia e l’efficienza dell’attività di test, ecc.;
• assicurare un alto grado di sinergia tra le risorse impiegate nello sviluppo e quelle impiegate negli altri servizi quali la gestione per la fase di avviamento in esercizio delle applicazioni/obiettivi, al fine di garantire un costante e adeguato grado di conoscenza e di attenzione evitando discontinuità.
7.4 Requisiti di Qualità Della Fornitura
Nell’esecuzione delle attività contrattualmente previste il Fornitore dovrà:
• rispettare i principi di assicurazione e di gestione della qualità della norma EN ISO 9001 rispetto alla quale gli è stata richiesta la certificazione;
• attenersi ed essere conforme a quanto previsto dal proprio Sistema di Gestione della Qualità e dal Piano della Qualità dell’AS, se previsto;
• implementare e perseguire le soluzioni migliorative proposte dal Fornitore in sede di offerta sia di AQ sia di AS;
• rispettare la normativa ISO 25010 e successive sulla qualità del software e dei dati;
• rispettare i livelli di servizio e gli indicatori di qualità riportati nell’Appendice - Indicatori di qualità AQ, così come integrata ed aggiornata nello specifico documento di AS. Infatti, a livello di AQ gli indicatori presidiano i servizi e le attività decontestualizzate dall’ambito, dalla dimensione e dalla criticità dei servizi,
invece in AS l’Amministrazione potrà meglio circoscrivere gli indicatori applicabili e specializzarne altri, nonché definire con esattezza i fenomeni da rilevare e le soglie di qualità attese.
7.4.1 Piano di Qualità
Generalmente sui contratti “grandi” dei Lotti 1 e 2, l’Amministrazione richiede il Piano della Qualità (potrebbe essere anche valutato in sede di Offerta Tecnica di AS).
Il Piano di qualità è il documento di riscontro per la valutazione della qualità del servizio erogato, rispetto al quale si valuta il livello qualitativo dei servizi erogati per l’intera durata contrattuale, anche in riferimento alle effettive esigenze dell’utenza.
Il Piano di Qualità dovrà essere predisposto dal Fornitore e dovrà:
• fornire lo strumento per collegare i requisiti specifici dei servizi contrattualmente richiesti con le procedure generali del sistema qualità e gestione dei rischi del Fornitore già esistenti;
• esplicitare le disposizioni organizzative e metodologiche adottate dal fornitore, allo scopo di raggiungere gli obiettivi tecnici e di qualità contrattualmente definiti;
• esplicitare le disposizioni organizzative e metodologiche adottate dal fornitore, allo scopo di determinare la più idonea soluzione tecnica ed economica per l’Amministrazione in ciascun servizio affidato e determinare dimensionamenti accurati ed affidabili;
• dettagliare i metodi di lavoro messi in atto dal fornitore, facendo riferimento o a procedure relative al proprio sistema, e per ciò descritte nel manuale qualità, o a procedure sviluppate per lo specifico contrattuale, a supporto delle attività in esso descritte (in questo caso da allegare al piano): in particolare, per i servizi realizzativi, dovranno essere esplicitati, con riferimento al contesto della fornitura, le modalità di formazione del gruppo di lavoro, i cicli di vita adottabili, gli effort per fase media stimata, le modalità di avanzamento e di controllo e di rendicontazione interna ed esterna, le modalità e gli strumenti per il test funzionale e non, ecc.;
• garantire il corretto e razionale evolversi delle attività contrattualmente previste, nonché la trasparenza e la tracciabilità di tutte le azioni messe in atto dalle parti in causa, il Fornitore e la Amministrazione contraente;
• rispettare quanto previsto dalla normativa di riferimento.
Qualora richiesto, Il piano di qualità dell’AS dovrà essere approvato prima dell’avvio delle attività contrattuali e potrà essere aggiornato su richiesta dell’Amministrazione.
7.5 Orario di erogazione dei servizi
In Appalto Specifico l’Amministrazione indicherà le puntuali esigenze di orario per ciascun servizio. A livello di AQ ci si riferisce alla situazione di maggior controllo e presidio in modo che il prezzo offerto in prima fase sia comprensivo delle richieste più estese.
Il livello alto è caratterizzato da una copertura del servizio estesa, erogabile attraverso una turnazione delle risorse, senza soluzione di continuità dall’apertura del servizio al termine, a cui si associa la facoltà dell’Amministrazione di richiede un’estensione ovvero un prolungamento sia nell’ambito della medesima giornata lavorativa (sino alla copertura delle 24 ore) sia attraverso interventi on-site fuori orario di servizio. La tabella seguente riporta in forma schematica le caratteristiche del livello di presidio alto.
SERVIZIO | ORARIO | PERIODO | estensione | reperibilità |
Servizi realizzativi IT (relativamente alle attività che richiedono incontri con Amministrazione o attività presso l’Amministrazione) e servizi Tecnico Specialistici | 8:00 – 20:00 | Giorni feriali | Responsabile o risorsa chiave per la fase di riferimento | |
Gestione applicativi e basi dati | 8:00 – 20:00 8:00 - 14:00 Senza interruzione | Giorni feriali Sabato | Su richiesta, sino al completame nto delle 24 ore | Sì: telefono di reperibilità e presenza on- site entro 1 ora |
Gestione dei contenuti di Siti, Portali e canali Web | ||||
Manutenzione Correttiva | ||||
Servizi di supporto - | 8:00 – 20:00 | Giorni feriali | Specialista responsabile del progetto | |
Servizi accessori | 8:00 – 20:00 | Giorni feriali | Specialista responsabile del progetto |
Si precisa che:
• in caso sia presente un team di lavoro l’orario sarà garantito secondo una distribuzione delle presenze da concordare con l’Amministrazione nel piano di lavoro, all’interno dell’orario di servizio, non sono previste maggiorazioni;
• relativamente all’extraorario pianificato (oltre le ore 20,00 – dal lunedì al venerdì e oltre le 14.00 del sabato) nonché domenica e festivi, gli interventi in reperibilità (on-site o da remoto) verrà retribuito alla tariffa oraria base maggiorata del 20%.
Per festività devono intendersi solamente le festività a carattere nazionale, non potendo in sede di AQ escludere la diffusione su tutto il territorio degli utenti finali dei servizi oggetto della fornitura.
I servizi di gestione del portafoglio applicativo o l’Amministrazione attivano il gruppo di manutenzione correttiva durante l'orario di servizio (anche esteso) che opererà in piena autonomia al fine di garantire il rispetto degli “Indicatori di qualità”, salvo diverse indicazioni previste in AS.
7.6 Luogo di erogazione dei servizi
Nel singolo Appalto Specifico, l’Amministrazione definisce il luogo di erogazione dei servizi. Nel paragrafo seguente è riportata una situazione standard. Tali modalità potranno essere modificate anche durante la vigenza dell’AS.
Le imprese aggiudicatarie dovranno garantire la presenza presso l’Amministrazione, qualora richiesta per l’erogazione dei servizi e/o per riunioni e/o per qualsiasi esigenza connessa alla fornitura, senza oneri aggiuntivi rispetto a quanto offerto. Eventuali spese di trasferta potranno essere previste dall’Amministrazione per attività fuori dalla/e sede/i ordinaria/e e qualora richiedano spostamenti al di fuori della provincia di riferimento.
In linea generale, i posti di lavoro necessari al Fornitore presso le proprie sedi devono essere dotati, a suo carico, del necessario corredo hardware e software, sia di base che di sviluppo, che per eventuali collegamenti ai sistemi dell’Amministrazione.
Sarà cura del Fornitore predisporre gli ambienti di sviluppo e manutenzione compatibili con gli ambienti di collaudo ed esercizio dell’Amministrazione, senza alcun onere aggiuntivo.
Eventuali casi di disponibilità di posti di lavoro presso l’Amministrazione (si stima Enti di dimensioni rilevanti, dotati di una propria organizzazione ICT) sarà l’Amministrazione stessa a dichiararlo nella documentazione di AS, specificandone le modalità di fruizione. In nessun caso, gli aggiudicatari potranno opporre costi relativi alla disponibilità di strumenti, attrezzature, corredo hardware e software.
Si segnala, comunque, che potrebbe esserci la necessità di interventi in sedi diverse da quelle inizialmente indicate, che saranno tempestivamente comunicate dall’Amministrazione.
La struttura, l’organigramma, le sedi di lavoro del committente verranno indicate in AS.
SERVIZIO | SOTTO-SERVIZIO | SEDE PRINCIPALE | NOTE |
Servizi applicativi IT (relativamente alle attività che richiedono incontri con Amministrazione o attività presso l’Amministrazione) e servizi Tecnico-Specialistici | Fornitore | Sede Amministrazione per tutte le attività che richiedono la presenza dell’Amministrazione od attività negli ambienti applicativi dell’Amministrazione | |
Manutenzione correttiva | Fornitore | Sede Amministrazione per riproduzione errore o accettazione/collaudo modifiche | |
Gestione applicativi e basi dati | Amministrazione | Spesso le risorse operano congiuntamente a personale dell’Amministrazione. Se richiesto il servizio presso il fornitore, particolare cura deve essere posta nella definizione dei livelli di servizio, della verifica delle attività e della qualità | |
Gestione dei contenuti di Siti, Portali e canali Web | |||
Servizi di supporto | Fornitore | Sede Amministrazione per tutte le attività che richiedono la presenza dell’Amministrazione, per la definizione dei requisiti, per la verifica dell’avanzamento e per l’accettazione delle attività. Nel caso di attività svolte in collaborazione con l’Amministrazione la sede è presso l’Amministrazione. | |
Servizi accessori | Da definire in AS | ||
7.7 Strumenti a supporto dell’operatività della fornitura
Il Fornitore dovrà conoscere e disporre di:
• Strumenti per la verifica della qualità del software: al fine di misurare ed assicurare la qualità del software realizzato o modificato il Fornitore dovrà prevedere processi operativi, modalità per la verifica, risorse, strumenti/prodotti atti allo scopo e che si impegna a mettere a disposizione ad inizio di ciascun AS – se prevista nella fase di subentro (comunque non oltre la fase di analisi del primo obiettivo di sviluppo/evolutiva di software realizzato o modificato). Le verifiche previste negli indicatori specifici verranno effettuate su tali postazioni in contraddittorio con il Fornitore
• Strumenti per la gestione della configurazione del sw
• Strumenti per gestire l’inventario Funzionale applicativo che gestisce il censimento volumetrico in Punti Funzione delle applicazioni dell’Amministrazione, solo eventualmente su richiesta dell’Amministrazione in AS.
7.8 MODALITA’ DI EROGAZIONE
I servizi previsti nel presente AQ possono essere erogati sia in modalità progettuale sia continuativa, come indicato dall’Amministrazione in fase di AS.
A prescindere dalla modalità con cui si erogheranno i servizi, le imprese aggiudicatarie, devono:
⮚ provvedere in piena autonomia al coordinamento e all’organizzazione dei servizi oggetto della fornitura;
⮚ garantire il rispetto dei processi, degli standard e best practices internazionali nonché di eventuali linee guida adottate dalle Amministrazioni e descritte in sede di AS;
⮚ assicurare la creazione, in lingua italiana, di tutta la documentazione prodotta a seguito delle attività oggetto dei servizi;
⮚ effettuare i dimensionamenti delle attività e servizi con la massima accuratezza ed affidabilità: in nessun caso potranno essere addebitati all’Amministrazione oneri per attività non svolte o Punti Funzione non realizzati o non gestiti. Tali inadempimento costituiscono causa di risoluzione dell’AS.
⮚ pianificare e consuntivare le attività secondo le indicazioni di Project Management e quanto richiesto dall’Amministrazione.
7.8.1 Documentazione
Gli standard documentali dipendono da ciascuna Amministrazione, ma in ogni caso il fornitore è responsabile di garantire che la documentazione interna al software, d’uso funzionale e per la gestione applicativa e sistemistica, per l’evoluzione futura e per la correttiva, sia in grado di permettere la piena acquisizione del know-how da parte dell’amministrazione o di terzi da essa delegati.
Di seguito uno schema riferito ad un modello di sviluppo sw ciclo completo, a cascata. Tutti prodotti indicati sono compresi nel corrispettivo offerto di AQ sia esso in PF sia esso in GG/PP.
Pertanto, i seguenti prodotti di fase sono da considerarsi requisiti minimi, che solo l’Amministrazione in AS potrà ridurre in ragione della dimensione e della propria organizzazione interna.
Fase | Prodotto di fase – ciclo completo |
Definizione | Piano di lavoro di obiettivo |
Piano della qualità dell’obiettivo (indicatori specifici di qualità del sw per tecnologia, architettura, requisiti non funzionali) | |
Prototipo | |
Specifiche requisiti (funzionali e non funzionali) | |
Altri documenti (es. analisi d’impatto; exx..) | |
Analisi | Piano di lavoro di obiettivo (tempi e costi) |
Documento di analisi | |
Prototipo avanzato sulla base dell’analisi | |
Piano di test (predisposizione ambienti/test automatici/cammini critici/campionamenti/ecc..) | |
Convalida sulla tecnologia (rispetto std e best practices, indicatori di qualità sw) | |
Modulo per conteggio FP (conteggio di revisione) | |
Altri documenti (Eventuali) | |
Disegno | Piano di lavoro di obiettivo |
Disegno di dettaglio | |
Piano di test | |
Documentazione dati | |
Campione tecnico | |
Altri documenti | |
Realizzazione | Piano di lavoro di obiettivo |
Codice sorgente | |
Piano di test |
Fase | Prodotto di fase – ciclo completo |
Documentazione utente | |
Documentazione delle procedure batch/DTS | |
Manuale di gestione applicativo | |
Manuale di gestione sistemistico | |
Modulo per conteggio FP (conteggio consuntivo/calcolo automatico di controllo, rettificato da dettaglio funzioni riusate/ridondate/duplicate .. utilizzo librerie aperte) | |
Report di inventario funzionale | |
Lista Oggetti Software | |
Report di analisi della qualità del sw (Iso 25010 e successive) | |
Demo sulle novità del sistema | |
Piano di adeguamento degli ambienti | |
Altri documenti | |
Collaudo | Verifica di conformità da parte dell’amministrazione |
Documentazione Aggiornamento documentazione preesistente a livello di applicazione e/o di sistema | Rapporto indicatori di qualità di obiettivo |
Documento di sintesi del sistema applicativo (in caso di modifiche ad applicazioni appartenenti ad un sistema più ampio) | |
Specifiche requisiti a livello di applicazione (in caso di modifiche applicazione esistente) | |
Specifiche di analisi a livello di applicazione (in caso di modifiche applicazione esistente) | |
Disegno di dettaglio di applicazione (in caso di modifiche applicazione esistente) | |
Avvio in esercizio | Piano di lavoro di obiettivo (consuntivi) |
Rapporto indicatori di qualità di obiettivo e di applicazione Test di verifica performance, tempi di risposta ed altre dimensioni |
7.8.2 Assenza di Virus
Tutti i prodotti consegnati su supporti ottici o in via telematica dovranno essere esenti da virus. L’Amministrazione si riserva di verificare l’assenza di virus secondo le modalità e gli strumenti che riterrà più opportuni.
7.8.3 Accettazione/approvazione prodotti della fornitura
l’Amministrazione sottopone ad Accettazione/Approvazione tutti i prodotti previsti per i servizi attivati nei relativi AS al fine di verificare la rispondenza dei prodotti stessi ai requisiti stabiliti (funzionali e non funzionali).
Le anomalie/malfunzionamenti/disallineamenti dovranno essere tempestivamente risolte dal Fornitore per permettere la prosecuzione delle attività, entro comunque i tempi definiti dai livelli di servizi (appendice qualità aggiornata dall’Amministrazione) o dall’Amministrazione stessa. Eventuali ritardi nella risoluzione delle anomalie riscontrate comporteranno l’applicazione delle sanzioni contrattualmente previste.
Nel caso si verifichino situazioni “anomale” che, a giudizio dell’Amministrazione, sia per numerosità sia per gravità, sia per non rispetto dei tempi massimi indicati dall’Amministrazione per la risoluzione delle anomalie, non consentano lo svolgimento o la prosecuzione delle attività l’Amministrazione procederà alla sospensione dell’obiettivo e lo slittamento del termine della fase sarà a totale carico del Fornitore comportando le azioni contrattuali previste.
I nuovi termini di consegna dei prodotti verranno indicati dall’Amministrazione ed entro tali termini il Fornitore dovrà procedere alla consegna della versione corretta dei prodotti stessi. In caso di 2 sospensioni sul medesimo obiettivo l’Amministrazione si riserva la facoltà di dichiarare non approvabile il prodotto oggetto di verifica per inadempimento del Fornitore e gli acconti eventualmente versati al Fornitore dovranno essere da lui restituiti oltre al risarcimento dei danni all’Amministrazione e la valutazione della risoluzione dell’AS.
All’atto dell’accettazione dei prodotti dell’obiettivo, in caso in cui sia possibile procedere all’accettazione/approvazione dei prodotti, verrà redatto e sottoscritto dall’Amministrazione il verbale di accettazione. Tale documento sarà utilizzato in fase di Verifica di Conformità.
Per i servizi realizzativi, assume particolare rilevanza l’accettazione del prodotto software realizzato. Le attività di accettazione vengono pianificate nella fase di Collaudo. Tale fase è di responsabilità dell’Amministrazione: l’esecuzione dei test di collaudo avverrà in contraddittorio con il fornitore che è tenuto a dare supporto all’Amministrazione, senza alcun onere aggiuntivo.
Al termine del collaudo, verrà redatto il verbale di collaudo con allegati i casi di test eseguiti ed il relativo esito. Tali dati determineranno il valore dell’indicatore di qualità TNCO -“Tasso di Casi di test eseguiti in collaudo con esito negativo”.
Si precisa che qualora il valore rilevato dell’indicatore sia inferiore al 10%, l’Amministrazione darà un termine molto limitato (indicativamente un termine di 3 giorni lavorativi) per riconsegnare il software corretto e verranno riprese le attività di collaudo senza alcuna ripianificazione; non si ha una formale sospensione del collaudo.
Diversamente, qualora il valore rilevato dell’indicatore sia superiore al 10%, verrà sospeso il collaudo. L’Amministrazione ed il fornitore concorderanno il tempo di sospensione ed a tale periodo sarà applicato l’apposito indicatore di qualità.
Come indicato nella trattazione generale, nel caso di 2 sospensioni sulla medesima attività/fase/prodotto, l’Amministrazione si riserva di risolvere il contratto di AS per inadempimento del fornitore.
In caso di obiettivi realizzativi molto piccoli in termini di punti funzione/funzionalità realizzate, per i quali non si addice la misurazione in termini percentuali della difettosità (casi di test indicativamente inferiori a 50), sarà l’Amministrazione a stabilire le soglie di difettosità fisiologica e le modalità di sospensione del collaudo.
7.8.4 Verifiche di conformità
Il soggetto deputato all’esecuzione delle attività di verifica di conformità, dopo aver acquisito la documentazione tecnico-funzionale dei servizi (sia a carattere continuativo che progettuale), procederà a certificare la corretta esecuzione degli stessi. Della verifica di conformità si darà apposita comunicazione al fornitore che potrà parteciparvi. Al termine della suddetta verifica verrà data comunicazione formale al fornitore.
7.9 Monitoraggio
Le attività di monitoraggio sull’esecuzione del contratto saranno svolte dall’Amministrazione secondo le modalità specificate nel Contratto di Appalto Specifico.
In particolare, le attività di monitoraggio dovranno essere conformi a quanto previsto dalla circolare n. 4 del 15 dicembre 2016 emessa dall’AgID, ai sensi dell’art. 14-bis, comma 2, lett. h.) del CAD, come modificato dal decreto legislativo 26 agosto 2016, n. 179, qualora l’Amministrazione sia tra quelle incluse nell’” Elenco delle Amministrazioni coinvolte nel monitoraggio sull’esecuzione dei contratti” predisposto dall’AgID e il contratto presenti almeno una delle caratteristiche di seguito indicate:
• abbiano un valore, al netto di IVA, superiore a 15 (quindici) milioni di euro, ovvero, in caso di contratti con validità pluriennale, superiore a 3,5 (trevirgolacinque) milioni di euro in media ogni anno. In caso di procedure di gara suddivisi in lotti, si considera il valore totale della procedura indipendentemente dal numero dei lotti e dal loro valore relativo. In tal caso, il monitoraggio si applicherà a ognuno dei contratti scaturenti dalle aggiudicazioni dei vari lotti;
• proroghe o atti aggiuntivi delle tipologie di contratto sopra riportato;
• si riferiscano a servizi che interessino la sicurezza dello Stato, la difesa nazionale, l'ordine e la sicurezza pubblica, lo svolgimento di consultazioni elettorali nazionali ed europee, indipendentemente dalle dimensioni economiche sopra indicate;
• abbiano un rilevante impatto sotto il profilo organizzativo o dei benefici che si prefiggono di conseguire, indipendentemente dalle dimensioni economiche sopra indicate, e che l’Agenzia ritenga necessario sottoporre a monitoraggio; in questo caso, l’Agenzia si riserva di richiedere tutte le informazioni necessarie a stabilire l’eventuale richiesta di monitoraggio del contratto all’Amministrazione.
In tal caso le attività di monitoraggio sono svolte dall’Amministrazione secondo una delle seguenti modalità:
a) direttamente dall’Amministrazione interessata, sotto la direzione del Responsabile del monitoraggio, utilizzando risorse interne adeguatamente formate e formalmente nominate (Gruppo di monitoraggio);
b) da una società esterna selezionata tramite apposita procedura di gara, ferma restando, in ogni caso, la direzione e la responsabilità del Responsabile del monitoraggio;
c) direttamente dall’AgID, su richiesta dell’Amministrazione, in base ad una specifica convenzione da stipulare tra le parti.
7.10 Flussi FEE e Flussi Informativi di Monitoraggio Forniture
Gli aggiudicatari dei singoli Appalti Specifici sono tenuti all’invio a Consip S.p.A. dei flussi FEE con le modalità stabilite dallo schema di contratto di AQ e dallo specifico documento.
Gli aggiudicatari di AS sono, inoltre, tenuti ad inviare i flussi informativi relativo al monitoraggio dell’AQ con le modalità che saranno dettagliate alla stipula dell’AQ e/o durante tutta la validità dell’AQ e degli Appalti Specifici. Consip si riserva di aggiornare il documento delle specifiche.
7.11 Azioni contrattuali
Ogni inadempimento contrattuale darà origine ad un’azione commisurata alla criticità della violazione.
I principali aspetti delle prestazioni contrattuali vengono presidiati da appositi indicatori di qualità, specialmente laddove vengono definite specifiche misure. Altri aspetti non sono oggetto di misurazioni strutturate di cui all’appendice “Indicatori di qualità”, ma per disservizi ritenuti gravi vengono direttamente presidiate nel capitolato tecnico e/o nel contratto.
Pertanto, il mancato rispetto dei requisiti minimi richiesti e/o come migliorati dal fornitore in Offerta tecnica determina azioni contrattuali conseguenti che possono consistere in una o più delle seguenti azioni:
• coinvolgimento di un livello più elevato di interlocutori, sia del fornitore, che della stazione appaltante, allo scopo di prendere le decisioni necessarie al ripristino delle situazioni fuori soglia o fuori controllo (attivazione di una procedura di escalation);
• ripetizione da parte del fornitore dell’erogazione di una prestazione, rifacimento di una attività, riconsegna di un prodotto (chiusura di una non conformità);
• azione di intervento sui processi produttivi del fornitore per evitare il ripetersi di sistematiche non conformità (esecuzione di una azione correttiva);
• applicazione di rilievi, se previsti dall’Amministrazione;
• perdita della quota variabile del corrispettivo legato al raggiungimento di un livello di qualità minimo, se previsti dall’Amministrazione;
• applicazione di penali;
• azioni aggiuntive (richiesta danni, risoluzione anticipata del contratto, ecc.) laddove previsto contrattualmente.
In sede di AQ, i livelli di servizio vengono presidiati attraverso l’applicazione di penali.
In sede di AS l’Amministrazione potrà modificare le sanzioni per renderle maggiormente rispondenti alle dimensione ed alla criticità dell’AS e degli specifici inadempimenti. Pertanto, in sede di AS l’appendice indicatori di
qualità potrà essere rivista dall’Amministrazione per allinearla alle specifiche esigenze della fornitura. Ciò potrà avvenire sia attraverso la revisione delle soglie sia delle azioni contrattuali.
Segue un approfondimento degli istituti a tutela della qualità dell’erogazione della fornitura.
7.11.1 Rilievi
I rilievi sono le azioni di avvertimento da parte dell’Amministrazione conseguenti il non rispetto degli adempimenti contenuti nella documentazione contrattuale. Pertanto oltre a quanto esplicitamente previsto potrà essere emesso un rilievo su qualunque inadempimento se non diversamente sanzionato. Sono notificati al Fornitore tramite comunicazione anche via e.mail, ognuna delle quali potrà contenere uno o più rilievi.
I rilievi non prevedono di per sé l’applicazione di penali e, se reiterati e accumulati, danno luogo a penali e/o altre azioni contrattuali. Pertanto, l’utilizzo di questa sanzione comporta l’introduzione in Appendice “Indicatori di qualità” di un livello di servizio che determina il numero massimo di rilievi tollerati al cui superamento si un’azione di livello superiore, perdita quota sospesa o penale.
Qualora il Fornitore ritenga di procedere alla richiesta di annullamento del rilievo dovrà sottoporre all’Amministrazione un documento con elementi oggettivi ed opportune argomentazioni entro il termine definito dall’Amministrazione (in genere 3 giorni lavorativi dall’emissione della nota di rilievo).
7.11.2 Indici di prestazione
Gli indici di prestazione sono legati al raggiungimento delle soglie di qualità previste per uno o più indicatori di qualità e dovranno essere indicati dall’Amministrazione nell’Appendice stessa.
Per alcuni indici di prestazione, la “% Quota” si intende maturata con il contemporaneo raggiungimento dei valori di soglia degli indicatori di qualità ai quali sono correlati.
In altri termini, il mancato raggiungimento del previsto valore di soglia anche di un solo Indicatore di qualità comporterà il mancato raggiungimento dell’Indice di prestazione correlato. Ciò avrà efficacia per il complesso dei corrispettivi maturati nel periodo di riferimento.
Altri indici di prestazione prevedono quote sospese distinte e disgiunte, pertanto il raggiungimento del singolo indicatore collegato all’Indice di prestazione comporta l’erogazione della relativa quota sospesa indipendentemente dagli altri indicatori.
7.11.3 Penali
Lo scopo delle penali è quello di riequilibrare il servizio effettivamente ricevuto (di minore qualità, e/o generando disservizi e/o ritardi e/o inducendo un danno all’utilizzatore) dall’Amministrazione al corrispettivo da erogarsi che è stabilito per prestazioni effettuate a regola d’arte.
Le penali da adottare sono individuate contrattualmente e normalmente sono organizzate in modo progressivo in relazione alla gravità o al ripetersi della mancata soddisfazione degli adempimenti richiesti.
7.12 STRUMENTI A SUPPORTO IN FASE DI AS
Contestualmente all’attivazione dell’Accordo Quadro Servizi Applicativi per la PA, Consip S.p.A. pubblicherà sul portale xxx.xxxxxxxxxxxxxxx.xx, nella vetrina relativa all’iniziativa in oggetto, una serie di modulistica, sotto forma di facsimile, a supporto dell’amministrazione appaltante per la predisposizione dei singoli Appalti Specifici.
Tra i principali documenti si prevede:
• Indicatori di Qualità 🡪 il documento conterrà l’attuale appendice indicatori di qualità che le amministrazioni appaltanti potranno utilizzare durante l’intera durata contrattuale ai fini della verifica degli SLA (Service Level Agreement) adeguandola alle proprie esigenze ed ai servizi richiesti;
• Profili Professionali 🡪 il documento conterrà l’attuale appendice profili delle risorse professionali necessarie per l’erogazione dei servizi. Le amministrazioni appaltanti potranno adeguare le competenze
alle specifiche esigenze in termini piattaforme tecnologiche, linguaggi di programmazione, tematiche funzionali, anche richiedendo certificazioni specifiche sui prodotti;
• Guida all’Accordo Quadro 🡪 il documento conterrà una sintesi dei principali aspetti della struttura dell’Accordo Quadro. Inoltre, conterrà, le credenziali e i riferimenti di ciascun fornitore aggiudicatario dell’AQ.