SISTEMA INFORMATIVO CONTABILE DELLA REGIONE
Regione Autonoma della Sardegna
Assessorato della Programmazione, Bilancio, Credito e Assetto del Territorio
Servizio Informativo per il Monitoraggio e l’Analisi della Finanza Regionale
APPALTO CONCORSO PER LA REALIZZAZIONE DEL
SISTEMA INFORMATIVO CONTABILE DELLA REGIONE
AUTONOMA DELLA SARDEGNA (SIC)
DISCIPLINARE TECNICO
Maggio 2004
SOMMARIO
1. QUADRO DI RIFERIMENTO - SCENARIO INTERNO/ESTERNO 3
2. OBIETTIVI DEL PROGETTO E CARATTERISTICHE GENERALI DEL SISTEMA INFORMATICO .4
2.1 Disponibilità delle applicazioni in formato sorgente 5
2.2 FLESSIBILITÀ 6
2.3 Capacità di integrazione 6
2.4 Modularità e scalabilità 6
2.5 Semplicità d’uso della soluzione finale 7
2.6 Manutenibilità 7
2.7 Architettura web-based 7
2.8 Interfaccia documentale 7
3. ARTICOLAZIONE DELL’APPALTO 8
3.1 Piano di lavoro 8
4. FASE 1: FORNITURA DI UN WEB-SERVER 10
5. FASE 2: REALIZZAZIONE DELLE FUNZIONI APPLICATIVE PRINCIPALI 12
5.1 Caratteristiche generali e modulo per la sicurezza 12
5.2 Sincronia 12
5.3 FORMAZIONE DEL BILANCIO DI PREVISIONE (ANNUALE E PLURIENNALE): 12
5.4 Variazione del Bilancio 15
5.5 Gestione del Bilancio 16
5.6 OBIETTIVI DELLA FASE 2 17
5.7 COLLAUDO PROTOTIPO FASE 2 17
5.8 COLLAUDO FASE 2 17
6. FASE 3: REALIZZAZIONE DELLE FUNZIONI APPLICATIVE SECONDARIE E DI QUELLE AGGIUNTIVE 19
6.1 Monitoraggio finanziario e procedurale 19
6.2 Contabilità analitica 21
6.3 Gestione delle determ inazioni 23
6.4 Gestione dei progetti 24
6.5 Collegamento DPEF e Bilancio di Previsione 24
6.6 Intranet documentale 24
6.7 Datawarehouse 24
6.8 Gestione del Bilancio d’Area 25
6.9 Modello sperimentale di bilancio sociale della Xxxxxxx Xxxxxxxx 00
6.10 OBIETTIVI DELLA FASE 3 25
6.11 COLLAUDO PROTOTIPO FASE 3 25
6.12 COLLAUDO FASE 3 25
7. FASE 4: ASSISTENZA TECNICA SU RICHIESTA 26
8. RINNOVO DELLE PRESTAZIONI PREVISTE NELLA FASE 4. 28
9. MODALITÀ DI ESPLETAMENTO DELLA FORNITURA 28
9.1 Piano di lavoro 28
9.2 Variazione in corso d’opera 28
9.3 Collaudo 28
10. GARANZIA E MANUTENZIONE 28
APPALTO CONCORSO PER LA REALIZZAZIONE DEL SISTEMA INFORMATIVO CONTABILE DELLA REGIONE AUTONOMA DELLA SARDEGNA (SIC)
DISCIPLINARE TECNICO
Premessa
Questo documento trae spunto ed integra il lavoro svolto dal gruppo interassessoriale (costituito con Determinazione del Direttore Generale della Programmazione, Bilancio, Credito e Assetto del territorio n.159/DG del 29.10.2003) e ha dato luogo ad uno Studio di Fattibilità di un Sistema Informativo Integrato per la Contabilità, il Monitoraggio e la Valutazione della Finanza Regionale (SIC), approvato dalla Giunta Regionale con Delibera n° 6/1 del 17/2/2004. Il documento è presente nel sito internet della R.A.S. xxx.xxxxxxx.xxxxxxxx.xx
Il presente disciplinare tecnico completa e in alcuni casi modifica le impostazioni presenti nello studio di fattibilità, che va quindi interpretato come un documento di lettura, utile al fine di comprendere meglio gli obiettivi che l’appalto si propone, ma esterno alle specifiche dell’appalto.
1. Quadro di riferimento - Scenario interno/esterno
Il Sistema informativo dovrà costituire un adeguato supporto negli adempimenti e funzioni connessi alla predisposizione e alla gestione degli strumenti di governo della finanza regionale, al monitoraggio e alla verifica della programmazione regionale, al controllo di gestione, alla certificazione della spesa, alla valutazione strategica.
Il ruolo della Regione Autonoma della Sardegna nell’ambito federale tracciato dalla riforma del titolo III della Costituzione rende fondamentali gli interventi relativi al controllo degli atti contabili degli enti strumentali, all’attivazione del progetto Conti Pubblici Territoriali, all’attuazione del Federalismo fiscale, alla verifica dei parametri del Patto di stabilità interno, oltre al completamento dell’attività di ricognizione e trasferimento delle risorse relative agli accordi stipulati nell’ambito della programmazione negoziata.
E’ necessario rafforzare i sistemi di monitoraggio degli interventi inseriti negli Accordi di programma quadro e dei programmi cofinanziati con i fondi strutturali europei 2000-2006, nonché assicurare l’interfaccia tra i due sistemi, con azioni di sistema (si veda anche al riguardo il progetto di Monitoraggio degli Accordi di Programma quadro, di cui alla delibera CIPE n.17/2003).
I Regolamenti comunitari impongono l’applicazione di misure di controllo sulle attività finanziate dall’U.E.: i Fondi Strutturali si collocano in una logica che richiede valutazioni sul rapporto costi/benefici, programmazione per progetti, verifica della spesa e costante monitoraggio.
Nella logica del ciclo unico di programmazione, si rende necessario estendere progressivamente tali misure all’intero quadro delle spese d’investimento, sia dirette che esterne e derivate, con la finalità di poter disporre di una banca dati degli investimenti pubblici in Sardegna (nell’ambito del sistema MIP – Monitoraggio Investimenti Pubblici, a livello statale).
La prevista introduzione della contabilità economico patrimoniale (art.2 L.R. 3/03), in linea con gli orientamenti e la normativa nazionale, e ferma restando la verifica preventiva e consuntiva dei flussi finanziari, dovrà articolarsi nell’adozione di sistemi contabili integrati.
Pertanto, nel quadro delineato, le linee e gli indirizzi regionali sono strettamente correlati agli
obiettivi strategici posti a livello nazionale e comunitario, inerenti:
- la razionalizzazione e il contenimento della spesa, anche al fine dell’abbattimento dell’attuale livello di indebitamento. Questo obiettivo richiede un costante impegno per evitare che prevalga la tendenza ad una espansione della spesa, quando non giustificata da incrementi contestuali di risorse e da riscontrabili utilità. A tal fine, assume rilevanza la capacità dei centri di spesa di tenere sotto controllo la gestione dei residui passivi, ma soprattutto attivi;
- il coordinamento tra la finanza regionale e quella degli enti locali e degli enti strumentali regionali che necessita della definizione di meccanismi di raccordo, finalizzati a garantire il controllo delle erogazioni a livello periferico e la responsabilizzazione dei molteplici enti e soggetti collegati alla finanza regionale;
- l’attivazione e il coordinamento degli adempimenti connessi all’attuazione del “federalismo fiscale” e alla definizione dell’Accordo di Programma Quadro Stato - Regione relativo al regime delle entrate fiscali, avente come oggetto la revisione del titolo III dello Statuto, alla cui realizzazione risultano necessari la collaborazione e il coordinamento di ciascun Assessorato. Al riguardo, si evidenzia che la riorganizzazione in senso federalista da parte dello Stato della finanza obbliga anche la Regione a procedere al potenziamento del sistema finanziario e delle strutture preposte all’acquisizione delle entrate;
- l’attuazione degli adempimenti connessi alla verifica del rispetto dei limiti di spesa stabiliti dal Patto di stabilità interno;
-la prosecuzione e la definizione della Riforma della legge di contabilità e l’introduzione della contabilità economico-patrimoniale e dei Centri di costo (ancora da definire a livello normativo regionale), con le relative trasformazioni del modello organizzativo dell’Amministrazione Regionale. Ciò consentirebbe di affiancare alla contabilità finanziaria le rilevazioni di natura economico patrimoniale, sviluppando un sistema integrato della gestione contabile collegata con la programmazione finanziaria ed economica, con il sistema delle procedure, con le risorse assegnate ai dirigenti e con il controllo di gestione.
Con l’analisi in corso di tutti i bilanci consuntivi dagli anni dal 1984 al 2001, la regione ha inteso
ricostruire non solo l’entità e la composizione dei risultati finanziari, ma anche individuare le principali cause che hanno condotto all’attuale situazione. La disponibilità in rete dei risultati, e la realizzazione del sistema informativo contabile integrato per il monitoraggio di tutte le entrate e spese regionali, consentirà la verifica dell’andamento delle stesse in conformità agli obiettivi previsti nei documenti contabili e di programmazione economico- finanziaria.
La verifica dell’andamento del livello delle entrate e delle spese regionali e del rispetto dei limiti stabiliti dal Patto di stabilità interno dovranno essere progressivamente realizzati con un sistema di codifica di tutti i capitoli del bilancio regionale, secondo le classificazioni economiche individuate dal Ministero dell’Economia e delle Finanze.
Una efficace e puntuale attività di programmazione del fabbisogno regionale assume importanza fondamentale al fine di assicurare alla Regione, nei tempi previsti, le risorse dovute dallo Stato, considerato che il Ministero dell’Economia e delle Finanze subordina l’erogazione delle quote di devoluzione dei tributi statali e dei trasferimenti spettanti alla Regione, in relazione al livello previsto, mensile ed annuale, della spesa regionale.
2. Obiettivi del progetto e caratteristiche generali del sistema informatico
L’obiettivo principale del progetto di sistema informativo contabile regionale integrato è volto a ricondurre ad un processo organizzativo unitario la raccolta e il trattamento dei dati contabili, per
via elettronica e telematica, anche in attuazione della Direttiva del Ministro per l’Innovazione tecnologica Stanca, del 21 dicembre 2001, che al punto 3.2 intitolato “Favorire l’economicità di gestione (gestione della contabilità economica e finanziaria)” dispone che “Ogni Amministrazione avvierà programmi per la progressiva eliminazione (2002/2003) della modalità di compilazione manuale di documenti di natura contabile. Ogni operazione di natura contabile (gestione degli stanziamenti, assestamenti, impegni, mandati di pagamento) dovrà essere effettuata per via elettronica”.
Il sistema, oltre all’obiettivo dell’integrazione , dovrà mantenere la caratteristica della
flessibilità dello strumento tecnologico nell’adeguarsi all’evolversi dell’organizzazione, considerando anche la specificità dell’autonomia statutaria e normativa della Regione, e infine garantire la standardizzazione dei flussi.
Il progetto dovrà ridisegnare l’architettura del sistema contabile, definendo le procedure telematiche di trasferimento delle informazioni, e delineando i supporti e i modelli informatici più adeguati, a partire dall’interfaccia contabile dei provvedimenti che comportano operazioni economico finanziarie: deliberazioni, decreti, determinazioni, schede di monitoraggio.
Le interfacce con le procedure di contabilità e bilancio di previsione esistenti attualmente, invece, saranno potenziate, fuori da questo appalto concorso, mediante l’estensione dei contratti di manutenzione e sistemistica già in essere.
Vengono di seguito elencate le principali caratteristiche richieste dal sistema informatico, che l’Impresa rappresenterà nel progetto-offerta.
2.1 Disponibilità delle applicazioni in formato sorgente
Il progetto è orientato all’integrazione del software esistente, garantendo un’elevata modularità, una elevata facilità di intervento e di manutenzione. Per queste ragioni, pur non essendovi ragioni pregiudiziali avverso l’utilizzo di package, si ritiene che l’adeguamento del modo di operare dell’Amministrazione, la peculiarità delle leggi in materia di contabilità (per le quali la RAS ha competenza primaria) necessitino, allo stato attuale, di personalizzazioni che consentano all’Amministrazione di adeguare in maniera graduale il proprio modo di operare.
In particolare la Commissione Tecnica, nella valutazione dell’offerta per ogni singolo modulo, valuterà la presenza dei sorgenti e la proprietà del software da parte dell’Amministrazione. Si ritiene quasi superfluo precisare che l’Amministrazione intende utilizzare la proprietà del software esclusivamente per la propria gestione; nulla osta quindi che l’Impresa utilizzi lo stesso software in realtà differenti: ciò che si vuole ottenere è solamente la capacità di intervento immediata sull’applicativo e l’indipendenza dall’Impresa per il suo adeguamento.
Per queste ragioni è fondamentale:
• che il progetto tenga conto delle procedure esistenti di gestione della contabilità finanziaria (presso la Presidenza della Giunta - Ragioneria generale ), e di previsione del bilancio (presso l’Assessorato della Programmazione, Bilancio, Credito e Assetto del Territorio), adeguandosi alla loro struttura dati ed eventualmente proponendo un’estensione di tale struttura. La struttura dati delle due applicazioni verrà fornita, su richiesta, alle Imprese.
Si dovrà tener conto inoltre della procedura di gestione degli ordini presso la Direzione Enti Locali e Finanze per garantire che l’applicativo proposto nel progetto-offerta possa coesistere con la detta procedura. Si precisa che non sarà compito dell’Impresa provvedere all’interfacciamento diretto di tali procedure, ma quello di proporre nei confronti delle stesse un’interfacciamento standard.
• che la parte centrale dell’applicazione sia fornita in formato sorgente, con proprietà, anche non esclusiva, da parte dell’Amministrazione e con possibilità di adeguamento alle proprie esigenze;
• che la presenza di moduli che non rispettano tali caratteristiche sia precisata preliminarmente, ampiamente giustificata, valutando attentamente le peculiarità della RAS, e in ogni caso limitata ai moduli non principali (sono moduli principali quelli inclusi nella fase 2 del progetto).
È opportuno precisare che l’Amministrazione potrà avvalersi del diritto di recedere dal contratto per colpa dell’impresa se questa in fase realizzativa dovesse presentare, in disaccordo con quanto dichiarato in offerta e comunque senza il benestare dell’amministrazione stessa, moduli non in formato sorgente o realizzati con linguaggi differenti da quelli dichiarati. Si precisa inoltre che l’Impresa dovrà obbligatoriamente indicare in fase di offerta, per ogni singolo modulo tali informazioni (presenza dei sorgenti, linguaggio utilizzato, proprietà dei sorgenti). Per quanto possibile dovrà essere evitata all’interno di uno stesso modulo la presenza di componenti tecnologiche disomogenee. Qualora non se ne potesse fare a meno, andrà indicato chiaramente in che misura, all’interno di uno stesso modulo, sono presenti componenti tecniche differenti.
Tali criteri sono applicabili in particolare ai moduli funzionali principali. L’offerta da parte dell’Impresa di moduli aggiuntivi, anche se non in formato sorgente, purché integrati a cura della Impresa proponente, non potranno che fornire un apporto positivo alla valutazione complessiva del progetto.
2.2 Flessibilità
L’applicativo dovrà essere in grado di:
• gestire eventuali cambiamenti di struttura di tipo organizzativo, mantenendo l’evidenza dei legami di cambiamento e rendendo quindi possibili i confronti tra la vecchia e la nuova struttura;
• adeguarsi ai mutamenti tecnologici ed all’interazione con altri progetti;
La flessibilità è legata alla proprietà dei sorgenti, in quanto questa proprietà garantisce l’Amministrazione da eventuali manchevolezze dell’Impresa nell’adeguare l’applicativo alle modifiche organizzative della RAS e alla manutenibilità. Ma sarà valutata anche autonomamente, tenendo conto della bontà dell’architettura adottata, della qualità certificata dell’Impresa in tutte le fasi del ciclo di vita del software.
2.3 Capacità di integrazione
Dal progetto finale dovrà scaturire un progetto informatico in grado di gestire in ma niera unitaria il flusso contabile. L’integrazione raggiungibile sarà necessariamente di tipo “debole”, ovvero integrazione di informazioni prodotte in sistemi diversi. Le applicazioni attualmente in vigore, come la gestione del Bilancio (BRS), rimarranno in essere, solo opportunamente “integrate” all’interno del sistema generale, divenendone dei moduli costituenti. Si ritiene un requisito indispensabile per determinare la riuscita del progetto, la capacità di mettere a disposizione, in tempo reale, le informazioni cardine del Sistema Informativo ai principali utilizzatori.
2.4 Modularità e scalabilità
Il sistema informatico sarà progettato in maniera modulare, per garantire una sua naturale evoluzione ed integrazione con altri sistemi, in particolare quelli di cui è conosciuta la loro prossima attuazione. Il disegno progettuale dovrà porre in evidenza la correlazione fra i diversi moduli e le loro interfacce. Per l’interfacciamento con i moduli esterni al progetto si dovrà utilizzare degli standard riconosciuti che saranno dichiarati in fase di proposta di progetto.
2.5 Semplicità d’uso della soluzione finale
La facilità di utilizzo dovrà tenere conto delle diverse classi di utenza che utilizzano il sistema e presentare un sistema omogeneo e di utilizzo intuitivo, corredato di help anche contestuale. L’utente avrà a disposizione un’interfaccia grafica evoluta in ambiente Windows con la quale, tramite il mouse, poter accedere a tutti i servizi applicativi secondo gli standard grafici di “Presentation” ormai consolidati. Il software di base sul lato server è a discrezione dell’Impresa, benché siano preferiti in termini di valutazione gli standard “de facto” o comunque gli ambienti più diffusi sul mercato.
2.6 Manutenibilità
Misurabile in particolare dalla chiarezza del disegno progettuale, dalla completezza della documentazione, dalle eventuali certificazioni di qualità, dall’utilizzo di software di base e strumenti di sviluppo ampiamente diffusi o standard de facto.
2.7 Architettura web -based
L’applicativo utilizzerà la rete telematica regionale (RTR), con facilità di distribuzione e aggiornamento: un'applicazione Web si trova interamente sul server, per cui la pubblicazione sul server coincide con la distribuzione e l'aggiornamento ivi effettuato è automaticamente reso disponibile a tutti gli utenti.
2.8 Interfaccia documentale
L’applicativo non dovrà operare direttamente sulla gestione documentale, ma dovrà prevedere interfacce standard, che dovranno essere dettagliate nel progetto, verso altri progetti di gestione documentale in fase di perfezionamento (“Regione Digitale”). Tuttavia al fine di consentire una gestione in assenza di procedure di gestione documentale, dovrà anche essere predisposto un modulo che consenta il trasferimento delle informazioni codificate in un documento di testo. Ad esempio: nella gestione delle determinazioni si provvederà a registrare le informazioni codificate (base-dati) per inserire poi tali informazioni in un template di determinazione, che modificata dall’utente, rimarrà comunque associata alla base dati delle determinazioni.
3. Articolazione dell’appalto
Nell’appalto viene distinta la realizzazione “chiavi in mano” di un applicativo web-oriented e di un web-server con tutto il supporto hardware e software necessario. È comprensivo della sua installazione, dello start- up, dell’avviamento e della formazione. L’appalto è integrato da una serie di prestazioni a consumo, per governare il sistema tenendo conto delle variabili esterne allo stesso. La fornitura si articola nelle seguenti fasi realizzative:
Parte “A”
• Fase 1: fornitura del web server;
• Fase 2: fornitura delle funzionalità principali dell’applicativo;
• Fase 3: fornitura delle funzionalità secondarie ed eventuali funzionalità aggiuntive;
Parte “B”
• Fase 4: “assistenza tecnica” richiesta periodicamente dall’Amministrazione per far evolvere meglio il proprio Sistema Informativo, adeguarlo al mutare delle esigenze al proprio interno e al contorno, tenendo conto di altri progetti in via di realizzazione, garantendo una maggiore integrazione e flessibilità del sistema. Tale assistenza tecnica comprende l’ assistenza operativa, applicativa e sistemistica, la formazione a carattere generale, la manutenzione evolutiva, il caricamento dei dati; temporalmente si estende su tutta la durata del progetto.
Le figure professionali messe a disposizione in quest’appalto per le prestazioni di assistenza tecnica, si intendono, salvo accordo contrario, operanti presso i locali indicati dall’Amministrazione.
Si tratta di una fornitura a consumo, su richiesta, dove l’Amministrazione si impegna a garantire un numero minimo di ore. La fase 4 presenta carattere di complementarietà e arricchimento della fornitura prevista nelle altre fasi, per tener conto di esigenze sopraggiunte del Sistema Informativo della RAS, non prevedibili all’atto di messa in appalto della fornitura, quali evoluzioni di applicativi con cui il SIC si interfaccia. Il progetto-offerta dovrà fornire un prodotto chiavi in mano senza attingere alle risorse della fase 4, che sono invece destinate a gestire l’evoluzione nel tempo del sistema informativo.
II piano di conduzione comprende anche le attività di formazione e di assistenza operativa della fornitura a corpo e va nettamente distinto, dalle attività di assistenza tecnica.
3.1 Piano di lavoro
Nel progetto-offerta andrà specificato il piano di lavoro, con una speciale attenzione al piano di conduzione del progetto, relativamente alla fornitura a corpo dell’appalto.
In particolare dovranno essere specificati un insieme di servizi specificatamente orientati alla formazione del Personale delle Organizzazioni coinvolte a vario titolo nel progetto.
Il piano formativo dovrà prevedere globalmente almeno 800 ore totali di formazione ed assistenza operativa, di cui un congruo numero destinate ad attività di training on the job per il personale che la RAS renderà disponibile, per far loro raggiungere un grado di autonomia sufficiente ad una gestione e conduzione di primo livello del sistema ed al suo utilizzo.
Dovrà essere previsto il necessario affiancamento operativo ai predetti operatori nella fase di start- up ed avviamento del sistema.
Gli interventi di formazione dovranno essere rivolti sia agli Amministratori del Sistema che al personale tecnico e amministrativo assegnato a ciascuna area funzionale ed estesi a tutte le Direzioni interessate al processo di spesa.
L’offerta dovrà contenere modalità alternative ai corsi in aula, così da favorire la formazione dell’utenza finale presso i propri posti di lavoro.
Tutti i corsi dovranno fornire materiale didattico documentale e illustrativo con opportuni riferimenti bibliografici per consentire successivi approfondimenti o recuperi di informazioni in caso di assenze, e dovranno prevedere meccanismi di valutazione dei risultati e di gradimento dei corsi.
L’Impresa nella proposta tecnica dovrà esplicitare tempi, modi e contenuti dei corsi, indicando chiaramente il numero di ore che intende proporre e che non potrà essere inferiore al numero minimo di 800. Il numero di ore dovrà essere ripartito in ore di formazione in aula (minoritaria, da utilizzare principalmente per gli Amministratori di Sistema), di training on the job, assistenza operativa. Il dettaglio delle ore dovrà essere inoltre ripartito per fase, per tipologia dell’intervento e con l’indicazione nominativa di almeno il 90% dei tecnici preposti, che dovranno essere d'elevato profilo ed esperienza professionale e di cui si chiede relativo curriculum formativo e professionale. Tali ore dovranno essere certificate dall’Amministrazione in fase di erogazione, con relativo attestato di gradimento. Non entreranno nel conteggio tutte le attività tecniche che l’Impresa impegnerà senza un coinvolgimento diretto di personale dell’Amministrazione.
La formazione in aula dovrà essere erogata presso le sedi comunicate dall'Amministrazione, comunque dislocate nel comune di Cagliari, e da questa rese disponibili secondo un programma di massima proposto dalla Impresa in fase di offerta, e concordato successivamente con l’Amministrazione nei dettagli.
Si ribadisce che questo piano riguarda le fasi 1, 2 e 3, comprensive di installazione, start-up, caricamento dei dati necessari per i diversi collaudi, avviamento, formazione e assistenza tecnica in garanzia e che tali attività devono essere realizzate autonomamente senza ricorrere all’aus ilio delle ore previste nella fase 4.
4. Fase 1: Fornitura di un Web-server
L’architettura applicativa, per le parti di nuova implementazione, sarà di tipo web-oriented, con una struttura a due o tre livelli e con un Client/Workstation di tipo “Light”. Il client dovrà possedere soltanto un’installazione minimale (Browser WEB) al massimo leggeri plug- in, questo al fine di ottenere delle migliori performances sia in termini di risposta dell’applicazione che di appesantimento del network
L’eventuale presenza di un application server distinto dal data-server, renderebbe più robusta l’architettura del sistema. In ogni caso si richiede di posizionare su due server differenti il web-server e l’application-server.
Le caratteristiche minime richieste per i due server sono le seguenti:
WebServer | Application Server |
CPU: Intel Pentium 4 Xeon 3.06 GHz cache 512Kb Raid: si Connessioni LAN: 3x q0/100/1000 Ethernet Alimentazione ridondata: si Sistemi Operativi: Windows 2003 Server o Linux Red Hat professional 9.0 Occupazione in Rack: 1 Unità Consumo: 180W RAM: 1Gb Dischi: 2x80 Gb Hot Plug SCSI (mirror raid 1) DAT Storage DLT 80 Gb | CPU: Intel Pentium 4 Xeon 3.06 GHz cache 512Kb dual processor Raid: si Connessioni LAN: 3x q0/100/1000 Ethernet Alimentazione ridondata: si Sistemi Operativi: Windows 2003 Server o Linux Red Hat professional 9.0 Occupazione in Rack: 1 Unità Consumo: 180W RAM: 1Gb Dischi: 3x80 Gb Hot Plug SCSI (raid 5) DAT Storage DLT 80 Gb |
I server dovranno comunque essere dimensionati per gestire almeno 100 operazioni di aggiornamento di unità contabili (impegno, liquidazione, mandato, accertamento, riversale) all’ora (con raddoppio nei momenti di punta) e circa 300 utenti massimi potenziali. Dovrà essere prevista l’abilitazione del terminal service su entrambi i server per le manutenzioni e gestioni ordinarie.
In questo documento, come nel capitolato, si farà riferimento genericamente ad un web- server, intendendo l’insieme dell’hardware, degli apparecchi di rete, del software di base necessari ad esplicare le funzioni di web/application/data Server.
L’applicativo del bilancio di previsione dell’Assessorato appaltante, che dovrà dialogare con l’applicativo in appalto, è realizzato in linguaggio Java, per cui tale ambiente di sviluppo sarà quello di riferimento. L’impresa potrà proporre lo sviluppo in altri ambienti, tenendo presente che la valutazione tecnica premierà la diffusione della tecnologia proposta, la sua facilità di manutenzione e la sua capacità di integrazione con l’ambiente esistente.
Si dovrà prevedere inoltre l’acquisto di tutto il software necessario allo sviluppo delle applicazioni, dei servizi e delle funzionalità previste dal progetto, come pure dovrà essere previsto l’acquisto e l’installazione, il setup e la formazione di un Exchange 2003 (per le esigenze interne dell’Assessorato, gestione della posta in sincronia con il CED e gestione intranet documentale interna all’Assessorato); entrambi i software andranno su postazioni (un client e un server) che l’Assessorato della Programmazione, Bilancio, Credito ed Assetto del Territorio metterà a disposizione.
L’insieme del software sviluppato dovrà prevedere una metodologia di modellazione ad oggetti ed utilizzare tecnologie di integrazione attraverso l’utilizzo di interfacce standard.
La fornitura dei prodotti software e hardware dovrà essere comprensiva di licenze, garanzia e manutenzione per 36 mesi “on-site”. Nel progetto tecnico si chiede di disegnare in maniera
esaustiva l’architettura di un web-server e delle componenti software necessarie alle funzioni applicative a cui verrà assegnato, indicate nelle descrizione delle successive fasi e inoltre per:
− connettere il proprio RDBMS con l’RDBMS di un data-base server della Ragioneria, di cui si forniscono in allegato le specifiche tecniche (allegato D1) e lo schema di massima dei collegamenti (allegato D2);
− connettersi con l’RDBMS SqlServer 2000 presso il Server dell’Assessorato della Programmazione, Bilancio, Credito e Assetto del Territorio, contenente la base dati del Bilancio di Previsione.
Si chiede una particolare cura nel garantire la sincronia fra l’RDBMS scelto con l’RDBMS della Ragioneria: l’Impresa non ha vincoli su la scelta dell’RDBMS, purchè si orienti verso una soluzione largamente diffusa, che garantisca buone prestazioni nella sincronizzazione con gli altri DB-Server. Si fa presente che l’elemento critico è rappresentato dal RDBMS della Ragioneria (gestione del bilancio) per il quale la sincronia va garantita in forma assolutamente automatica, mentre è meno critica l’interazione con l’RDBMS dell’Assessorato appaltante, avvenendo solo in determinati periodi dell’anno e con quantità di dati meno rilevanti (bilancio di previsione). Costituirà elemento di valutazione positiva la presenza di un’interfaccia grafica evoluta per una gestione il più possibile estesa del RDBMS (a tal proposito si invita l’Impresa a descrivere la propria proposta nel dettaglio). L’Impresa in sede di offerta dovrà specificare i tipi di collegamento che intende utilizzare per le connessioni DB.
Il server, che sarà gestito dall’Assessorato della Programmazione, Bilancio, Credito e Assetto del Territorio, sarà presumibilmente dislocato presso i locali della Ragioneria, dove è presente il Server della stessa Ragioneria, contenente il DB dei dati del bilancio gestionale. Le altre dislocazioni possibili per il server sono il CED e l’ Assessorato della Programmazione, Bilancio, Credito e Assetto del Territorio. L’Impresa potrà, dopo aver sentito le strutture interessate, proporre una sede diversa per la dislocazione del Server, se questa risultasse debitamente motivata. In fase di realizzazione, l’ Assessorato della Programmazione, Bilancio, Credito e Assetto del Territorio potrà decidere o meno di accogliere la proposta di modifica.
Inoltre, l’Impresa dovrà individuare ed indicare eventuali carenze dell’attuale livello di connettività dell’Amministrazione Regionale per i fini preposti, allegando uno studio sullo stato attuale della connettività che evidenzi le condizioni minime al contorno (hardware, apparati, protocolli e software) perché l’oggetto dell’offerta sia pienamente autoconsistente.
L’offerente dovrà eventualmente proporre delle soluzioni di connettività transitorie, le cui caratteristiche siano atte a soddisfare la domanda di trasmissione dati generata dalle applicazioni e adeguata al carico di lavoro previsto ed integrabile nel progetto relativo alla RTR.
L’offerente dovrà presentare le modalità, le regole e gli standard che definiscono l’architettura di interconnessione del Server web.
L’offerta relativa a questa fase dovrà essere comprensiva di:
• hardware;
• licenze software (a tempo indeterminato);
• almeno una licenza di ogni software necessario per l’ambiente di sviluppo prescelto:
• installazione;
• attività sistemistica sui server;
• attività di formazione sulla gestione sistemistica del web-server (da specificare come numero di ore nel progetto offerta, indicando nominativo e curriculum del docente e da inserire nel piano di conduzione), potranno essere erogate anche dopo il collaudo, ma fino alla loro completa erogazione non si potrà procedere alla fatturazione del 10% finale della fase 1;
• studio sull’adeguatezza delle connettività attuale;
• manuale di gestione del web-server, che dovrà essere consegnato in fase di collaudo
5. Fase 2: realizzazione delle funzioni applicative principali.
Vengono indicati i moduli di massima che devono essere realizzati entro i termini di conclusione della seconda fase. L’Impresa nel progetto-offerta fornirà un dettaglio dei diversi livelli di sottomoduli offerti. L’articolazione in moduli elementari sarà fortemente auspicabille ogni volta che ragioni tecniche (utilizzo di tecniche realizzative differenti) o ragioni di articolazione funzionale lo rendano necessario.
5.1 Caratteristiche generali e modulo per la sicurezza
L’interfaccia utente-sistema deve presentare caratteristiche di estrema semplicità d’uso, di gradevolezza e deve essere basata su web Browser standard.
L’insieme di servizi offerti dovrà essere suddiviso ed organizzato per aree funzionali. L’accesso ad aree informative specifiche ed ai servizi di comunicazione dovrà essere consentito solo all’utenza autorizzata. A tal fine il sistema dovrà prevedere un sistema di gestione degli utenti e di gruppi di utenti il cui obiettivo è quello di fornire un sistema di sicurezza che permetta di realizzare le funzioni di autenticazione ed autorizzazione degli utenti per il controllo degli accessi ai servizi ed ai contenuti del sito, in modo da rendere sicura l’operatività del sistema e di riuscire a controllare eventuali intrusioni nel sistema da parte di utenti non autorizzati.
Per ogni utente o per ogni gruppo di utenti, definiti in profili e/o legati alla posizione in struttura,
nel modo più semplice e flessibile possibile, verrà configurato il diritto di accesso per singola funzione, specificando modalità di accesso (in lettura, in modifica), parzializzando la modifica dei campi consentiti, per un sottoinsieme di dati (ne è un esempio la ripartizione della contabilità per Servizi).
Ogni variazione al contenuto delle autorizzazioni di accesso deve avvenire senza alcuna interferenza sul funzionamento del sistema.
5.2 Sincronia
Dovrà essere garantita la sincronia con il Server della Ragioneria, aggiornando in tempo reale le informazioni in entrambe le direzioni. In fase di collaudo si curerà con particolare attenzione questo specifico aspetto, garantendo la possibilità, con l’application-server funzionante a regime, di assicurare almeno 4 transazioni di aggiornamento al minuto.
5.3 Formazione del Bilancio di previsione (annuale e pluriennale):
5.3.1 Modulo per le singole Direzioni di Servizio
Stato di previsione della spesa
1. l’interfacciamento con le procedure esistenti dovrà muovere dai dati relativi al bilancio annuale e pluriennale in corso che dovrà essere, dunque, riproposto; le Unità Previsionali di Base (UPB) ed i capitoli dovranno comunque essere ulteriormente classificati in relazione alle destinazione programmatica dei fondi iscritti ai medesimi (ad. es: Programma Operativo di Settore, P.O. di comparto, Accordo di Programma Q uadro Stato-Regione, Programma comunitario, Programmazione negoziata, P.O.R., Programma Integrato Territoriale, Programma Integrato d’Area, delibera CIPE etc.);
2. il documento di lavoro a disposizione della Direzione di Servizio è la “Scheda capitolo/S/UPB”, documento di sintesi illustrativo della proposta di bilancio (conferma o variazione stanziamento previsto nel bilancio annuale e pluriennale, differimento stanziamento, proposta di istituzione di nuovo capitolo, ridenominazione e articolazione capitolo, soppressione capitolo etc.);
3. la “Scheda capitolo/S/UPB”, quale documento di sintesi dovrà richiamare in modo agevole gli aggregati di riferimento, riportati in altrettante “schede capitolo” sottostanti, i cui dati, desunti dalla contabilità della Ragioneria Generale ovvero immessi ex novo dalla Direzione del Servizio, debbono essere rappresentativi dei seguenti elementi di gestione (descrizione a titolo esemplificativo):
− residui perenti;
− residui eliminati dalla contabilità per disposizione di legge o per altro titolo;
− ammont are presunto dei residui alla chiusura dell’esercizio in corso;
− quadro storico di sintesi della programmazione precedente, già chiusa a consuntivo;
− correlazione tra stanziamenti annuali e pluriennali e i programmi già approvati (identificazioni programmi in corso e relativa copertura finanziaria annuale e pluriennale);
− stato di attuazione riepilogativo della programmazione in corso (comprensiva dei dati relativi alle erogazioni delle gestioni post bilancio, come quelle correlate a specifici fondi accreditati agli organismi convenzionati con la Regione);
− correlazione tra stanziamenti annuali e pluriennali proposti e i fabbisogni accertati;
− correlazione, in termini di esposizione contabile, tra stanziamenti e vincoli di bilancio (ad es. quantificazione per le ggi di spesa permanente, nuova autorizzazione di spesa, spesa obbligatoria, stanziamenti a destinazione vincolata, stanziamenti legati all’accertamento dell’entrata, stanziamenti condizionati dall’acquisizione di mutui, etc.);
− modifiche al bilancio pluriennale in corso (riduzione, differimento e revoca stanziamenti iscritti al bilancio pluriennale);
− trattamento degli stanziamenti sulla base delle tabelle allegate alla legge finanziaria regionale.
Stato di previsione dell’ entrata
1. l’interfacciamento con le procedure esistenti, unitamente all’implementazione delle stesse, deve consentire di evidenziare i dati di gestione del capitolo (anno del residuo, causale, importo accertato, importo da riscuotere, previsioni mensili di cassa) nell’apposita “Scheda capitolo”,
2. la “Scheda capitolo”, quale documento di sintesi dovrà richiamare in modo agevole gli aggregati di riferimento, riportati in altrettante “Schede capitolo/E/UPB” sottostanti, i cui dati, desunti dalla contabilità della Ragioneria Generale ovvero immessi ex novo dalla Direzione del Servizio, debbono essere rappresentativi dei seguenti elementi di gestione (descrizione a titolo esemplificativo):
− residui eliminati dalla contabilità per disposizione di legge o per altro titolo;
− ammontare presunto dei residui alla chiusura dell’esercizio in corso;
− collegamento del capitolo con le fonti finanziarie del residuo attivo (ad es.: capitolo del Ministero o fonte comunitaria, codici tributi propri, conti correnti c/o tesoreria Stato etc.) di modo da agevolarne l’imputazione;
− validazione importo residuo attivo da riscuotere: stato del procedimento di rimborso di fondi statali e comunitari in caso di richiesta di rimborso inoltrata (modalità di
rendicontazione richiesta per il rimborso, estremi richiesta di rimborso, importo, estremi risposta organismo nazionale o comunitario, monitoraggio della spesa correlata all’accertamento dell’entrata etc.) o da inoltrare (motivi della mancata richiesta, attività istruttoria in corso per la presentazione della richiesta di rimborso).
Sia dal lato spesa che dal lato entrata deve essere posta una grande attenzione nel fornire strumenti che agevolino una corretta classificazione del bilancio secondo le classificazioni esistenti:
▪ per UPB (TITOLO, Ambiti, Xxxx Xxxxxxxx);
▪ per Capitolo (Fonte, Onere, Codice Ministeriale (titolo, categoria economica, voce economica, settore di intervento, sezione, aggregato economico), Codice Patto stabilità, Codice UE);
e ad altre eventuali classificazioni proposte dall’Impresa.
In particolare, sarà gradita la possibilità di richiamare le fonti normative del capitolo con rimandi al contenuto del testo normativo e di visualizzare una scheda che evidenzi gli effetti economico- finanziari che il testo normativo produce.
5.3.2 Modulo per le Direzioni Generali
Le Direzioni Generali costituiscono l’interfaccia diretta dell’Assessorato del Bilancio in termini previsionali e programmatici, e necessitano di disporre dei dati d’insieme delle varie UPB. Le DG, hanno minori esigenze operative ma maggiori esigenze di visione direzionale, con reporting aggregati a livello di DG o disaggregati, a livello di Servizi.
Partendo dai moduli a disposizione per ciascuna Direzione di Servizio (U.P.B.) dovrà quindi prevedersi l’aggregazione dei dati delle diverse U.P.B. in un quadro riassuntivo delle entrate e delle spese per Direzione Generale - Assessorato per il conseguente interfacciamento con la Direzione Generale del Bilancio.
5.3.3 Modulo per la Direzione Generale dell’ Xxx.xx della Programmazione, Bilancio, Credito e Assetto del Te rritorio
L’obiettivo di una efficace e puntuale attività di programmazione del fabbisogno regionale assume importanza fondamentale al fine di assicurare alla Regione, nei tempi previsti, le risorse dovute dallo Stato, considerato che il Ministero dell’Economia e delle Finanze subordina l’erogazione delle quote di devoluzione ai tributi statali e dei trasferimenti spettanti alla Regione, in relazione al livello previsto, mensile ed annuale, della spesa regionale.
L’Impresa dovrà prevedere una procedura che consenta di inserire in rete e di effettuare l’analisi dei bilanci consuntivi regionali dagli anni dal 1984 al 2003, permettendo non solo di ricostruire l’entità e la composizione dei risultati finanziari, ma anche di individuare le principali cause che li hanno determinati.
La procedura di monitoraggio di tutte le entrate e spese regionali dovrà consentire la verifica dell’andamento delle stesse in conformità alle previsioni indicate e agli obiettivi previsti nei documenti contabili e di programmazione economico-finanziaria.
L’interfacciamento con le Direzioni Generali degli Assessorati deve consentire, quanto al bilancio annuale e pluriennale:
− l’aggregazione dei quadri riassuntivi delle entrate e delle spese per Assessorato in un quadro generale dell’entrata e della spesa;
− l’aggregazione degli stati di attuazione degli Assessorati in un quadro riepilogativo storico e tematico strutturato almeno secondo “ambiti di bilancio” e relative “aree omogenee”;
− la messa a disposizione delle Direzioni Generali dei dati preliminari di bilancio sulla base della dotazione finanziaria complessivamente disponibile;
− la proposta assestata degli Assessorati sulla base della dotazione finanziaria agli stessi definitivamente assegnata;
− la definizione da parte dell’Assessorato del Bilancio del quadro finale degli stati di previsione, annuali e pluriennali, dell’entrata e della spesa e contestuale messa a disposizione delle Direzioni Generali degli Assessorati del dato finanziario.
Il quadro generale dell’entrata e della spesa, a carattere annuale e pluriennale, dovrà essere strutturato di modo da garantire:
− la corrispondenza tra i dati del quadro generale e i dati di riferimento nonché l’esatta interrelazione tra i dati stessi;
− la classificazione dei dati di bilancio che partendo dai codici di classificazione del bilancio presso il sistema della Ragioneria Generale li integri con codici suppletivi rappresentativi della destinazione programmatica dei fondi iscritti ai capitoli di bilancio (ad. es: Programma Operativo di Settore, P.O. di comparto, Accordo di Programma Quadro Stato-Regione, Programma comunitario, Programmazione negoziata, P.O.R., Programma Integrato Territoriale, Programma Integrato d’Area, delibera CIPE, etc.).
− il controllo, nel corso dell’esercizio, dei fatti di gestione che hanno diretta rilevanza con i vincoli di bilancio (gestione fondi di riserva e fondi speciali, controllo flussi di cassa, controllo limiti impugnabilità somme, variazioni di bilancio correlate all’accertamento dell’entrata etc.);
− La verifica periodica, a livello mensile, dell’andamento del livello delle entrate e delle spese regionali e del rispetto dei limiti stabiliti dal Patto di stabilità interno, con un sistema informativo di codifica di tutti i capitoli del bilancio regionale, secondo le classificazioni economiche individuate dal Ministero dell’Economia e delle Finanze.
5.4 Variazione del Bilancio
La procedura dovrà essere articolata in modo da consentire il dialogo Direzione Generale Xxxxxxxx/Direzioni Generali in ragione delle diverse procedure adottate per l’assestamento di bilancio.
Dovrà essere infatti prevista una procedura a esclusivo utilizzo dell’Assessorato della Programmazione, Bilancio, Credito e Assetto del Territorio che provvederà a definire la proposta finale di assestamento ad iniziativa propria o su iniziativa della Direzioni Generali: la gestione della fasi della procedura saranno compendiate in apposita “Scheda capitolo/Bilancio” i cui dati (variazioni definitive apportate con provvedimento legislativo o amministrativo) verranno immessi nel sistema e acquisiti alla pertinente “Scheda capitolo/S/UPB” a disposizione delle Direzioni dei Servizi/Responsabili di U.P.B/Ragioneria Generale.
Una seconda procedura gestirà invece le variazioni di bilancio disposte con atti amministrativi degli Assessorati competenti: anche tali variazioni saranno compendiate nell’apposita “Scheda
capitolo/S/UPB” i cui dati (variazioni definitive apportate con provvedimento amministrativo) verranno immessi nel sistema e acquisiti alla pertinente “Scheda capitolo/Bilancio” a disposizione della Direzione Generale del Bilancio//Ragioneria Generale.
Nella progetto-offerta si dovrà considerare la presenza dell’attuale procedura di gestione del Bilancio di Previsione, presso l’Assessorato della Programmazione, Bilancio, Credito ed Assetto del Territorio.
5.5 Gestione del Bilancio
L’area comprende sostanzialmente le funzioni per l’emissione degli atti di accertamento, riscossione e versamento dell’entrata, di impegno, liquidazione e pagamento della spesa da parte dell’Amministrazione e per le successive registrazioni da parte della Ragioneria Generale.
Gli atti adottati dai dirigenti, ai sensi dell’art.21 della L.R. 31/98, sono denominati “determinazioni”.
Per gli atti che presentano effetti sulla contabilità regionale si deve predisporre l’interfaccia contabile, che si perfeziona durante le diverse fasi di gestione procedurale documentando il raggiungimento di ciascuna soglia di definizione prevista, che consenta di emettere la relativa determinazione (si veda anche 6.3 “gestione delle determinazioni”).
Il sistema deve assicurare la correlazione automatizzata tra emissione del provvedimento e ricezione dello stesso da parte della Ragioneria Generale: in particolare dovrà essere possibile trasmettere in via informatica i dati salienti del provvedimento (dati identificativi, oggetto, importo, capitolo, modalità di accredito, etc.) in una maschera condivisa dalla Ragioneria Generale di modo che gli stessi siano esattamente trasferibili al sistema contabile della Ragioneria.
Il dato di gestione comprenderà la fase della “prenotazione di impegno” - ovvero dell’impegno in corso di formazione - per tutte le fattispecie di gestione che comportano l’attivazione di procedure contrattuali (ad es. bandi di gara o deliberazioni a contrattare) o di procedure ad evidenza pubblica per la concessione di aiuti al settore produttivo per le quali sia necessario mantenere l’iscrizione delle somme in bilancio allo scadere dell’esercizio.
Il sistema dovrà garantire la registrazione delle clausole di apertura / variazione dei provvedimenti a rilievo finanziario e rendere disponibili funzioni per variare o annullare una determinazione non definitiva, per visualizzare le informazioni memorizzate e per richiedere la stampa in formato di foglio notizie.
Una particolare attenzione dovrà essere posta nel mettere a disposizione degli strumenti che facilitino e guidino l’utente verso una puntuale indicazione delle informazioni riguardanti la localizzazione della spesa e, laddove ciò non sia possibile, portando l’utente a lavorare per eccezione, con l’inserimento di opportune motivazioni che giustifichino l’eventuale assenza di tale informazione.
L’area dovrà inoltre comprendere un’appropriata anagrafica dei creditori dell’Amministrazione regionale facenti parte del c.d. “settore pubblico allargato” (comuni, province, consorzi, comunità montane, enti regionali distinti anche per aree territoriali omogenee) al fine di costituire una prima carta degli utenti pubblici della Regione che esponga i dati dei finanziamenti agli stessi attribuiti.
Dovrà altresì prevedere l’anagrafica generale dei debitori e creditori, imprese e persone fisiche, con i dati dei pagamenti effettuati o percepiti, la causale e la localizzazio ne per comune e provincia (queste ultime appositamente codificate).
5.6 Obiettivi della fase 2
Gli obiettivi prioritari dell’appalto, ed in particolare della fase 2, sono quelli di garantire la chiusura del ciclo contabile Direzioni- Ragioneria-Assessorato della Programmazione, Bilancio, Credito e Assetto del Territorio in tutti i momenti di vita del ciclo contabile ed in particolare:
- bilancio di previsione entrata/uscita;
- impegno/accertamento;
- liquidazione /riscossione;
- mandato/reversale.
5.7 Collaudo Prototipo fase 2
Al fine di verificare per tempo la buona realizzazione dell’applicativo, si introduce un collaudo intermedio applicato al semi- lavorato, prototipale della soluzione finale. Le caratteristiche minime richieste saranno quelle di:
▪ garantire la sincronia della base dai contabile con il Server della Ragioneria;
▪ garantire il flusso del bilancio di previsione fra DG e Xxx.xx della Programmazione, Bilancio, Credito e Assetto del Territorio, nella sua forma essenziale (scheda UPB/capitolo contenente classificazione dei capitoli ed UPB, stanziamenti previsti e previsioni di cassa);
▪ garantire il flusso di gestione del bilancio di spesa, fra DG e Ragioneria, almeno nelle sua forma essenziale (generazione di un flusso di impegni, liquidazioni e pagamenti che si interfaccia con il S.I. della Ragioneria e ricezione delle informazioni relative all’avvenuta registrazione degli impegni, e dei dati provenienti dalla Tesoreria).
E’ facoltà dell’Impresa proporre ulteriori obiettivi intermedi (che si tramuteranno in vincoli contrattuali) e che serviranno a comporre uno dei criteri di valutazione previsti per l’offerta tecnica. Eventuali carenze prestazionali evidenziate dal collaudo del prototipo, rimetteranno in discussione anche l’esito del collaudo del web-server, consentendo all’Amministrazione di richiedere un potenziamento del sistema.
5.8 Collaudo fase 2
A differenza del collaudo del prototipo, che verte su dati di prova, il collaudo finale dovrà essere effettuato su dati reali, secondo le modalità indicate ne l Capitolato d’oneri. Durante il collaudo l’applicazione verrà verificata funzionalmente rispetto alle specifiche del progetto offerta e agli obiettivi dell’Amministrazione. La verifica non verterà solamente sugli aspetti qualitativi, ma anche su quelli quantitativi. Si chiederà all’Impresa di garantire in fase di collaudo e per un periodo di 10 gg lavorativi continuativi, stabiliti dalla Commissione di collaudo all’interno del periodo dedicato al collaudo, la gestione informatica di almeno il 15% di tutti gli impegni e mandati e il 15% degli accertamenti e reversali effettivi prodotti dalle diverse Direzioni Generali e dalla
Ragioneria Generale. Si richiede inoltre che la gestione del bilancio di previsione (interscambio bidirezionale fra Xxx.xx della Programmazione, Bilancio, Credito e Assetto del Territorio e le altre Direzioni Generali) avvenga per almeno il 50% delle Direzioni Generali.
Il collaudo sul modulo di bilancio di previsione, su richiesta dell’Amministrazione, potrà essere anticipato sino alla data prevista per il collaudo del prototipo, al fine di consentire la coincidenza con i tempi di predisposizione del bilancio regionale. Questa verifica pertanto potrà ricadere in un periodo diverso dal periodo dedicato formalmente al collaudo, i suoi risultati comunque verranno analizzati solo durante l’effettivo collaudo.
I risultati indicati potranno ottenersi sia con l’utilizzo delle risorse di ogni singola Direzione Generali, o qualora queste per qualsiasi ragione non fossero disponibili, con le risorse dell’Impresa, utilizzando esclusivamente la procedura che si intende rilasciare, ed in maniera totalmente automatica, senza operazioni aggiuntive che debbano essere svolte da tecnici dell’Impresa.
L’Impresa dovrà confermare tali obiettivi minimi o fornire delle soglie più elevate che contribuiranno a determinare il punteggio assegnato alla voce livello e la qualità dei risultati, secondo il seguente schema:
• per la gestione del bilancio, ogni 5 punti percentuali offerti dall’Impresa sopra il 15% danno diritto a 0,3 punti sino ad un massimo di 5 punti;
• per la previsione di bilancio, ogni DG di cui si propone di gestire pienamente il bilancio di previsione dà diritto a 0,25 punti, sino ad un massimo di 4 punti;
• il rimanente punto verrà assegnato, a discrezione della Commissione per eventuali proposte delle Imprese di cui si dovesse valutare la congruità con gli obiettivi preposti.
Cumulativamente i punti dati non potranno superare i 10 punti previsti per tale voce.
6. Fase 3: realizzazione delle funzioni applicative secondarie e di quelle aggiuntive
In questa fase verranno realizzate alcune funzionalità applicative, definite secondarie in quanto, pur ad alto valore aggiunto, necessitano per il loro funzionamento della realizzazione delle funzionalità primarie. Sono indicate inoltre alcune funzionalità aggiuntive e opzionali, suggerite alla ditta, ma non richieste espressamente. A questa lista l’Impresa potrà allegare ulteriori moduli funzionali che ritiene complementari al progetto ed utili per l’Amministrazione. La loro offerta sarà analizzata in fase di valutazione tecnica, al punto proposte di funzionalità aggiuntive. La valutazione verterà sull’utilità della funzione, sul suo grado di dettaglio che dovrà essere ampiamente documentato e sul grado di integrazione con il resto del sistema.
La funzionalità secondarie sono:
▪ il monitoraggio finanziario e procedurale;
▪ la contabilità analitica;
▪ la gestione delle determinazioni.
Fra le funzionalità opzionali citiamo:
- il monitoraggio fisico;
- la gestione dei progetti;
- il collegamento tra DPEF e Bilancio di previsione;
- la creazione di una intranet documentale, e l’utilizzo avanzato del prodotto MS Exchange 2003 per le esigenze interne dell’Assessorato della Programmazione, Bilancio, Credito ed Assetto del Territorio;
- la creazione di un datawarehouse per le esigenze di analisi e di monitoraggio dell’Assessorato della Programmazione, Bilancio, Credito e Assetto del Territorio;
- la creazione di una intranet per l’Assessorato della Programmazione, Bilancio, Credito e Assetto del Territorio, per la pubblicazione e condivisione dei documenti contabili;
- la rappresentazione del Bilancio d’Area;
- un modello sperimentale di bilancio sociale della Regione Sardegna.
6.1 Monitoraggio finanziario e procedurale
L’obiettivo del monitoraggio è volto a ricostruire il quadro delle politiche di sviluppo regionale nella logica del “ciclo unico” della programmazione.
Il modulo di gestione del bilancio per le singole Direzioni di Servizio sarà strutturato in modo tale da poter registrare anche i dati relativi al monitoraggio finanziario analitico, procedurale e fisico, in un percorso parallelo ma strettamente interconnesso a quello contabile finanziario, per ciascuna fase di avanzamento dell’attività gestionale.
Tali dati di monitoraggio dovranno poter essere visualizzati in modo automatizzato in specifiche schede di report ordinate per programma, per misura, per progetto e/o intervento, .
Nell’ambito del monitoraggio si tenderà ad estendere all’intero spettro delle spese d’investimento, ivi compresi gli interventi statali e gli strumenti di programmazione negoziata, le modalità di rilevazione e raccolta dei dati proprie dei programmi comunitari, di supporto alle fasi della programmazione, del controllo e della valutazione.
Vale come modello di riferimento non esclusivo la procedura di monitoraggio Monit Web utilizzata per il monitoraggio del P.O.R. 2000-2006, riconducendo la struttura attuale del bilancio regionale al modello dei programmi operativi: l’impostazione comunitaria a cascata, basata sul Quadro Comunitario di Sostegno, sul Programma Operativo Regionale, sugli assi, sui
sottoprogrammi, sulle misure, sulle azioni e sui progetti e/o interventi, andrà riproposta a partire dalle aree d’intervento strategiche previste nel DPEF regionale e dall’articolazione di questo in livelli primario (le politiche prioritarie) e secondario (gli ambiti settoriali), individuando quindi i centri di responsabilità a livello di Direzione generale o di Servizio; questi ultimi andranno ricondotti alle Unità Previsionali di Base, impostate per funzioni obiettivo, mentre ai capitoli di spesa faranno capo i programmi operativi formati da azioni, progetti e/o interventi. Questi ultimi, a loro volta, potranno essere monitorati singolarmente, come avviene su Monit Web per le azioni ed i progetti individuati all’interno delle singole misure, per mezzo delle fatture o dei documenti contabili equivalenti.
Nel presente progetto si fa riferimento unicamente ai dati caricati dagli utenti interni all’amministrazione regionale; no n è previsto pertanto l’afflusso diretto di dati provenienti da
operatori di altri enti esterni, compresi quelli strumentali.
Il monitoraggio delle spese effettuate “a valle” da tali enti nell’ambito delle attività di gestione conseguenti a trasferimenti di fondi regionali (sia direttamente, come soggetti beneficiari finali, sia in qualità di soggetti intermedi), nonché da eventuali ulteriori livelli sottostanti, potrà rientrare nel SIC nelle 2 seguenti modalità: o con caricamento diretto dei dati da parte degli operatori delle Direzioni di servizio, o con trasferimento da altre procedure di monitoraggio, ma sempre nell’ambito dell’intranet dell’amministrazione regionale, per cui il modulo applicativo dovrà prevedere le due modalità di acquisizione dati.
L’impresa dovrà curare in modo particolare i punti e le modalità di collegamento fra la contabilità finanziaria e le rilevazioni analitiche di costo-ricavo, considerando quale momento di
sostenimento del costo quello della registrazione della fattura e/o della liquidazione (manifestazione numeraria) e, quale momento in cui si sostanzia il ricavo, la registrazione dell’atto che rende matura la riscossione dell’entrata.
Sarà introdotta pertanto nel modulo di gestione del bilancio per le singole Direzioni di Servizio l’interfaccia di un documento di certificazione dei ricavi e dei costi rilevati con le modalità sopra indicate, ai fini dell’introduzione di elementi della contabilità analitica (attualmente non disciplinati dalla normativa regionale di contabilità).
La struttura del sistema sarà impostata in modo tale che i dati rilevati rendano possibile l’introduzione nell’amministrazione regionale, integrato col vigente sistema di contabilità finanziaria previsto dalla legge regionale n. 11 del 1983, di un sistema di contabilità analitica, come definito dall’art.2 L.R. n. 3 del 2003, al fine di favorire la valutazione periodica di cui al comma 5 dell’articolo 9 della legge regionale 13 novembre 1998, n. 31, e di svolgere analisi economiche per centro di costo, inerenti l’attuazione del controllo di gestione di cui all’articolo 10 della medesima legge regionale n. 31/98.
Allo stato attuale, pur in previsione di una utile estensione del sistema, demandata all’attuazione del comma 4 dell’articolo 2 della citata L.R. n. 3 del 2003, ci si dovrà limitare a consentire la rilevazione dei “momenti del costo e del ricavo ” secondo le tecniche della partita semplice, in base a quanto suggerito dal Decreto del Ministero dell’Economia e delle Finanze n.136587 del 30 Dicembre 2002 e dal DPR 97/2003 che detta la regolamentazione della contabilità e dei bilanci degli enti del settore pubblico allargato.
L’organizzazione del modulo di competenza dei Responsabili di Servizio sarà ordinata in due percorsi paralleli: Gestione e Monitoraggio, e dovrà consentire di tenere separata la gestione contabile finanziaria sull’asse Direzioni di Servizio-Direzioni Generali- Ragioneria rispetto al percorso del monitoraggio e dell’analisi che avverrà sull’asse Direzioni di Servizio-Direzioni Generali- Assessorato della Programmazione (la fase di ritorno in entrambi i casi andrà invece a beneficio di tutti gli attori del processo).
L’area monitoraggio farà riferimento anche all’anagrafica dei debitori e dei creditori, vista nella fase 2. E’ richiesto ino ltre un’importante funzione di monitoraggio, da dedicare alla gestione
dei flussi finanziari di cassa, da alimentare in futuro con l‘interfacciamento verso le Tesorerie (Regionale e Statale) e verso gli Istituti di Credito, gestori di Fondi di Rotazione, etc.
Si ricorda che, all’interno del modulo monitoraggio, la parte di monitoraggio fisico rientra fra le funzionalità opzionali che l’Impresa può proporre.
6.2 Contabilità analitica
Gli obiettivi che si vogliono raggiungere sono quelli di :
• disporre di informazioni economiche e finanziarie sulla gestione, sia a preventivo e sia a consuntivo, al fine di poter svolgere analisi di efficienza economica e di economicità nel ciclo di definizione di obiettivi - risorse - responsabilità;
• specializzare ulteriormente le analisi di spesa per consentire la determinazione dei costi sotto il duplice aspetto della natura e della destinazione dei fattori produttivi impiegati nei processi produttivi in senso lato, fornendo una diversa chiave di lettura delle informazioni derivanti dal sistema contabile in uso, tipicamente orientate ai processi di carattere autorizzatorio della spesa;
• produrre informazioni in cui trova concreta applicazione il criterio di competenza economica d’imputazione dei costi nell’ottica di quantificare il valore delle risorse consumate nei processi;
• articolare le informazioni economiche riferite all’intera amministrazione regionale per Assessorato/Direzione Generale, per Centro di Responsabilità, per Centro di costo;
• disporre di informazioni economiche tempestive (annuali ed infrannuali) attraverso tecniche contabili mirate a determinare in modo corretto eventuali elementi mancanti o di difficile determinazione, in considerazione delle novità introdotte dal sistema di misurazione in esame;
• consentire ai centri di spesa di procedere ad un’efficace azione di autocontrollo e di corretta allocazione delle risorse in sede di formulazione delle proposte di bilancio (budget), previa identificazione di obiettivi e programmi.
Il raggiungimento degli scopi evidenziati nei punti precedenti implica la realizzazione concreta di un sistema di rilevazione delle operazioni gestionali denominato Contabilità economico analitica.
La soluzione individuata è vincolata all'impianto contabile esistente e alla relativa scarsità di dati di costo, pertanto è stato deciso di adottare le seguenti semplificazioni:
• assunzione del principio in base al quale si riconosce la coincidenza tra acquisto e consumo (assenza di magazzino contabile), considerando quale momento di sostenimento del costo il momento della registrazione della fattura e/o della liquidazione (manifestazione numeraria);
• mancata imputazione degli ammortamenti, in quanto non si dispone di un inventario a quantità e valore, aggiornato sistematicamente con acquisizioni e dismissioni;
• mancata imputazione di scritture di rettifica e d’imputazione (ratei, risconti, etc.);
• utilizzo di un piano dei conti semplificato.
Quanto descritto precedentemente può essere dettagliato descrivendo un modello dei costi
che il Sistema Informativo vuole realizzare, costituito dai seguenti elementi:
6.2.1 Piano dei conti
Il piano dei conti è un elenco di “archivi contabili” e serve per “classificare” i diversi costi sostenuti da un’amministrazione “per natura” (personale, energia, materiali di consumo, eccetera). Ciascuna voce del piano dei conti corrisponde in pratica a un archivio in cui vengono raccolti i costi della risorsa corrispondente in un dato periodo di tempo.
6.2.2 Piano dei centri di costo
Il Centro di Costo consente di definire l’unità organizzativa alla quale sono attribuiti i costi in funzione dell’utilizzo delle risorse.
Il Piano dei Centri di Costo della Regione è basato sulla sua struttura organizzativa: è stato individuato un Centro di Costo per ogni Servizio. La struttura del Piano dei Centri di costo è quindi articolata su quattro livelli:
• Regione;
• Assessorato;
• Direzione Generale;
• Servizio.
Inoltre, potrebbe essere necessario definire alcuni Centri “fittizi” che non si riferiscono a entità organizzative reali, ma consentono l’aggregazione di elementi organizzativi ed economici a livelli di sintesi maggiore (vedi oltre Ribaltamento).
La scelta, imposta dalla norma vigente, è anche motivata dalla necessità di:
• fornire ai singoli responsabili delle Direzioni la possibilità di valutare le risorse a loro disposizione;
• valutare l’efficienza, l’efficacia e l’economicità dei Servizi che gestiscono;
• agevolare la valutazione del personale con incarico dirigenziale.
Lo schema generale di alimentazione del sistema informativo è il seguente:
• Costi del personale. L’attribuzione dei costi del personale viene effettuata rielaborando le informazioni della banca dati del personale. L’alimentazione dalla base dati del personale non è oggetto di questo appalto. I costi del personale rappresentano una parte notevole dei costi totali di funzionamento della Regione, di conseguenza è necessaria una particolare cura nella determinazione ed allocazione di tali nature di costo: anche per questo motivo si è optato per una logica di “costo effettivo” del personale piuttosto che una logica a “costi standard”. I costi del personale vengono resi disponibili già articolati per natura e centro di costo.
• Altri costi. L’inserimento delle informazioni relative alla natura del costo viene effettuato direttamente dal Servizio che gestisce l’acquisto. L’attribuzione ai Centri di Costo presenti in Regione viene effettuata:
o se il costo è rilevabile a livello di Centro di Costo, direttamente dal Servizio stesso o dal Servizio che effettua l’acquisto per quel Centro di Costo (costi dire tti). In questo caso la destinazione del costo viene imputata direttamente senza necessità di ribaltamenti;
o se il costo non è direttamente rilevabile a livello di Centro di Costo (costi indiretti), l’attribuzione avviene tramite driver di ribaltamento;
o la gestione dei progetti.
6.3 Gestione delle determinazioni
Unicamente a titolo di esempio, si riporta una scomposizione in termini di attività principali che compongono la gestione delle determinazioni, secondo uno studio operato dalla Direzione Generale “Enti Locali e Finanze”:
AZIONE | SOGGETTO | NOTE |
1 - Predisposizione della determinazione | Responsabile del procedimento | Nel frontespizio dell’atto devono essere indicati: a) data;b) codice; c) oggetto |
2 - Firma della determinazione | Dirigente competente | |
3 - Richiesta di registrazione della determinazione | Responsabile del procedimento | Una copia del file contenente il testo, e degli eventuali allegati, viene salvata nella cartella “DG – Servizio ………”. Al fine di garantire l’ordine cronologico, ciascun file deve essere così denominato: a) data (formato aa/mm/gg); b) codice; c) sintesi oggetto |
4 - Operazioni preliminari alla registrazione | Responsabile della tenuta del Registro telematico | L’operatore: a) preleva il file e lo salva in una apposita cartella temporanea, nel proprio PC; b) lo apre e ne stampa la prima pagina |
5 - Registrazione della determinazione | Responsabile della tenuta del Registro telematico | La registrazione avviene con l’inserimento nel registro di: numero progressivo (formato 0000), codice, oggetto e relativo codice di classificazione |
6 - Inserimento del numero della determinazione nel frontespizio del testo | Responsabile della tenuta del Registro telematico | L’inserimento determina la conseguente modifica del file |
7 - Salvataggio del file contenente il testo della determinazione | Responsabile della tenuta del Registro telematico | L’operatore salva il file nella cartella “DG – Registro Determinazioni”, cui tutti possono accedere soltanto per la lettura e la stampa delle determinazioni |
8 - Prelevamento della determinazione registrata | Responsabile del procedimento | La copia del file, modificata per effetto della registrazione, viene ricercata nella cartella condivisa (vedi fase n. 7), per essere salvata nell’archivio digitale . |
9 –Trascrizione del numero nell’originale cartaceo della determinazione. | Responsabile del procedimento | La trascrizione viene effettuata manualmente, successivamente al salvataggio del file (vedi fase n. 8) |
10 - Deposito dell’originale, in formato cartaceo, per l’inserimento nella “Raccolta delle determinazioni” | Responsabile del procedimento | Presso l’ufficio incaricato, entro 2 giorni lavorativi dalla registrazione |
11 – Trasmissione determinazioni alla D.G. | Responsabile del procedimento | I files relativi sono salvati in copia nella cartella creata sul server, immediatamente dopo la registrazione ed in ogni caso entro il lunedì per le determinazioni della settimana precedente |
12 – Adempimenti ex D.A. 434/2002 (art. 21, c. 9, LR 31/1998) | Direttori dei Servizi | Via e-mail, ogni lunedì, comunicano al D.G. numero-data-oggetto delle determinazioni della settimana precedente |
13 - Trasmissione delle determinazioni registrate all’Assessore | Responsabile della tenuta del Registro telematico | Via e-mail, ogni martedì, per le determinazioni della settimana precedente |
14 – Conservazione delle determinazioni anno per anno |
Nello studio si suggerisce una fase successiva di monitoraggio e una di “pubblicazione” nel sito dell’Amministrazione.
6.4 Gestione dei progetti
Modulo opzionale che l’Impresa può proporre, relativo ai progetti attuati direttamente dall’Amministrazione Regionale; da integrare con il monitoraggio procedurale e con l’eventuale monitoraggio fisico.
6.5 Collegamento DPEF e Bilancio di Previsione
Ad estensio ne del modulo di previsione del Bilancio, l’Impresa può proporre un modulo che consenta di trasformare gli obiettivi misurabili del DPEF in una proposta di Xxxxxxxx.
6.6 Intranet documentale
Secondo un progetto opzionale che l’Impresa può proporre, con un utlizzo avanzato di MS Exchange 2003 per l’implementazione di servizi collaborativi (newsgroup, community documentale sulla intranet, messaggistica istantanea, calendari condivisi, gestione delle proprie cassette di posta via web, agende condivise etc.). In particolare la creazione di una Intranet documentale è finalizzata a rispondere alle esigenze interne dell’Assessorato proponente, legate alla predisposizione di documenti di natura contabile.
6.7 Datawarehouse
Modulo opzionale che l’Impresa può proporre, la progettazione e la realizzazione di un datawarehouse orientato all’Analisi della Finanza Regionale.
6.8 Gestione del Bilancio d’Area
L’Impresa può far riferimento ai documenti prodotti dalla Direzione Generale della Programmazione, Bilancio, Credito e Assetto del Territorio - Servizio Verifica della Programmazione di Spesa (visibili anche nel sito dell’Amministrazione regionale).
6.9 Modello sperimentale di bilancio sociale della Regione Sardegna
Sono ormai diverse le amministrazioni pubbliche che hanno realizzato esperienze di “rendicontazione sociale” in affiancamento alla tradiziona le rendicontazione finanziaria. Tali esperienze nascono dall’esigenza di rappresentare i risultati dell’azione amministrativa in una logica di maggiore trasparenza verso il territorio e secondo logiche di rappresentazione dei risultati conseguenti alle politiche pubbliche sviluppate.
Il modello può essere proposto attraverso una focalizzazione di finalità, oggetto e confini di tale strumento, a partire dalle esperienze realizzate e proponendone una lettura integrata con il sistema complessivo di “governo dell’amministrazione” (pianificazione strategica, rendicontazione e comunicazione), attraverso la presentazione di concrete soluzioni, strumenti e percorsi utili alla progettazione e realizzazione del Bilancio Sociale.
6.10 Obiettivi della fase 3
Gli obiettivi della fase 3 sono quelli di concludere la fornitura applicativa garantendo il buon funzionamento degli strumenti di gestione delle determinazioni, con una completa integrazione sul piano contabile, la gestione dei Centri di Costo e a livello di direzione generale e dell’ Assessorato della Programmazione, Bilancio, Credito e Assetto del Territorio la disponibilità di strumenti di reporting e di monitoraggio a diversi livelli.
6.11 Collaudo Prototipo fase 3
Al fine di verificare per tempo la buona realizzazione dell’applicativo, si applica anche in questa fase un collaudo intermedio applicato al semi- lavorato, prototipale della soluzione finale. Le caratteristiche minime richieste saranno concordate fra l’Amministrazione e l’Impresa, che fornirà la sua proposta in fase di offerta.
6.12 Collaudo fase 3
Questo collaudo sarà quello finale della fornitura, sarà articolato, come il collaudo della fase 2, in unit-test e system-test e riguarderà il funzionamento del sistema nel suo complesso, quindi compreso il contenuto delle precedenti fasi, soprattutto in fase di system- test.
7. Fase 4: Assistenza tecnica su richiesta
L’assistenza tecnica, a differenza delle altre fasi, dove la fornitura è chiavi in mano, è orientata ad esigenze future, a far evolvere meglio il proprio Sistema Informativo, adeguarlo al mutare delle esigenze al proprio interno e al contorno, tenendo conto di altri progetti in via di realizzazione, garantendo una maggiore integrazione e flessibilità del sistema. Tale assistenza comprende l’assistenza operativa (distinta da quella che verrà proposta nelle prime tre fasi fasi), l’assistenza applicativa e sistemistica, la formazione a carattere generale, la manutenzione evolutiva, il caricamento dei dati. Da un punto di vista temporale si estende su tutta la durata del progetto.
Di seguito vengono elencate le professionalità per le quali l’Impresa dovrà fornire dei curricula:
- Analista funzionale: laureato, con competenze almeno quinquennale in analisi di processi informatici, ottima conoscenza della contabilità finanziaria ed economica-analitica;
- Analista programmatore: in possesso di diploma, competenza almeno biennale nella programmazione web-based, negli strumenti scelti dalla Impresa appaltante, buone competenze in materia contabile, in grado anche di fornire un supporto operativo sulle applicazioni erogate;
Programmatore: in possesso di diploma, competenza almeno annuale nella programmazione web-based, negli strumenti scelti dalla Impresa appaltante;
- Consulente esperto in monitoraggio finanziario e contabilità analitica: laureato in materie economiche con esperienza almeno decennale di consulenze significative nell’ambito della PPAA.
- Amministratore di sistema: laureato, con competenze almeno quinquennale nella gestione di un web-server e dei server della famiglia Windows Server (2003 incluso);
- Amministratore di database: laureato, con esperienza almeno quinquennale nella gestione di RDBMS e almeno due nello specifico RDBMS scelto dall’Impresa;
- Sistemista junior: esperienza almeno biennale in attività di supporto operativo, conoscenza sistemistica a livello di PC, con particolare attenzione verso Windows XP e la suite Office Xp;
- Network Specialist: laureato, esperienza almeno decennale nella gestione di reti complesse, problematiche della sicurezza dei dati e degli accessi;
- Docente di programmazione Java: con esperienza almeno quinquennale nell’insegnamento del linguaggio di programmazione Java. Spiccate attitudini alla comunicazione, buone capacità di programmazione;
- Docente per DBA: con esperienza almeno quinquennale nell’insegnamento e nella gestione dei DB relazionale e almeno biennale per l‘RDBMS prescelto. Si richiedono spiccate attitudini alla comunicazione;
- Docente di Amministrazione di reti: con esperienza almeno quinquennale nell’insegnamento, nell’amministrazione di reti complesse, nella gestione di web-server. Si richiedono spiccate attitudini alla comunicazione.
- Operatore data-entry: con esperienza almeno biennale nel data-entry.
Figura professionale N° ore max N° ore garantite
Analista funzionale 100 50
Analista programmatore 8501 5302
1 Di cui 300 di un analista programmatore Java, indipendentemente dall’ambiente scelto dall’impresa
2 Di cui 200 di un analista programmatore Java, indipendentemente dall’ambiente scelto dall’impresa
Programmatore | 20003 | 12004 |
Consulente M.F. e C.A. | 60 | 30 |
Amministratore di sistema | 400 | 200 |
Amministratore di database | 2405 | 506 |
Sistemista junior | 2200 | 1400 |
Network Specialist | 120 | 50 |
Docente programmazione Java | 50 | 27 |
Docente Gestione RDBMS | 50 | 25 |
Docente Gestione Sistemistica | 50 | 25 |
Operatore Data-entry | 500 | 300 |
TOTALE | 6610 | 3887 |
Tutte i professionisti proposti dalla ditta devono ottenere il gradimento da parte dell’Amministrazione. I professionisti verranno scelti fra quelli inseriti nell’elenco nominativo presentato dall’Impresa. La mancata disponibilità di risorse adeguate, oltre ad essere sanzionata con delle penali, come indicato nel Capitolato d’Xxxxx, se prolungata oltre 40 gg cumulativi per tutte le figure professionali, potrà portare alla risoluzione del contratto.
L’Amministrazione richiederà le risorse sulla base delle proprie necessità, presentando un piano semestrale, un mese prima della sua partenza, con indicazione nominativa degli esperti. Il primo trimestre conterrà il piano di lavoro effettivo, mentre il secondo semestre sarà rimodulabile, con la possibilità di ridurre del 30% le ore indicate. L’aggiornamento del piano avverrà trimestralmente, per cui si avrà sempre un primo trimestre con una pianificazione in effettivo e un secondo trimestre con un piano rimodulabile. Fatta salva la quantità delle ore, le date effettive degli interventi saranno stabilite secondo la seguente modalità: l’Amministrazione proporrà delle date di inizio per ogni singola figura professionale, ma su richiesta dell’Impresa, da inviare entro 10 giorni dalla presentazione del piano, dovrà fornire almeno una data alternativa. Per quanto possibile le prestazioni dovranno essere previste continuativamente.
Nel piano di impiego delle risorse, da allegare nel progetto-offerta, l’Impresa potrà inserire dei propri tempi di ritardo, suddivisi per figura professionale, rispetto alle richieste dell’Amministrazione, limitatamente alle figure professionali diverse dall’analista programmatore, programmatore, sistemista junior, amministratore di sistema, amministratore di database. Tali tempi verranno presi in considerazione nella valutazione del piano di messa a disposizione delle risorse, riducendo il punteggio totale per il criterio, che in assenza di vincoli sarà di punti 4.
Per ogni professionalità coinvolta vanno definiti i requisiti in termini di:
▪ definizione del profilo (analista funzionale, analista programmatore, sistemista, amministratore di sistema, amministratore di database,…)
▪ titolo di studio (diploma, laurea, specializzazioni, certificazioni…)
▪ conoscenze (metodologiche, progettuali, tecniche hardware e software, specialistiche …)
▪ capacità (gestionali, relazionali, interpersonali, comunicative, socialità, …)
▪ esperienze lavorative (durata minima, ruolo, mansione, contenuti, competenze sviluppate, progetti a cui ha partecipato...).
L’Impresa potrà, per sua tutela, indicare un elenco nominativo di professionisti ridondante rispetto alle reali necessità, ma l’Amministrazione avrà poi la facoltà di scegliere le risorse più confacenti alle proprie esigenze.
3 Di cui 800 di un analista programmatore Java, indipendentemente dall’ambiente scelto dall’impresa 4 Di cui 450 di un analista programmatore Java, indipendentemente dall’ambiente scelto dall’impresa 5 Di cui 60 di un DBA esperto in SQLServer
6 Di cui 20 di un DBA esperto in SQLServer
8. Rinnovo delle prestazioni previste nella fase 4.
La ditta aggiudicataria dovrà , ai sensi e per gli effetti dell’art.7, comma 2 lettera f) del D. Lgs. n.157/95 testo in vigore, qualora il servizio sia stato realizzato in modo soddisfacente nel periodo fino al 31.12.2005, e sussista l’esigenza da parte dell’Amministrazione, garantire la disponibilità di personale confacente all’espletamento dei servizi di assistenza tecnica e gestionale nell’utilizzo del sistema fino al 31.12.2006, il tutto da valutarsi per il tramite di una commissione tecnica. Dovrà inoltre garantire l’invariabilità dei prezzi unitari, fatto salvo l’adeguamento all’indice ISTAT.
9. Modalità di espletamento della fornitura
9.1 Piano di lavoro
L’impresa proponente dovrà formulare un piano di lavoro contenente il dettaglio della fornitura per le fasi previste, i relativi documenti ed oggetti software costituenti il prodotto software e la stima dei tempi di consegna.
Le fasi dovranno coincidere con quelle previste dall’Amministrazione, salvo la creazione di sottofasi, che non avranno valore ai fini del collaudo e della fatturazione.
La stima dei tempi di consegna non potrà superare i tempi previsti dall’Amministrazione. Qualora fossero invece inferiori, questi tempi subentreranno contrattualmente, ai fini del collaudo e della fatturazione, ai tempi indicati in questo capitolato. I tempi proposti dall’Impresa verranno valutati in fase di aggiudicazione nel criterio sul “piano di conduzione, modalità e tempi per la messa in produzione/conduzione dei sottosistema”.
Tutta la documentazione di pianificazione e controllo e quella di contenuto tecnico dovrà essere sottoposta a revisione in seguito a qualsiasi variazione del progetto e dovrà risultare costantemente aggiornata.
Relativamente alle attività di formazione devono essere indicati contenuti, durata, impegno in giorni persona e la tipologia d’utenza cui sono rivolti i corsi.
Le attività di formazione potranno essere erogate con modalità diverse (presentazioni sulle funzioni del sistema, addestramento operativo sull’uso del sistema, training on the job del personale).
9.2 Variazione in corso d’opera
L’Amministrazione appaltante, nel corso della realizzazione del Sistema, si riserva il diritto di apportare modifiche al medesimo, aggiungere e/o integrare delle funzionalità finalizzate al miglioramento del Sistema con eventuali oneri aggiuntivi a carico dell’Amministrazione medesima.
9.3 Collaudo
Il collaudo provvisorio verrà effettuato presso la sede del Fornitore con i tempi e le modalità previste nel punto 1.25 del capitolato d’oneri.
10. Garanzia e manutenzione
L’Impresa dovrà garantire, data la natura del progetto, un servizio di correzione di eventuali errori che dovessero emergere nell’uso operativo di tutte le componenti oggetto della fornitura per un periodo compreso entro i 36 mesi successivi alla data di accettazione del prodotto (collaudo finale, corrispondente al collaudo della fase 3).
Tale attività si esplica nella manutenzione correttiva avente lo scopo di rimuovere eventuali malfunzionamenti riconducibili ad errori imputabili al fornitore in una delle fasi precedenti il rilascio in esercizio.
Durante il periodo di garanzia, la Ditta si impegna a intervenire per la risoluzione di eventuali gravi malfunzionamenti, con tempificazioni diversificate in funzione del livello di gravità ed in seguito a comunicazione per iscritto del malfunzionamento.
I livelli di gravità previsti sono:
a) errori gravi: impediscono l’operatività anche parziale di una funzione o la degradano sensibilmente.
b) altri errori: non hanno un impatto immediato, evidente e generalizzato sull'operatività del Sistema.
I tempi di intervento saranno diversificati in funzione della gravità dell’errore secondo quanto di seguito precisato.
a) Tempo massimo di intervento:
• per errori classificati gravi: entro le 12 ore lavorative per guasti hardware, con sostituzione dell’eventuale pezzo on-site; 2 giorni lavorativi per i malfunzionamenti software. I tempi si calcolano dal ricevimento della comunicazione per iscritto del malfunzionamento rilevato;
• per tutti gli altri errori: entro 5 giorni lavorativi dal ricevimento della comunicazione per iscritto del malfunzionamento rilevato.