CIG n° 2671496C3A PIATTAFORMA DI ERP, INTEGRAZIONE E I B ... di gara e contratti/Gar… ·...
47
CIG n° 2671496C3A PROCEDURA APERTA PER LA FORNITURA DELLA PIATTAFORMA DI ERP, INTEGRAZIONE E BUSINESS INTELLIGENCE PER LA PREDISPOSIZIONE DELLA BANCA DATI UNIFICATA “BDU” DELLA CAMPANIA COMPRENSIVA DI SERVIZI ON SITE DI PERSONALIZZAZIONE GESTIONE E IMPIEGO OPERATIVO CAPITOLATO TECNICO
Transcript of CIG n° 2671496C3A PIATTAFORMA DI ERP, INTEGRAZIONE E I B ... di gara e contratti/Gar… ·...
CIG n° 2671496C3A
PROCEDURA APERTA PER LA FORNITURA DELLA PIATTAFORMA DI ERP, INTEGRAZIONE E BUSINESS INTELLIGENCE PER LA PREDISPOSIZIONE DELLA BANCA
DATI UNIFICATA “BDU” DELLA CAMPANIA COMPRENSIVA DI SERVIZI ON SITE DI
PERSONALIZZAZIONE GESTIONE E IMPIEGO OPERATIVO
CAPITOLATO TECNICO
2 / 47
INDICE
Premessa Generale ........................................................................................................................................ 3 I. Struttura generale della fornitura ...................................................................................................... 8 II. Architettura funzionale della piattaforma applicativa .................................................................... 9 III. Caratteristiche Tecniche minime della piattaforma applicativa E Standard Di Riferimento13 IV. Elementi utili al dimensionamento della fornitura ....................................................................... 31 V. Caratteristiche e Requisiti minimi dei Servizi Tecnici e Operativi ............................................. 31 VI. Schema di massima delle attività progettuali oggetto dei servizi tecnici e operativi ........... 34 VII. Requisiti minimi del Contratto di manutenzione .......................................................................... 42 VIII. Piano finanziario .................................................................................................................................. 46 IX. Gantt di Progetto di massima ............................................................................................................. 1
3 / 47
Premessa Generale
La legge finanziaria della Regione Campania ha affidato a SoReSa una serie di importanti
responsabilità apparentemente distinte ma in realtà unite da un unico filo conduttore coerente alla
mission istituzionale di SoReSa: Il contenimento della spesa Sanitaria e il rientro dei debiti
pregressi e la gestione contabile dei dati funzionale alla centralizzazione degli acquisti.
Fig. 1
Il punto di partenza di questo articolato e ambizioso progetto è quindi rappresentato dalla
costruzione di una Sistema unificato dei flussi finanziari, che rappresenta la base indispensabile
di informazioni propedeutica allo sviluppo e consolidamento delle successive fasi indicate nel
diagramma.
Il sistema dovrà da un lato permettere di ottenere una accurata indicazione dell’effettivo stato
di indebitamento delle singole AASSLL dall’altro di controllare in tempo reale i movimenti
relativi ai nuovi ordini e contratti i quali potranno essere stipulati solo previa autorizzazione di
4 / 47
SoReSa. A tal fine assume un ruolo significativo la anagrafe unica dei fornitori di beni e servizi
che dovrà sia essere alimentata e sincronizzata con le anagrafe delle singole AASSLL, che
arricchita di ulteriori
informazioni che
tengano conto della
“qualità” delle
forniture effettuate e
dell’atteggiamento
etico delle aziende
fornitrici.
Il monitoraggio della
situazione contabile
delle Aziende
Sanitarie, e la corretta
gestione del flusso
della
Centralizzazione
Acquisti, richiede un flusso costante di dati amministrativi e contabili (Schede contabili, ordini
fatture etc) delle Aziende Sanitarie.
Anche la funzione di Assistenza e Supporto richiesta a SoReSa in materia di controllo di gestione e
di pianificazione aziendale, richiede che le Aziende Sanitarie “espongano” i propri dati verso
SoReSA.
In linea di principio la costruzione del sistema richiede che le Aziende Sanitarie e Ospedaliere
inviino verso SoReSa, un flusso informatico di dati contabili per i necessari controlli e
accertamenti. Tali flussi informatici attualmente sono costituiti da files che devono essere
compilati ad hoc dal personale delle AASSLL sulla scorta delle risultanza contabili presenti nei
sistemi gestionali delle varie AASSLL e AAOO.
Fig. 2
5 / 47
Questa attività è propria di SoReSa per quanto attiene la cosiddetta >”gestione del debito” in
quanto molto spesso impiegata per gestire le attività relative alle varie operazioni finanziarie di
gestione del debito pregresso delle AASSLL.; L’esperienza di questi anni ha dimostrato diversi
limiti di questa tecnica.
In questo modello di cooperazione il contenuto dei files rappresenta una sorta di “fotografia”
relativa ad una specifica finestra temporale; poiché i movimenti contabili vengono spesso
aggiornati anche molti mesi dopo la data di competenza, i dati contenuti nei files trasmessi,
potrebbero essere superati già il giorno dopo la trasmissione.
Inoltre i dati contenuti nei sistemi gestionali delle AASSLL spesso risentono di carenze
organizzative del flusso gestionale-contabile, in altri termini la “qualità” del dato non è alle
volte garantita; questo fa si che molto spesso queste “fotografie” risultano “sfocate” e
inutilizzabili per le necessarie valutazioni gestionali. In questo caso occorre quindi effettuare le
opportune bonifiche e re-inviare le informazioni a scapito dei ristretti tempi operativi previsti
dalle attività gestionali-contabili.
Oppure, al contrario, le estrazioni sono il frutto di post-elaborazioni effettuate ad hoc e quindi il
dato che giunge a SoReSa non riflette i vizi organizzativi della struttura che quindi permangono
all’infinito.
Un ulteriore elemento di criticità è rappresentato dai debiti relativi a contenziosi in atto tra i
creditori e le ASL: tali debiti, di importo significativo, non risultano dai dati contabili inseriti
nei gestionali e quindi sfuggono a qualunque tipo di controllo; è quindi evidente che un sistema
realmente efficace di monitoraggio dei flussi finanziari non potrà prescindere da una
informatizzazione di tali dati e delle procedure connesse alla gestione dei contenziosi con le
ditte fornitrici.
I dati così ricevuti da SoReSa, in generale consentono quindi , nel migliore dei casi, una
stima approssimata “storica” dei dati contabili ma non permettono invece un monitoraggio in
6 / 47
“tempo reale” della situazione corrente di spesa, complicando notevolmente la possibilità e la
efficacia di eventuali azioni correttive da parte degli Assessorati competenti (Bilancio e
Sanità).
La Banca Dati Unificata: un Sistema integrato regionale per il monitoraggio dei dati
contabili
Un efficiente monitoraggio dei dati e la predisposizione di efficaci strumenti di controllo e
programmazione della spesa da parte delle Aziende Sanitarie richiedono un sistema in grado di
fornire informazioni in tempo reale relative ai flussi contabili; da un punto di vista tecnico ciò
significa adottare soluzioni informatiche in grado di interoperare - in modalità standard con gli
applicativi gestionali in uso presso le diverse strutture. Tali sistemi informatici devono essere poi in
grado di interpretare correttamente i flussi prodotti e di tradurre tali dati in specifici report
riepilogativi indispensabili agli analisti degli organi di controllo. Le soluzioni proposte devono
disporre di una “Piattaforma di integrazione” : che permetta di recepire i dati gestiti e prodotti dai
sistemi delle Aziende collegate Diversi costruttori si stanno impegnando su questo campo di
frontiera che rappresenta la vera sfida per l’interoperabilità dei sistemi informativi del futuro.
L’obiettivo finale è quello di fornire un sistema evoluto di collaborazione, monitoraggio, gestione e
controllo agli amministratori, integrando, in una vista centralizzata, i flussi gestionali delle singole
Aziende Sanitarie .
Lo schema generale prevede che Le Ditte responsabili dei sistemi gestionali delle AASSLL
rendano disponibili sul sistema di connettività (Porta di Domnio, WEB Services) i flussi coerenti
al format indicato da SoReSa, questi flussi verranno acquisiti dalla piattaforma di integrazione e
quindi non richiedono alcuna modifica degli applicativi gestionali delle AASSLL e AAOO
(Fig.2 ). Inoltre poiché le query di accesso sono in sola lettura l’intervento della piattaforma di
integrazione non può essere causa di interferenze con i sistemi gestionali i quali mantengono
inalterate le proprie prerogative funzionali.
7 / 47
Una volta predisposti tali flussi SoReSa potrà effettuare diversi tipi di interrogazione al fine di
rendere disponbile ai competenti Assessorati i report necessari alle attività di monitoraggio e
controllo dei conti.
La connessione di rete
tra il sistema
informativo di
SoReSa e quelli delle
aziende sanitarie
richiede unicamente
la creazione di una
connessione,
adeguatamente
protetta . (Fig.2)
Preme rilevare che le
AASSLLe AAOO già
dispongono di questa
funzionalità,
nell’ambito dei propri sistemi telematici aziendali, in quanto già realizzate dalla piattaforma
regionale del CuRep (Cup Regionale.)
La messa a punto dei flussi richiede comunque necessariamente la conoscenza della struttura dei
database gestionali delle specifiche applicazioni installate presso le AASSLL e AAOO; in altri
termini, in fase di personalizzazione del sistema di integrazione è quindi necessaria la piena
COLLABORAZIONE da un lato dei responsabili SEF delle AASSLL, dall’altro delle Ditte
responsabili dei singoli sistemi informatici gestionali, a supporto dei sistemisti esperti della
piattaforma di integrazione adottata.
Le linee guida tecniche e gli schemi procedurali, per dare risposta ai requisiti tecnici della BDU nel
rispetto della normativa corrente, sono contenute nelle linee guida rilasciate dal DigitPA
(http://www.digitpa.gov.it/qualitaICT/elenco_manuali_qualita_ICT) in base alle quali SoReSa ha
elaborato il proprio progetto di creazione dalla BDU che in sintesi prevede le seguenti azioni:
8 / 47
1) Le AASSLL , AAOO e IRCCS si connettono sulla rete SPC (Sistema Pubblico di
Connettività) al fine di costituire una rete privata unica regionale della Sanità, sicura, e
aderente alla normativa tecnica corrente e alle linee guida tecniche prima indicate; tale rete
permette anche una migliore gestione degli altri servizi applicativi regionali quali il CUP
Regionale.
2) Riuso della piattaforma SPICCA per la interconnessione delle porte di dominio quale
infrastruttura logica per la cooperazione applicativa tra i gestionali delle Aziende Sanitarie e
quello di SoReSa
3) Le AASSLL, AAOO e IRCCS espongono i propri dati gestionali tramite appositi Web
Services attraverso le Porte di Dominio di SPICCA già attive per il CUP Regionale.
4) SoReSa Attraverso una apposita gara si munisce di una piattaforma di ERP – Integrazione –
Business Intelligence conforme agli standard industriali comprensiva dei servizi di
personalizzazione e gestione, necessari per:
a. la creazione e gestione della BDU
b. l’analisi dei flussi finanziari
c. la predisposizione dei servizi applicativi necessari alle nuove funzioni di integrazione
e consolidamento della piattaforma ordini.
Il progetto di SoReSa di cui al comma 4) prevede quindi da un lato la predisposizione di una
piattaforma tecnologica, hardware e software, aderente agli standard e in grado di inter-operare
con i sistemi informatici delle altre pubbliche amministrazioni regionali e nazionali, dall’altro i
servizi professionali necessari.
I. Struttura generale della fornitura
Il progetto di Banca Dati Unificata consta dei seguenti elementi che saranno di seguito dettagliati:
Piattaforma applicativa
Servizi Tecnici di Configurazione, Personalizzazione e Gestione Operativa
La piattaforma applicativa sarà costituita da un sistema software commerciale conforme agli
standard industriali e di interoperabilità, provvisto delle funzionalità di gestione flussi contabili,
9 / 47
integrazione e analisi dei dati necessarie per il raggiungimento degli obiettivi. Il sistema software
dovrà peraltro consentire le necessarie personalizzazioni che DOVRANNO ESSERE
EFFETTUATE SENZA INTACCARE IL CODICE SORGENTE DELLA PIATTAFORMA,
saranno consentiti, e solo previa esplicita autorizzazione di SoReSa, inserimenti di codice
sviluppato ad hoc limitatamente alle funzioni di integrazione con flussi esterni (V.
dematerializzazione documenti, flussi di fatturazione elettronica). Tali moduli dovranno comunque
essere predisposti in maniera conforme alle indicazioni del costruttore della piattaforma e il codice
sorgente di tali moduli dovrà essere ceduto in uso illimitato SoReSa nonché certificato dal
produttore stesso.
Obiettivo del presente appalto è anche quello di garantire che il know how relativo all’uso delle
funzioni di personalizzazione della piattaforma diventi un patrimonio del personale di SoReSa, la
ditta aggiudicataria dovrà quindi garantire durante l’intera durata del progetto un regolare
trasferimento di conoscenza sia per gli aspetti progettuali che operativi.
II. Architettura funzionale della piattaforma applicativa
Il sistema informativo da fornire si inserisce in un contesto in via di evoluzione che riguarda diversi
componenti applicativi e diverse strutture organizzative. La figura sottostante, descrive in quale
modo queste componenti dovranno colloquiare ed integrarsi nella nuova Banca Dati Unificata di
SoReSa.
La figura individua i nuovi componenti funzionali oggetto della fornitura indicando la macro
componente ERP e quella di Business Intelligence. (BI) mentre la piattaforma di integrazione PI
fornirà i necessari servizi infrastrutturali per connettersi ai Database e alla Applicazioni
informatiche preesistenti.
Dato il grado di centralità di SoReSa e quindi l’importanza che rivestono i servizi informatici di
SoReSa per l’intera Regione, anche sulla scorta delle caratteristiche strutturali di SoReSa, in
conformità delle indicazioni delle linee guida del DigitPA si ritiene INDISPENSABILE che i
servizi informatici di cui sopra debbano essere predisposti utilizzando piattaforme software di
10 / 47
ampia diffusione e sulle quali possa quindi intervenire, senza alcuna privativa, un qualsiasi partner
attivo sul territorio nazionale e anche internazionale.
Il piano di attività prevede quindi la predisposizione di una piattaforma informatica aderente agli
standard industriali e di interoperabilità, come da raccomandazioni DigitPA, comprensiva dei
servizi tecnici ed operativi indispensabili al raggiungimento degli obiettivi indicati in premessa. Le
aziende che concorrono pertanto al presente appalto, dovranno quindi offrire, insieme ai servizi
tecnici e operativi necessari, il prodotto software che risponde ai requisiti appresso indicati.
Area Ammnistrativo Contabile - ERP
In questa area dovranno essere attivate:
le anagrafiche di tutte le AASSLL e AAOO coinvolte nel Nuovo Sistema Centralizzato
la gestione dei dati anagrafici contabili:
o piano dei Conti condiviso (voci economico /patrimoniali)
o anagrafiche dei fornitori/creditori
o codici Iva
la gestione delle causali di movimento
la gestione contabile delle operazioni tipiche della Contabilità Fornitori/Creditori (Fatture,
Storni, Note di credito,ecc)
la gestione delle operazioni di chiusura e apertura periodo/esercizio
Area Controlling - ERP
In questa area dovranno essere attivate:
la gestione dati Anagrafici: voci di Costo, Centri di Costo
le contabilizzazioni in effettivo su Centri di Costo relativamente ai costi derivanti dal “flusso
di Ddt e Fatture”
Ie operazioni di giroconto
la gestione dati Anagrafici: voci di Costo/Ricavo, Centri di Costo, ordini interni
(commesse), Centri di Profitto (reddito)
l’aggregazione dei Centri di Costo per Centro di Responsabilità
11 / 47
la pianificazione & Budgeting: nello specifico per la pianificazione su Centri di Costo,
ordini interni e Centri di Profitto
la registrazioni di prenotazione dei costi relative ai flussi di RdA (Richieste di Acquisto) e
OdA (Ordini di Acquisto)
la contabilizzazioni in effettivo su Centri di Costo, Ordini Interni, Centri di Profitto
le operazioni di Fine Periodo: nel senso delle riallocazioni, del calcolo dei costi figurativi,
delle rateizzazioni, etc.
la reportistica di analisi su tutte le dimensioni individuate
Area Contenzioso- ERP
In questa area dovranno essere attivate:
la gestione delle tabelle di attribuzione delle partite oggetto di contenzioso
la gestione dei dati relativi al DP 12/2011 (Anagrafica avvocati , riferimento ai decreti
esecutivi, ecc)
la gestione del processo di ricognizione del debito
Ulteriori aree funzionali-ERP
La piattaforma di ERP potrà contenere ulteriori aree funzionali alla gestione complessiva dei flussi,
anche sanitari, all’interno dell’azienda sanitaria.
Questo nell’ottica di tendere ad una sempre maggiore integrazione e coerenza dei dati, elemento
questo indispensabile ad un efficace controllo di gestione.
Area di Analisi - BI
La piattaforma di Analisi dati o Business Intelligence (di seguito BI) dovrà utilizzare come unica
sorgente informativa i dati provenienti dal sistema ERP.
Le aree analitiche che saranno oggetto di lavoro sono scomponibili nelle seguenti tre aree :
Analisi Flussi Finanziari
Analisi Ricognizione Debitoria
12 / 47
Analisi Contenziosi
Cuore del sistema deve essere un PORTALE di BUSINESS INTELLIGENCE che deve raccogliere
e consolidare le analisi e le presenta in una visualizzazione personalizzata e protetta tramite un
portale web. Attraverso il portale l’utente potrà accedere alle diverse aree analitiche disponibili
(Flussi Finanziari, Ricognizione del Debito e analisi Contenziosi) e alle diverse tipologie di
reporting (reporting operativo, istituzionale, analisi per eccezioni, analisi multidimensionale e
cruscotti direzionali).
Di seguito vengono presentati alcuni esempi (non vincolanti in quanto il modello analitico verrà
definito in fase di definizione dei servizi implementativi) di reporting e cruscotti direzionali:
Analisi Flussi Finanziari: Analisi operativa e multidimensionale su fatture, storni, note di
credito (anagrafiche ASL/AO, Causali, Tempo, Fornitore, Prodotto, Categoria
Merceologica, Centri di Costo, …), documenti di trasporto, cruscotto di sintesi ASL/AO.
Analisi Ricognizione Debitoria: Analisi multidimensionale debito (ragione sociale
impresa, causali, importo, residuo, tempo, importo certificabile, importo certificato, …),
Analisi Importo Certificato, Analisi parametrizzata singole partite di debito, Analisi Debito
Complessivo e trend storico, …
Analisi Contenziosi: Analisi multidimensionale contenziosi (ASL/AO, Tempo, Fornitore,
Tipologia, Prodotto, Categoria Merceologica, …), Analisi statistiche: tempistiche medie,
importo %, trend, …; Cruscotto «Grado di Aggressività Fornitore»: % azioni legali, %
forniture, tempistiche di avvio azione legale, …; reporting di rendicontazione contenziosi.
Dalla figura soprastante, inoltre, si possono individuare anche l’ecosistema in cui il NSC dovrà
collocarsi, in cui sono componenti fondamentali i diversi sistemi delle singole ASL e AO e il
sistema MEP attualmente in uso presso SORESA.
Il sistema del suo complesso, deve rispondere ad un disegno unitario e strettamente integrato degli
archivi anagrafici di base che descrivono il core del modello di contabilità e controllo.
Area di integrazione PI
13 / 47
La soluzione proposta deve offrire la massima flessibilità, attraverso una Business Process Platform
(BPP), in grado di supportare con una serie di elementi interni o con l’integrazione di elementi e
servizi esterni, la piena adattabilità del sistema alle evoluzioni dei processi richiesti .
[T2] La flessibilità deve essere possibile tramite logiche di enterprise Service-Oriented
Architecture (enterprise SOA). L’enterprise SOA deve consentire la rapida composizione delle
soluzioni e dei processi operativi, incapsulando le logiche di processo ed esponendole come
enterprise services, (ovvero piccoli componenti che ricoprono funzionalità applicative) che possono
essere ri-assemblati per comporre rapidamente nuovi processi, in modo da soddisfare le mutevoli
esigenze dell’Amministrazione.
III. Caratteristiche Tecniche minime della piattaforma applicativa E Standard Di Riferimento
La fornitura richiesta è articolata come segue:
Fornitura di un software applicativo di mercato di tipo ERP per la copertura dell’area
funzionale della contabilità generale, analitica, della pianificazione e controllo, inclusa la
gestione del cash management, del ciclo passivo, del magazzino (V. griglia requisiti ERP
allegata) (Il software si intende escluso delle licenze di database necessarie al suo
funzionamento). Il Software potrà prevedere opzionalmente, ma in modalità integrata, la
copertura di ulteriori aree funzionali relative al workflow clinico
Fornitura di un software applicativo di mercato di tipo BI per la copertura dell’area di analisi
multidimensionale. (V. griglia requisiti BI allegata) Il software si intende escluso delle
licenze di database necessarie al suo funzionamento.
Fornitura di un software applicativo di mercato per la integrazione a livello di processi e di
database eterogenei (V. griglia requisiti PI allegata) Il software si intende escluso delle
licenze di database necessarie al suo funzionamento.
Contratto di manutenzione di durata annuale che assicuri per entrambi i sistemi la fornitura di:
14 / 47
o correzioni al software standard (patch);
o adeguamento del software standard a mutamenti legislativi;
o rilascio di nuove versioni del software standard.
Nel seguito verranno dettagliate le caratteristiche tecnico-funzionali del software con evidenza di
quelle obbligatorie pena esclusione.
Caratteristiche generali obbligatorie
R.1. Il sistema del suo complesso, deve rispondere ad un disegno unitario e strettamente
integrato degli archivi anagrafici di base che descrivono il core del modello di contabilità e
controllo. I sistemi applicativi di mercato richiesti nella presente fornitura, compresi
quelli opzionali, anche se concettualmente distinti, devono necessariamente , riferirsi
ad un’unica piattaforma integrata, garantita e manutenuta da un unico produttore.
R.2. Il sistema deve essere in grado di alimentare da un'unica registrazione le diverse aree
del sistema gestionale (contabilità generale, cespiti, analitica, di magazzino e di controllo).
Ad esempio, dalla registrazione di un entrata merce muovere in automatico il magazzino, la
contabilità, il controllo di gestione ed eventualmente i cespiti.
R.3. Nel sistema deve essere possibile definire a livello di parametrizzazione (senza
nessun intervento di programmazione) diverse causali contabili che guidino campi
obbligatori, campi facoltativi, campi nascosti e che possono essere attribuite come parametri
ai profili autorizzativi
R.4. Ulteriore caratteristica comune è il rispetto del requisito dell’univocità del dato. Tale
requisito implica in particolare che i sistemi applicativi forniti siano in grado di gestire in
modo univoco l’ownership di ciascun dato (anagrafico od operazionale), e in particolare di
garantire il corretto trattamento della proprietà di dati provenienti da o diretti verso sistemi
esterni, in modo da garantire sempre la certezza che il dato originario, qualunque
trattamento abbia subito, possa essere inserito una sola volta e attraverso processi e regole
sempre rintracciabili. In particolare per ogni dato creato o cambiato deve essere possibile
individuare l’autore, il cambiamento effettuato, la data e l’ora dell’intervento.Tutte le
15 / 47
strutture anagrafiche definite devono disporre di un meccanismo di storicizzazione del dato,
in modo da gestire il cambiamento organizzativo. Si sottolinea in particolare la necessità di
poter ricostruire e riclassificare i dati nel corso del tempo, rendendo per quanto possibile
confrontabili le informazioni di periodi temporali diversi nei quali l’assetto per centri di
costo dell’Amministrazione può progressivamente mutare.
R.5. Il sistema deve consentire la gestione multiente e multiazienda nell’ambito di
un’unica installazione
R.6. Il sistema deve essere installabile sulle principali piattaforme hardware e di sistema
operativo presenti sul mercato. Il software dovrà essere disponibile e certificato almeno su
tutte le seguenti piattaforme Windows, Linux (RedHat e Suse), Sun Solaris, AIX e HP UX.
R.7. Il sistema deve poter utilizzare le principali tipologie di database relazionale. Il
software dovrà essere disponibile e certificato almeno su tutti i seguenti motori di Database :
Oracle DB, MS SQL-Server, IBM DB2.
Caratteristiche sistema ERP (Non obbligatorie soggette a valutazione di qualità)
Gestione anagrafica
R.8. Gestione dell’anagrafica fornitori unica e completa di tutte le informazioni necessarie alla
corretta identificazione e classificazione economica, giuridica e commerciale del fornitore,
definibili in base alla tipologia del fonitore. Gestione di sedi multiple per ciascun fornitore.
R.9. Possibilità di classificare i fornitori attraverso la definizione parametrica (senza l’intervento sui
programmi ma solo sulle tabelle di parametrizzazione) di gruppi.
R.10. Possibilità di istituire relazioni di gerarchia o di legame fra fornitori diversi, ad esempio al
fine di rappresentare e gestire fornitori in RTI (Raggruppamento Temporaneo di Impresa).
R.11. Nel sistema deve essere possibile definire delle validazioni per la corretta gestione
dell’univocità delle anagrafiche e della eventuale bonifica di dati anagrafici.
16 / 47
Transazioni
R.12. Gestione delle diverse tipologie di operazioni di acquisto, all’interno di un workflow
configurabile del processo di acquisto, dalla richiesta all’evasione dell’ordine, coerente con la
normativa vigente.
R.13. Scadenzario ordini.
R.14. Gestione integrata, nativa ed automatica di tutte le operazioni relative alla tesoreria.
R.15. Rilevazioni contabili, documentazione e dichiarazioni fiscali per i fornitori variabili in
funzione della loro tipologia (soggetti a ritenuta d’acconto professionisti, con IVA e senza
IVA, con possibilità di gestire le dichiarazioni d’intento ed all’utilizzo del plafond IVA, ecc.).
R.16. Gestione delle entrate erariali e delle operazioni in “sostituto di imposta”.
Integrazione con il magazzino beni
R.17. Possibilità di definire più magazzini, inclusi magazzini virtuali.
R.18. Anagrafica degli articoli di magazzino, con possibilità di classificazione degli articoli
secondo molteplici raggruppamenti, e possibilità di gestione della valorizzazione a costo
standard.
R.19. Gestione del carico e scarico della merce da magazzino integrata con il processo di
inventariazione e collocazione fisica del bene nel caso di beni da inventariare.
R.20. Gestione del sottoscorta e del riordino, qualora si tratti di articoli standard.
Reporting
R.21. Elaborazione e produzione di tutti gli output e registri richiesti dalla normativa civilistica e
fiscale.
R.22. Elaborazione di report standard di analisi di dettaglio e di sintesi delle operazioni effettuate
sui fornitori secondo diversi criteri di selezione dei dati (per tipologia, per causale, per data,
per fornitore, per conto di contropartita, per contratto, per ordine di acquisto, per attività,
centro di costo).
R.23. Analisi dei consumi di magazzino per articoli, gruppi di articoli e centri di costo richiedenti.
17 / 47
Contabilità Cespiti
Gestione anagrafica
R.24. Gestione delle anagrafiche cespiti complete di dati contabili, gestionali e logistici.
R.25. Integrazione con altre anagrafiche aziendali di asset management
R.26. Organizzazione delle anagrafiche per classi, categorie, etc. per gestione strutturata del
patrimonio aziendale in funzione delle diverse esigenze aziendali; si tenga conto in particolare
che le classificazioni possibili, necessarie alla gestione logistica, civilistica, fiscale, di
controllo, devono poter essere mappate sulla rappresentazione del patrimonio utile.
Transazioni
R.27. Gestione dell'acquisizione automatica delle registrazioni contabili. Gestione integrata delle
operazioni contabili provenienti da altri processi che hanno effetto sulla valutazione dei cespiti
(acquisti, fatturazione, dismissioni, manutenzioni straordinarie, ecc.)
R.28. Possibilità di definire ed utilizzare contemporaneamente diversi piani di ammortamento, ad
uso fiscale o gestionale, secondo diversi criteri costruttivi, che devono essere parametrizzabili
(senza l’intervento sul codice). Gestione delle detraibilità e deducibilità fiscali (es.: fondo
ripristino cespiti, deducibilità fiscale delle manutenzioni, etc.).
R.29. Possibilità di eseguire simulazioni sui piani di ammortamento, in funzione delle diverse
tipologie di ammortamento, a livello di singolo cespite o per classe.
Reporting
R.30. Gestione dei registri e degli output previsti da normativa civilistico/fiscale, quali il libro
cespiti.
30.1 Reporting flessibile sui cespiti ammortizzabili:Possibilità di analisi del ciclo di vita di ogni
singolo cespite (acquisti, rivalutazioni, svalutazioni incrementi/migliorie, alienazioni, etc.).
30.2 Analisi dei dati secondo selezionabili dall’utente, sia caratteristiche del bene (criteri
d’ammortamento, tipologia di cespite, tipologia di ammortamento, etc.), sia di classificazione
multidimensionale (destinazione, natura, etc.).
18 / 47
Contabilità Clienti
Gestione Anagrafica
R.30. Possibilità di classificare i clienti attraverso la definizione parametrica (senza l’intervento
sui programmi ma solo sulle tabelle di parametrizzazione) di gruppi
R.31. Gestione dell’anagrafica cliente completa di tutte le informazioni necessarie alla corretta
identificazione e classificazione economica, giuridica del cliente, come per i fornitori,
definibile per tipologia. Gestione di sedi multiple per ciascun cliente.
R.32. Possibilità di istituire relazioni di gerarchia o di legame fra clienti diversi
R.33. Nel sistema deve essere possibile definire delle validazioni per la corretta gestione
dell’univocità delle anagrafiche e della eventuale bonifica di dati anagrafici.
Transazioni
R.34. Gestione integrata delle operazioni di tesoreria (incassi), con possibilità di acquisizione
automatica delle operazioni e di intervento manuale.
R.35. Gestione degli adempimenti della contabilità clienti, inclusa la gestione della morosità con
produzione di solleciti di varia tipologie, differenziabili in funzione della tipologia cliente e
con possibilità di simulare calcolo degli interessi di mora e delle spese da addebitare.
Reporting
R.36. Possibilità di disporre di report standard di analisi di dettaglio o di sintesi delle operazioni
effettuate sui clienti sulla base di vari criteri di selezione dei dati (per tipologia, per causale,
per data, per cliente, per conto di contropartita, per contratto, per ordine di acquisto, per
progetto/attività, centro di costo).
R.37. Produzione di tutti gli output e registri richiesti dalla normativa.
Contabilità Integrata
R.38. Il sistema applicativo deve consentire di gestire con scritture uniche i movimenti di
contabilità economica e le scritture di contabilità analitica. Il sistema deve, quindi , permettere
sui movimenti un’analisi secondo tutte le dimensioni contabili “coinvolte” in fase di
registrazione.
19 / 47
Transazioni contabili di contabilità generale ed analitica
R.39. Gestione delle diverse tipologie di operazione contabile con definizione di modelli
predefiniti di prima nota. Tali rilevazioni devono consentire, sulla base di regole di
imputazione predefinite, anche la scrittura delle informazioni di contabilità analitica (per
centro, attività/progetto, ecc.).
R.40. Gestione delle registrazioni amministrative: manualmente, in automatico e secondo causali
personalizzabili che definiscano le modalità di rilevazione del movimento.
R.41. Gestione dei conti mastro, gestione dei conti sia per saldi che per partite e interrogazione dei
conti a saldo e partite singole.
R.42. Possibilità di imputare rettifiche per la corretta gestione della competenza (chiusure
contabili).
Altre funzionalità
R.43. Gestione del sostituto d’imposta.
R.44. Possibilità di collegamenti dei documenti contabili con documenti esterni (word, pdf,
excell,ecc).
R.45. Gestione degli acquisti in economia.
R.46. Gestione centralizzata del processo di chiusura (e riapertura) periodica (mensile, semestrale,
annuale) della contabilità, con la possibilità di gestire ulteriori 4 periodi speciali per le
operazioni di rettifica ed integrazione.
Reporting
R.47. Disponibilità della reportistica di supporto alle attività di Bilancio previsti dalla
normativa vigente.
R.48. Report standard realizzabili ed articolabili secondo criteri variabili di selezione dei
dati (per causale, per conto, per centro, per data, ecc..), e di supporto per le seguenti finalità:
a. stesura della relazione illustrativa dell’attività svolta e dei risultati conseguiti.
b. riclassificazioni multiple delle strutture di bilancio sia a scopo normativo che
gestionale.
20 / 47
c. stesura della nota integrativa ed alla relazione sulla gestione
Tesoreria
Gestione Anagrafica
R.49. Gestione centralizzata delle anagrafiche dei tesorieri bancari e postali.
Transazioni
R.50. Gestione flussi di cassa effettivi e previsionali, in modalità integrata ai processi di ciclo
attivo e passivo.
R.51. Riconciliazione automatica tra estratto conto bancario o postale e posizione previsionale di
tesoreria, attraverso interfacciamento al sistema di remote banking, con possibilità di
ricezione estratto conto e riconciliazione e di trasmissione telematica dei pagamenti.
R.52. Gestione nativamente integrata del Cash flow
Reporting
R.53. Reporting finanziario e di tesoreria:
o analisi di dettaglio per data, causale, importo, ecc…
o supporto dell’analisi del lavoro bancario.
Sistema di Programmazione e controllo
R.54. Le funzionalità da supportare nello specifico sono:
Budgeting
R.55. L’applicazione deve consentire di definire budget in modo flessibile consentendo:
o La produzione di diverse versioni di Budget;
o La produzione di budget legati alle diverse dimensioni di destinazione (centri di
costo di responsabilità, commesse/progetti)
o L’articolazione dei budget per singola voce di costo (natura contabile)
o L’articolazione del budget per diversi orizzonti temporali (mensile, bimestrale,
trimestrale, semestrale, annuale).
21 / 47
R.56. Deve essere possibile predisporre “n” versioni del budget, con la possibilità di copiare in
automatico una versione su un'altra.
R.57. Nel sistema deve essere nativamente disponibile un sistema di controllo di disponibilità che
consenta di definire diversi “livelli di utilizzo” del budget, raggiunti i quali, il sistema
produca avvisi automatici (tramite un sistema interno di messaggistica/mail) ai referenti per
i Centri di responsabilità o messaggi bloccanti al superamento delle soglie.
Elaborazione del modello multidimensionale di controllo
R.58. Il sistema applicativo deve essere in grado di raccogliere, calcolare e proporre le
informazioni consuntive secondo un modello di controllo multidimensionale, attraverso la
disponibilità dei seguenti processi:
o Rilevazione automatica dei movimenti economici e patrimoniali raccolti in fase di
gestione operazionale della contabilità e delle sue integrazioni;
o Allocazioni e ribaltamenti di dati contabili per la costruzione di molteplici
configurazioni di costo e ricavo; i processi di allocazione e ribaltamento devono
poter utilizzare driver di ribaltamento a vari livelli e di vario tipo (allocazione tramite
valori o quantità, con ponderazioni, secondo tecniche Activity Based Costing, ecc.);
o Rilevazione di movimenti e rettifiche solo ai fini gestionali di tipo analitico.
Analisi e Reporting
R.59. Deve essere possibile, disporre di strumenti di Reporting per:
o Conti economici riclassificati e riaggregati secondo le varie dimensioni contabili
(centri, attività, prodotti, ecc.) e le varie configurazioni di costo definite.
o Definire Bilanci per aree o settori (all’interno della singola Azienda) utilizzando
funzionalità standard
o Reporting di confronto budget vs. consuntivo, analisi degli scostamenti, calcolo di
forecast e previsioni, ecc.
R.60. Il sistema di reporting deve consentire di:
22 / 47
o Progettare e personalizzare report tramite tool di reporting;
o Estrarre, visualizzare report tramite fogli elettronici o altri tool di produttività
individuale;
o Consentire all’utente la possibilità di configurare e modificare i report standard
tramite funzionalità di personalizzazione user frendly.
Caratteristiche Sistema di Business Intelligence (BI) (Non obbligatorie soggette a valutazione
di qualità)
B.1. L’architettura client-server dovrà rispettare un approccio di tipo three-tiers:
Tier di presentazione (client o webclient)
Tier di applicazione (servizio)
Tier di archiviazione.
B.2. L’architettura dovrà prevedere tre ambienti di lavoro:
Ambiente di test e sviluppo
Ambiente di quality assurance
Ambiente di produzione.
B.3. L’architettura server dovrà comprendere anche l’area di deploy dei prodotti
informativi sviluppati, in modo da consentirne la fruizione, a titolo esemplificativo, dai
portali web dell’amministrazione e da altre applicazioni esterne.
B.4. La piattaforma dovrà garantire scalabilità e affidabilità, estendibilità (aggiungere
nuovi servizi modularmente) ed essere progettata per soddisfare esigenze di fail-over, fault-
tolerance, analisi d’impatto, auditing e disponibilità h24.
B.5. I prodotti informativi creati con la piattaforma saranno accessibili da differenti
tipologie di utenti:personale Soresa, dirigenti e dipendenti dell’amministrazioni e, in
generale, portatori di interessi.
23 / 47
B.6. La piattaforma per la creazione dei prodotti di BI dovrà rispondere ai più moderni
principi di usabilità, avere un’interfaccia intuitiva e semplice, accessibile in ambiente di
tipo web-based. La piattaforma potrà essere costituita dall’integrazione di più componenti,
ferma la percezione da parte degli utilizzatori a tutti i livelli, di unicità e di integrità della
soluzione, da garantire anche con uniformità degli elementi grafici e con il richiamo delle
singole funzionalità disponibili, in modo da rendere agevole la navigazione.
B.7. Multicanalità: i prodotti generati dalla piattaforma di Business Intelligence devono
poter risiedere nelle più svariate applicazioni; deve essere pertanto garantita la distribuzione
multicanale, ovvero la distribuzione sui portali istituzionali, via e-mail, attraverso i cellulari
di nuova generazione, su PC desktop (attraverso miniapplicazioni), su sistemi Mac Os e
palmari. Sarà considerato elemento migliorativo l’assenza di obblighi di installazione di
particolari applicativi sulle macchine client, ad eccezione di componenti legati al web-
browser quali ActiveX, Applet Java, Adobe Flash, ecc.
B.8. Funzionalità di amministrazione: la piattaforma deve includere funzionalità di
amministrazione che consentano la gestione degli utenti, delle ACL (access control list) e di
monitoraggio dei server.Le funzionalità di gestione e monitoraggio dei server potranno
essere garantite anche con tools separati, di cui dovrà essere data compiuta descrizione
all’interno dell’offerta tecnica. La piattaforma dovrà garantire le funzionalità di
integrazione, produzione delle informazioni e analisi.
B.9. Integrazione: la piattaforma dovrà integrare in un unico layer gli elementi relativi
alla gestione dei dati, alla sicurezza, all’amministrazione, al modello degli oggetti-dato, e al
motore di produzione delle query. I tools della piattaforma dovranno essere integrati in un
portale, incluso all’interno della soluzione offerta, con un look and feel coerente. Si
dovranno poter integrare i dati provenienti da diverse sorgenti informative, sia strutturate
che non strutturate; quindi, la piattaforma dovrà prevedere uno strato semantico (un
repository informativo), che unificherà più fonti dati anche fisicamente o logicamente
separate, in un unico ambiente navigabile. Sarà elemento fondamentale l’integrazione
nativa con le componenti ERP proposte. La piattaforma dovrà garantire elaborazioni di
volumi elevati di dati in modalità on-line o batch, fornendo nativamente il servizio di
estrazione, pulizia e trasformazione del dato (ETL);
24 / 47
B.10. La piattaforma deve fornire uno strumento di Data federation: lo strumento deve
poter rendere omogenea la navigabilità su fonti dati residenti fisicamente in archivi
differenti, creando di fatto un punto di accesso unificato al dato.
B.11. La piattaforma deve consentire, attraverso un sistema agevole di tracciamento delle
modifiche, di verificare la presenza, sia dal punto di vista tecnico che dei dati finali, di
eventuali modifiche al dato di base, gestendo le versioni storiche e con possibilità
d’inserimento di note, e di ulteriori informazioni sul metadato; La piattaforma dovrà
prevedere degli strumenti in grado di far comprendere gli impatti che un oggetto ha sugli
altri dati, rendendo possibile l’analisi su gerarchie e dipendenze; inoltre, nell’osservazione
di un metadato, dovrà essere possibile verificare le strutture che ad esso confluiscono e
quelle di derivazione, eseguendo agevolmente Impact Analisys e Data Lineage; Infine, la
piattaforma deve garantire in modo affidabile la ricerca, il rilevamento, il riuso e la
pubblicazione degli oggetti, sotto forma di gerarchie, misure e metriche.
B.12. La piattaforma deve fornire strumenti di sviluppo delle applicazioni BI, tali
applicazioni devono poter essere facilmente integrabili negli attuali processi di business. La
piattaforma deve inoltre permette agli analisti, attraverso appositi SDK (Software
Development Kit), di realizzare applicazioni BI senza la necessità di scrivere codice di
programmazione, ma attraverso strumenti grafici come wizard, e processi di assemblaggio
grafici, ad esempio mediante metodologie drag&drop dei componenti.
B.13. L’architettura della piattaforma deve essere aperta ed estendibile, basandosi su
tecnologia SOA (Service Oriented Architecture) e su Web Service Interoperabili
B.14. Nell’ottica di autonomo sviluppo di prodotti di business intelligence, anche grazie
all’acquisizione delle necessarie competenze, la piattaforma dovrà consentire, anche a
personale non tecnico, la costruzione di report e cruscotti informativi attraverso processi
intuitivi di creazione (Wizard). La piattaforma dovrà garantire la massima integrazione con
gli strumenti di office automation (principalmente fogli di calcolo e presentazione via
diapositive). I report potranno essere il risultato di aggregazione di dati provenienti da più
fonti informative, anche fisicamente separate, ma logicamente unificate. Lo soluzione
proposta dovrà, inoltre, permettere la distribuzione e la realizzazione di report operativi,
sintetici, analitici e report dinamici navigabili, in cui la domanda informativa sia sempre
25 / 47
identica, permettendo la produzione d’istantanee informative diverse nel tempo, ma con il
medesimo layout, pubblicabili in vari canali verso un numero di utenti significativo.
B.15. Devono essere disponibili Strumenti di reportistica: per la creazione di report con
formati personalizzabili, interattivi, e fortemente scalabili. Inoltre, dovrà essere consentito
l’utilizzo di funzionalità di anteprima e di schedulazione nella distribuzione del report
stesso. Dovrà essere messa a disposizione un’ampia gamma di stili e formattazioni
personalizzabili su aree di business note (area finanziaria, del personale, gestione
documenti, ecc.). Inoltre, dovrà essere possibile distribuire il report in vari formati (ad
esempio HTML, PDF, XLS, ecc.). I report dinamici dovranno avere la funzionalità drill-
down, drill-up, drill-through e con possibilità di creare link dinamici (anche
parametrizzabili).
B.16. Devono essere disponibili Dashboards: per la creazione e pubblicazione, da parte
dell’utente, di appositi grafici informativi intuitivi, sfruttando componenti di base quali
tachimetri, misuratori, quadranti, semafori; questi tipi di oggetti devono essere collegati alle
performance di una metrica rapportata al valore soglia/obiettivo che si vuole raggiungere. Si
dovrà garantire la possibilità di poter dinamicamente cambiare i valori soglia/obiettivi,
eseguendo in questo modo sommarie previsioni e analisi di tipo “WHAT-IF”. Infine, sarà
considerato come elemento migliorativo la funzionalità di analisi tipo “real-time”;
B.17. Ad hoc query: la piattaforma deve essere dotata di tools in grado di soddisfare in
autonomia il bisogno informativo dell’utente finale, in particolare, l’utente deve essere
libero dal supporto IT nel realizzare e pubblicare propri reports; lo strumento deve essere
dotato di un forte strato semantico per permettere all’utente di navigare nella sorgente dati,
prelevando gli oggetti di suo interesse e costruendo dinamicamente il report attraverso
tecniche di tipo drag&drop. Infine, lo strumento deve garantire preventivamente la verifica
della qualità del report, e di eventuali problemi di performance;
B.18. Integrazione con strumenti di office-automation: il prodotto dovrà essere integrato
con almeno una suite di office-automation, in particolare con gli strumenti del foglio di
calcolo e della presentazione via diapositive, il collegamento ai dati deve essere diretto e
rispettare tutte le regole di sicurezza imposte dai sistemi sovraordinati;
B.19. Funzioni di stampa: lo strumento dovrà prevedere funzionalità avanzate per la
stampa su moduli con spazi predefiniti da riempire quali cedolini, moduli fiscali, bollettini;
26 / 47
inoltre, dovrà prevedere la possibilità sia di stampe on-line, che di stampe eseguite in
modalità batch. Non vi dovranno essere particolari limiti sulle tipologie delle stampanti.
B.20. L’utente deve essere messo in grado di fare query e calcoli senza dover
necessariamente comprendere il funzionamento del database o avere conoscenze specifiche
di un particolare query-language. In particolare si dovrà poter usufruire di:
a. Accesso a tecnologia di tipo OLAP: l’On-Line Analytical Processing, che designa un
insieme di tecniche software per l'analisi interattiva e veloce di grandi quantità di
dati; questo tipo di analisi si basa in genere sulla tecnica così detta di “slicing-
dicing”; la piattaforma non deve avere particolari limitazioni di accesso verso le più
diffuse fonti dati multidimensionali o relazionali sempre basate su tecnologie OLAP;
b. Visualizzazione avanzata: lo strumento deve permettere la visualizzazione di
numerosi aspetti del dato attraverso oggetti di tipo figure e grafici, e non solo
mediante banali analisi del dato su righe e colonne; sono considerate elemento
migliorativo le soluzioni che permettono di sfruttare la tecnologia OLAP mediante
tecniche di slicing and dicing di tipo grafico;
c. Analisi multidimensionale: la piattaforma dovrà garantire l’accesso e la navigazione
su strutture logico/fisiche di tipo multidimensionale.
L’offerente all’interno dell’offerta tecnica dovrà descrivere nel dettaglio le funzionalità della
piattaforma di BI che intende offrire e dare evidenza del rispetto dei requisiti sopra descritti.
Caratteristiche Piattaforma di Integrazione (PI) (Non obbligatorie soggette a
valutazione di qualità)
P.1. La piattaforma tecnologica ed applicativa deve essere capace di disaccoppiare la
componente applicativa sovrastante dall’infrastruttura tecnologica sottostante, garantendo
l’indipendenza dall’HW, dal database e dai sistemi operativi.
P.2. I componenti dell’architettura del Nuovo Sistema informativo Centralizzato (NSC)
devono essere costruiti, come più volte sottolineato, su una n-tier client/server architecture,
che include i livelli: presentation, application e database. I componenti devono poter
27 / 47
comunicare attraverso i protocolli standard di mercato e devono essere basati su un singolo
repository. Il sistema si deve basare su un’architettura altamente scalabile.
P.3. La flessibilità deve essere resa possibile tramite logiche di enterprise Service-
Oriented Architecture (enterprise SOA). L’enterprise SOA deve consentire la rapida
composizione delle soluzioni e dei processi operativi, incapsulando le logiche di processo
ed esponendole come enterprise services, (ovvero piccoli componenti che ricoprono
funzionalità applicative) che possono essere ri-assemblati per comporre rapidamente nuovi
processi, in modo da soddisfare le mutevoli esigenze dell’Amministrazione.
P.4. La piattaforma proposta deve poter offrire tecnologie per la composizione e
l’orchestrazione dei processi aziendali, la composizione di applicazioni e
l’implementazione di soluzioni innovative.
P.5. La Piattaforma proposta deve poter essere scomposta in tre principali area
a. Integrazione: come middleware tecnologico di integrazione
b. Interoperabilità: come Enterprise Service Repository e Registry di servizi provenienti
dalle applicazioni ERP proprie o di terze parti e come Enterprise Service Bus (ESB)
c. Composizione e Fruizione: come ambiente di creazione e composizione di
applicazioni, consumo di servizi SOA e Business Process Management dove poter
modellare i processi e gli ambienti e le interfacce per l’utilizzo delle applicazioni
P.6. L’architettura proposta deve essere aperta agli standard attuali di mercato.
All’interno della piattaforma devono essere supportati un numero considerevole di standard.
Nella tabella sottostante sono riportati degli esempi.
N. Area Standard
1 Integrazione di persone
Accesso multicanale
Portale
Collaborazione
JAAS, JSR168, WSRP, AJAX, HTTP(S), PersonalJava,
CSS
2 Integrazione di informazioni ICE, WebDav, XML/A, JMI, XMI, CWM, ODBO
3 Integrazione di processi Web services, HTTP(S), BPEL, JCA, SOAP, JMS, CIDX,
RosettaNet
4 Piattaforma applicativa J2EE, HTTP, SMTP, XML, XSLT, WSDL, SOAP, UDDI
28 / 47
5 Sicurezza WS-Security, SAML, SSL, X.509
Ulteriori standard supportati per area tecnologica:
N. Area Standard Note
1 Metadata Infrastructure CWM, EMF, ISO 11179, ONS, UDDI, WS-
MetadataExchange, XML NDR, XML
Schema
In particolare
UDDI 3.0
2 Messaging
ICE, MTOM, SOAP and SOAP bindings,
WS-Addressing, WS-Notification, WS-
ReliableMessaging
3 Component
Frameworks
J2EE/J2SE, SCA, SDO, WSRP, XMLA
4 Foundation HTML, HTTP, HTTPS, SMTP, SQL, SSL,
XML, XSL
5 Process Definition
Languages
BPEL4People, UML 2.0, VoiceXML, WS-
BPEL
Languaggi per definire le
Semantiche di Business
6 Service Definition
Languages
EPCIS, UML, WSDL
7 Message Definition
Languages
UML, UN/CEFACT CCTS
Business Semantic Standards
8 Cross-Industry
ANSI X12, EIC, EPCglobal, ISO, OAGi -
Cross Industry, OMG, UN/CEFACT, XBRL
9 Industry-Specific
1SYNC (Retail), ACORD (Insurance), AIAG
(Automotive), BIAN (Banking), CIDX
(Chemical), HL7 (Health Care), PIDX (Oil
and Gas), PapiNet (Forest Products),
RapidNet (Chemical), RosettaNet (High
Tech), SWIFT (Banking), UNIFI (Banking)
Common Standard trasversali su tutta la piattaforma.
10 Profiles
WS-I Basic Profile, WS-I Basic Security
Profile, WS-I Sample Application
29 / 47
11 Management
CIM, CMIS, WS-Management, WS-
etadataExchange
12 Security
SAML, SPML, WS-SecureConversation,
WS-Security, WS-Trust, XACML, XML
Encryption, XML Signature
13 Policy JSR265, WS-Policy
14 Ontology Definition
Languages
OWL, RDF
15 Development Eclipse, UML
Integrazione ed interoperabilità
P.7. Il Middleware di integrazione deve disporre di una infrastruttura SOA standards-
based che fornisce connettività alle diverse applicazioni consentendo la gestione end-to-end
dell’integrazione dei processi e fornendo servizi d’integrazione cross-component, secondo i
protocolli standard di mercato (es. BPEL, XML, WS).
P.8. L’ambiente deve essere dotato delle caratteristiche di Enterpise Service Bus, e deve
disporre di funzionalità di mediazione Built-in per conciliare protocolli non compatibili,
mappe strutturali, schemi e formati di dati di applicazioni provider e consumer. La
soluzione proposta deve fornire capacità di trasporto e quequing affidabili e fornisce
meccanismi per la gestione di diversi livelli di quality-of-service in fase di runtime. Devono
essere supportate varie opzioni di connettività che includono la gestione di diversi end
point, quali: file; database; servizi Web; Java Message Service (JMS); documenti Remote
Function Call (RFC); documenti intermedi (IDOC) per l'interscambio di dati elettronici
(EDI), RosettaNet Implementation Framework (RNIF) messaging.
P.9. La applicazioni devono poter interoperare anche attraverso i Web Services. In
particolare deve essere possibile utilizzare l’infrastruttura per definire, implementare ed
utilizzare Web Services secondo gli industry standard. Lo strumento deve supportare
30 / 47
modelli di Web Service sincroni, asincroni, stateful and stateless, consentendo agli
sviluppatori di supportare diversi scenari d’integrazione.
P.10. Le funzionalità e caratteristiche dello strumento di process integration devono offrire
tutte le caratteristiche più diffuse delle componenti di un Enterprise Service Bus, quali:
a. Communication infrastructure (messaging and connectivity)
b. Request routing and version resolution
c. Transformation and mapping
d. Service orchestration
e. Process and transaction management
f. Security
g. Quality of service
h. Services registry and metadata management
i. Monitoring and management
j. Support of Standards (WS RM, WS Security, SAML, BPEL, UDDI, etc.)
k. Distributed deployment and execution
P.11. Le componenti ESB non devono essere confezionate come un prodotto stand-alone ma sono
un set di proprietà e caratteristiche fruibili nell’ambiente proposto.Le interfacce devono risiedere
all’interno di un unico repository centralizzato. P.12. L’integrazione deve essere composta da una parte di “design time” in cui si costruiscono e
gestiscono le interfacce e i processi di comunicazione e una di “run time” in cui tali modelli sono
eseguiti sui sistemi reali. L’intero sistema deve essere basato sullo standard XML che detta le regole
di archiviazione di tutte le strutture descritte nelle precedenti parti. Definito un processo di
integrazione anche i messaggi scambiati sono in formato XML.
P.13. Il sistema deve prevedere la possibilità di utilizzare adapter per i principali standard di
comunicazione: IDOCs; RFCs; Http(s); SOAP; JMS; JDBC; Mail Protocols (pop, imap, smtp).
P.14. Deve essere possibile interfacciarsi attraverso standard specifici come RosettaNet, CIDIX,
l’HL7, IHE, DICOM.
31 / 47
IV. Elementi utili al dimensionamento della fornitura
Dalla rilevazione delle attuali tipologie di utilizzo, le utenze previste sono ripartite come indicato in
tabella, per ogni area sono indicate le utenze allo start up e in vista dello sviluppo previsto
nell’ambito dei 18 mesi della fornitura :
Utenti area ERP
Utilizzatori sistema
contabile ed
amministrativo
35 – 400
Utenti del Contenzioso 30 – 60
Utenti area BI
Utilizzatori strumenti di
analisi ed ad-hoc query
5
Utilizzatori di strumenti
di reporting e dashboard
in visualizzazione
60
Utenti Area PI
Utilizzatori 65
Numero di connessioni
applicative e a database
Illimitato
V. Caratteristiche e Requisiti minimi dei Servizi Tecnici e Operativi
Nel presente capitolo verranno esposte le caratteristiche e i requisiti minimi dei servizi professionali
che dovranno essere erogati, attraverso la piattaforma applicativa, per il raggiungimento degli
obiettivi della banca dati unificata (BDU); nel seguito si farà riferimento per brevità alle seguenti
sigle
32 / 47
1. Piattaforma applicativa
2. SPT Personale Tecnico Esperto Certificato per la personalizzazione della piattaforma
3. OPE Personale Operativo Fornito nell’ambito della presente fornitura
4. TIR Tirocini di supporto alle attività operative
5. TES Personale Tecnico di SoReSa
6. PES Personale Operativo di SoReSa
Le attività relativa alla costruzione della Banca Dati Unificata si dovranno sviluppare secondo i
seguenti macro obiettivi per ognuno dei quali sono anche indicati i tempi massimi di rilascio
operativo :
Gestione Debito : 90 gg
Monitoraggio dei flussi finanziari, Anagrafe unica dei fornitori e Cruscotto di controllo
direzionale : 90 gg
Sostituzione piattaforma gestionale : 180 gg
Le tre attività dovranno essere svolte in parallelo ed essere completate al massimo entro i limiti
indicati nella proposta tecnica presentata.
Il progetto esecutivo che la Ditta Appaltatrice dovrà presentare dovrà indicare le varie fasi
operative, le attività previste e gli obiettivi da raggiungere mensilmente, per la autorizzazione
dei pagamenti, in coincidenza di altrettanti SAL mensili.
Ogni SAL dovrà quindi obbligatoriamente contenere le seguenti informazioni:
date di inizio e fine delle singole attività elementari;
lo stato delle singole attività elementari (Non-iniziata, Iniziata, Completata);
lo stato delle milestones più significative;
GG. Uomo erogati on site da Personale Tecnico SPT
GG. Uomo erogati on site da Personale Operativo OPE
Obiettivi funzionali mensili per i quali dovrà essere indicato un elemento univoco di
controllo del raggiungimento dell’obiettivo mensile.
33 / 47
Il personale previsto dalla fornitura dovrà, da un lato (Tecnici SPT), svolgere attività strettamente
tecniche, in costante affiancamento al personale tecnico di SoReSa, finalizzate alla
personalizzazione della piattaforma, dall’altro (Operatori OPE) fornire supporto operativo per il
raggiungimento degli obiettivi indicati in premessa.
Al fine di fornire al personale OPE le conoscenze e capacità operative indispensabili, è prevista una
prima fase nella quale le unità operative saranno impiegate nell’ambito dei flussi attuali di SoReSa
a supporto delle aree Debito, Contabilità e Liquidazione, sino a quando, via via che verranno
completate le attività di personalizzazione della piattaforma, le medesime unità operative potranno
poi essere impiegate per le vere e proprie attività progettuali.
34 / 47
Requisiti curriculari e gg uomo minime da erogare su 18 mesi
La ditta aggiudicataria dovrà comunque garantire on site il numero di giornate uomo indicate in tabella, per ogni tipologia sono anche indicati i requisiti curriculari minimi:
Codice Descrizione
gg uomo minime on site garantite profilo curriculare
OPE Operatore 6000Laureato Magistrale, specialistico, discipline economiche o scientifiche Buona conoscenza excel
SPT Sistemista piattaforma 1000
Laureato Magistrale, specialistico, discipline economiche o scientifiche almeno 3 anni di esperienza certificata su piattaforma presentata in gara. Il candidato deve possedere le competenze previste dal profilo EUCIP SMU pur non essendo in possesso necessariamente della certificazione corrispondente.
TIR Tirocinante 660Laureato Magistrale, specialistico, discipline economiche o scientifiche Buona conoscenza excel
La ditta aggiudicataria dovrà allegare al progetto esecutivo presentato in offerta la seguente
documentazione:
• profili curriculari del personale che si intende impiegare
• giustificativi relativi alla retribuzione del personale che si intende impiegare
Il personale dovrà rimanere invariato durante l’intero periodo contrattuale, a meno di eventi
eccezionali che dovranno essere notificati a SoReSa e il conseguente Turnover di personale, sia
Tecnico che Operativo è soggetto alla approvazione di SoReSa.
Le Attività delle unità SPT dovranno essere svolte da un numero massimo di 6 unità, eventuali
deroghe sono sottoposte alla approvazione di SoReSa.
VI. Schema di massima delle attività progettuali oggetto dei servizi tecnici e operativi
Per il raggiungimento dei seguenti macroobiettivi:
Gestione Debito
35 / 47
Monitoraggio dei flussi finanziari, Anagrafe unica dei fornitori e Cruscotto di controllo
direzionale
Sostituzione piattaforma gestionale
Sono previste le attività appresso dettagliate, per cui la Ditta dovrà comunque predisporre un
proprio gantt temporale e specificare i tempi di rilascio delle varie personalizzazioni della
piattaforma necessarie per il raggiungimento degli obiettivi previsti.
In generale gli obiettivi previsti dal progetto rappresentano un obiettivo minimo da raggiungere con
le giornate uomo previste dall’offerta e non un tetto massimo.
Pertanto, oltre alle attività di cui al progetto esecutivo, potranno essere richieste alla Ditta
aggiudicataraia, per il raggiungimento degli obiettivi indicati, ulteriori
attività/personalizzazioni della piattaforma che dovranno essere sviluppate con tempi e
modalità da concordare senza ulteriori oneri per l’amministrazione.
Aspetti preliminari e condivisione degli obiettivi creazione del Gruppo di Progetto –
Monitoraggio
Al di là degli aspetti puramente tecnici, da un certo punto di vista marginali, visto che l’architettura
del sistema proposto è ampiamente supportata dagli standard ed è già stata adottata in altre realtà
Nazionali ed internazionali, è bene sottolineare che l’adozione di un sistema di questo tipo non è di
per se garanzia di raggiungimento degli obiettivi.
Il monitoraggio dei dati contabili per essere realmente efficace richiede una azione condivisa di
controllo e di consulenza tecnico-organizzativa e il coinvolgimento di tutti gli attori regionali in
gioco nonchè il coordinamento con le altre azioni di cambiamento organizzativo già in essere e in
via di attuazione.
Inoltre, vista la pratica impossibilità di conoscere e gestire dall’esterno le mille criticità operative,
gestionali e molto spesso relazionali presenti all’interno di ogni singola azienda, e al fine di poter
contare sulla necessaria collaborazione delle risorse interne ed esterne presenti nelle singole ASL,
sembra opportuno avere un momento di condivisione nel quale concordare i dettagli del flusso di
gestione dei dati funzionale alla creazione della Banca Dati Unificata Regionale
36 / 47
Predisposizione Connettività AASSLL (Attività a Carico di SoReSa)
SoReSa di concerto con le AASSLL e AAOO predisporrà una rete di connessione su rete SPC
e basata sulla connessione di porte di dominio già disponibili per il progetto CUP regionale.
La Ditta aggiudicataria dovrà quindi garantire la connessione con le altre porte di dominio
regionali per la veicolazione dei flussi regionali oggetto della BDU.
Predisposizione Porta di dominio (Attività a Carico di SoReSa)
La cooperazione applicativa tra i domini è una funzione indispensabile per realizzare
l’interconnessione tra le pubbliche amministrazioni e lo scambio di informazioni tra i sistemi
delle organizzazioni strutturate in domini federati. Come si realizza? In sintesi, avviene
tramite un canale di interscambio basato su standard aperti (Web Services, XML, SOAP) che
agevola il passaggio di messaggi tra i domini. Grazie al Sistema Pubblico di Connettività,
ogni dominio della rete colloquia con gli altri attraverso una componente infrastrutturale di
interfaccia denominata “Porta di dominio” che svolge funzioni di barriera di ingresso per
autorizzare l’accesso alle risorse applicative della rete e tradurre i messaggi provenienti da
altri domini.
Ogni porta di dominio deve assicurare i livelli di sicurezza indicati nelle specifiche tecniche
elaborati da CNIPA, gestendo i profili di collaborazione previsti, essere in linea con gli
standard definiti per il formato dei messaggi (busta di eGovernment), verificare l’integrità dei
documenti ricevuti e la rispondenza della firma digitale allegata, controllare l’autorità che ha
emesso i certificati elettronici.
Predisposizione Infrastruttura Tecnologia ed applicativa
La piattaforma applicativa dovrà essere installata sulle macchine previste dalla fornitura di
SoReSa e configurata per l'avvio delle attività. La server farm, per analogia e omogeneità di
supporto, dovrà essere basata interamente su tecnologia HP, la ditta aggiudicataria dovrà
anche predisporre appositi servizi in cloud computing da attivare in caso di overload
operativo. La configurazione minima della server farm prevista per la fornitura è a seguente:
37 / 47
n. Descrizione Caratteristiche per nodo
3 HP Proliant
2 node Cluster
node1
CPU Intel XEON 3.4Ghz/1024
RAM 8 Gigabyte
Ctrl RAID 0/5
2 HDD 72 Ultra320 SCSI
2x NIC Gigabit
Redundant Fan Kit
Redundant Power Supply
I sistemi saranno installati nei rack già presenti nel CED di SoReSa, la fornitura si intente
esclusa di S.O. La installazione dovrà prevedere anche la predisposizione del piano di backup
e di disaster recovery c di tutte le procedere previste a norma di legge per la integrazione del
DPS aziendale.
Il progetto esecutivo dovrà prevedere al massimo entro 15 gg dalla firma del contratto la fase
di test e collaudo della piattaforma tecnica, HW, SW di base e applicativo in tutte le
funzionalità indicate nel presente documento ed esposte in sede di gara.
Questa attività sarà svolta dal personale tecnico della ditta aggiudicataria di in costante
affiancamento del personale tecnico di SoReSa al quale dovranno essere rese note le attività di
manutenzione e gestione di 1° livello.
La integrazione della piattaforma tecnologica nel dominio SoReSa dovrà essere pianificata
nel progetto esecutivo e subordinata alla accettazione da parte di SoReSa.
Formazione personale interno.
Tutte le attività tecniche del presente progetto vedranno coinvolti da un lato i sistemisti esperti
della piattaforma dall'altro i sistemisti e tecnici di SoReSa per la parte tecnica e il personale
operativo che dovrà fornire i servizi durante l'intero periodo contrattuale.
Il personale tecnico esperto sulla piattaforma, indicato convenzionalmente con la sigla SPT
dovrà quindi svolgere le attività tecniche secondo un piano di affiancamento operativo sia del
personale tecnico di SoReSa “TES” che del personale operativo esterno “OPE” secondo una
logica di formazione continua on the job. Il progetto esecutivo dovrà quindi dettagliare modi e
tempi con i quali avverrà il necessario trasferimento di conoscenze al fine di garantire in un
38 / 47
periodo massimo di 9 mesi il raggiungimento delle competenze minime necessarie allo
svolgimento di semplici compiti di gestione e personalizzazione della piattaforma.
In fase di avvio, mentre il personale tecnico SPT dovrà provvedere con i responsabili di area
di SoReSa alla analisi dei flussi e alla configurazione e personalizzazione iniziale della
piattaforma, il personale operativo della ditta aggiudicataria “OPE” dovrà a sua volta essere
formato sui principali flussi operativi di SoReSa. In questa ottica il progetto esecutivo potrà
prevedere l'utilizzo iniziale da parte di SoReSa del personale “OPE” nell’ambito di una serie
di attività ordinarie degli attuali flussi di lavoro di SoReSa.
Successivamente, una volta che si rendono disponibili le nuove funzioni operative della
piattaforma, il personale operativo verrà progressivamente spostato sulle nuove attività.
Il progetto esecutivo dovrà prevedere, quale obiettivo minimo di questa fase operativa,
che almeno numero cinque unità di personale tecnico di SoReSa e/o personale operativo
in carico alla aggiudicataria, siano messi nelle condizioni di svolgere le principali attività
di gestione e personalizzazione della piattaforma.
Analisi flusso banca dati unificata.
Le rappresentazioni dei dati esposti dalle aziende sanitarie, dovranno essere coerenti ad un
format predefinito da costruire sulla base dei prefissati obiettivi di gestione; sarà quindi
costituito un gruppo di lavoro formato dal personale dell'area debito, l'area contabilità e area
legale, insieme ai sistemisti DELLA PIATTAFORMA e ai tecnici dell'area informatica con
l'obiettivo di definire la struttura dei dati da acquisire dai gestionali delle aziende sanitarie.
Il format dovrà essere esposto dai singoli gestionali in base alle specifiche di SoReSa, le varie
Ditte svilupperano le attività tecniche nell’ambito di una serie di attività gia in corso di
affidamento da parte delle AASSLL a seguito dei nuovi flussi di gestione del sistema di
gestione ordini regionale MEP
In fase di analisi dovrà essere predisposto il tracciato della anagrafe dei fornitori al fine di
catalogare e avere traccia storica non solo dei convenzionali dati anagrafici ma anche del
“comportamento” sia tecnico che etico assunto dalla ditta fornitrice nel corso della fornitura.
39 / 47
La alimentazione della banca dati non potrà prescindere dai dati relativi ai contenziosi in atto,
tali dati a tutt’oggi sono ancora su supporto cartaceo e quindi sfuggono ad ogni forma di
controllo e monitoraggio. Occorre quindi predisporre una analisi dei flussi di gestione di tali
dati al fine di verificare le funzionalità disponibili della piattaforma e le necessarie
personalizzazioni.
Attivazione procedura gestione contenzioso e acquisizione dati anagrafe fornitori -
Formazione personale AASSLL
I dati relativi alla banca dati unficata, in parte vengono acqusiti in tempo reale dai gestionali,
in parte dovranno essere caricati in piattaforma da parte del personale delle AASSLL. Il
personale delle singole AASSLL dovrà quindi essere messo in grado di effettuare una attività
di data entry, su specifico modulo web predisposto sulla piattaforma di SoReSa relativo alle
seguenti informazioni:
Contratti stipulati negli ultimi 5 anni, o comunque ancora oggetto di contenzioso,
con Ditte fornitrici di beni e servizi.
Dati relativi ai contenziosi in atto
Dati integrativi relativi alla Anagrafe dei fornitori di beni e servizi.
Per il personale delle AASSLL dovrà essere svolta a carico di SoReSa una specifica attività di
formazione e di supporto all’impiego delle nuove procedure informatiche.
Bonifica dati gestionali provenienti dalle aziende sanitarie.
I dati acquisiti secondo le rappresentazioni opportune, dalle aziende sanitarie, dovranno
essere analizzati dal gruppo di lavoro di SoReSa costituito allo scopo, al fine di analizzare la
qualità del dato e fornire all'azienda sanitaria una serie di indicazioni su eventuali carenze
organizzative e gestionali che impediscono la corretta analisi dei dati al fine di controllo di
gestione. Questa fase, in considerazione del numero di aziende sanitarie coinvolte e, sulla
scorta dell'esperienza maturata in SoReSa negli anni precedenti, è quella che presenta le
40 / 47
maggiori incognite e difficoltà. In tal senso riveste una particolare importanza la figura del
referente SoReSa che ogni direttore generale dovrà individuare all'interno del proprio staff,
con il compito di collegamento tra gli uffici amministrativi dell'azienda sanitaria e SoReSa.
Costruzione del sistema di analisi dei dati finanziari
una volta bonificata e consolidata la base dati provenienti dalle aziende sanitarie, raggiunto quindi
un livello di affidabilità minimo della fonte informativa, dovrà essere sviluppato un opportuno
sistema di analisi dei dati raccolti basato sulle tecnologie di datawarehousing.
Un Sistema di analisi di questo tipo comprende diverse tipologie di dati articolati in diversi livelli di dettaglio:
1. Dati attuali di dettaglio: sono i dati al massimo livello di dettaglio che si ritiene possano
essere utile ai processi decisionali sulla base delle esigenze note e di quelle ragionevolmente
prevedibili. In realtà, questa parte comprende non solo i dati propriamente attuali (cioè
validi al momento dell’interrogazione), ma anche una certa finestra temporale di dati storici.
2. Dati storici di dettaglio:i dati di dettaglio che superano la finestra temporale del dato
“attuale” ma che rientrano comunque nella finestra temporale del Data Warehouse vengono
collocati su supporti meno impegnativi e costosi, ma anche accessibili meno comodamente.
3. Dati aggregati: la presenza dei dati aggregati deriva da considerazioni di efficienza e
praticità in risposta alle richieste degli utenti; infatti tutte le informazioni ricavabili dai dati
aggregati sono in teoria ricavabili dai dati di dettaglio, ma ciò richiederebbe di volta in volta
il loro ri-calcolo. In questo modo, però, non potranno essere soddisfatte esigenze non
previste che richiedano aggregazioni diverse da quelle predisposte, ma a questo scopo sono
comunque conservati i dati di dettaglio.
Il concetto di multidimensionalità si traduce nella metafora del cubo per la rappresentazione dei
dati. Secondo questa metafora, gli eventi corrispondono a celle di un cubo i cui spigoli
rappresentano le dimensioni di analisi. Ogni cella del cubo contiene un valore per ciascuna misura.
Dunque, rappresenta un insieme di eventi, descritti quantitativamente da misure numeriche ove ogni
asse del cubo rappresenta una possibile dimensione di analisi; ciascuna dimensione può essere vista
a più livelli di dettaglio da attributi strutturati in gerarchie. In particolare, un Cubo OLAP è una
41 / 47
struttura per la memorizzazione di dati che permette di eseguire analisi in tempi rapidi, superando
un limite dei database relazionali
Queste informazioni potranno essere utilizzate per le funzioni di supporto e assistenza in materia di
controllo di gestione delle Aziende Sanitarie così come richiesto nella legge finanziaria.
.
Definizione flusso gestione debito.
Una volta completata l'attivazione della banca dati, in parallelo alla bonifica dei flussi informativi
provenienti dalle aziende sanitarie, verrà avviata la definizione del flusso della gestione del debito,
sulla scorta dell'esperienza maturata in SoReSa negli anni precedenti. Il medesimo gruppo di lavoro
che già oggi sta operando sul tema opererà a supporto dei sistemisti della piattaforma per la
automatizzazione e implementazione del flusso operativo. Naturalmente anche questo flusso potrà
giovarsi delle attività tecniche e di personalizzazione della piattaforma già svolte per la banca dati
unificata.
Completamento piattaforma applicativa – Migrazione piattaforma MEP
la piattaforma applicativa sarà personalizzata sulla base dei moduli relativi alla contabilità e alla
gestione ordini e fatture indispensabili per la predisposizione del flusso di lavoro relativo alla
centralizzazione acquisti. Tutte le funzioni dell'attuale piattaforma sia la parte ordini che per la parte
contabilità, comprensivi dei moduli di dematerializzazione delle fatture, dovranno integralmente
essere riprodotti sulla nuova piattaforma. Il progetto esecutivo dovrà prevedere tutte le attività
tecniche e organizzative necessarie a garantire la switch trasparente delle funzionalità dalla vecchia
alla nuova piattaforma, in altri termini di utenti dovranno poter operare in continuità senza che
venga loro somministrata alcuna nuova formazione
Gestione Evolutiva
In corso d’opera, a seguito di adempimenti normativi o di prescrizioni della amministrazione
regionale o centrale, si possono rendere necessari adeguamenti del progetto esecutivo approvato in
sede contrattuale.
42 / 47
La Ditta aggiudicataria, in questo caso, dovrà garantire comunque a pari condizioni, la ridefinizione
e riprogrammazione delle attività previste nel progetto esecutivo che pertanto dovrà essere
aggiornato e sottoscritto nuovamente in contraddittorio con il Responsabile di SoReSa.
VII. Requisiti minimi del Contratto di manutenzione
È richiesto che la fornitura della piattaforma e dei servizi tecnici includano per l’intero periodo
contrattuale un servizio di manutenzione che copra integralmente, hardware, software di
base della piattaforma e relative personalizzazioni a partire dal momento della data di firma
del contratto; i servizi di manutenzione ed assistenza hanno lo scopo di garantire, a
condizioni prestabilite, l'assistenza da parte di personale tecnico specializzato e la
conservazione in efficienza del prodotto installato presso il Cliente nei termini e con le
modalità più avanti descritti.
I servizi previsti sono i seguenti:
• Manutenzione ordinaria
• Assistenza all'utente tramite Help Desk
• Assistenza all'utente on-sìte/ remota
• Manutenzione evolutiva.
Descrizione Dei Servizi
Manutenzione ordinaria
Per l'espletamento del servizio di Manutenzione Ordinaria è espressamente e
formalmente incaricato un responsabile del corretto andamento della
manutenzione e della soluzione delle problematiche tecniche di qualsiasi genere.
Il Servizio di manutenzione ordinaria prevede le seguenti prestazioni:
a) preparazione di nuove release o aggiornamenti del Prodotto in sostituzione
di quelle già
rilasciate a seguito di:
• allineamenti a nuove release del software di base di riferimento
43 / 47
• modifiche che si rendessero necessarie a seguito di mutamento di
disposizioni nazionali e regionali legislative e/o fiscali. Tali modifiche
sono apportate in regime di manutenzione ordinaria purché
l'adattamento dei programmi alle suddette disposizioni non comporti il
rifacimento sostanziale del Prodotto nel suo complesso
b) istruzioni per il temporaneo superamento di eventuali malfunzionamenti che
siano stati opportunamente documentati dal Cliente (work-around)
c) aggiornamento della documentazione tecnica relativa al Prodotto oggetto
della licenza
d) distribuzione di informazioni relative al Prodotto quali:
• livelli di aggiornamento
• nuove funzioni offerte
• evoluzioni del Prodotto
Assistenza all'utente tramite Help Desk
Assistenza telefonica
Consiste nella trasmissione di istruzioni verbali al fine di guidare il personale del Cliente alla
soluzione del problema denunciato e comunicato con le modalità di seguito riportate. Nel caso
che l'assistenza verbale non sia sufficiente a risolvere il problema si procederà con altri tipi di
intervento (Tele assistenza e/o assistenza on-site) quando contemplati nel Contratto.
L'intervento si conclude solo dopo verifica telefonica che le istruzioni fornite abbiano
consentito la soluzione del problema.
Tele assistenza
Consiste nella assistenza tramite collegamento con il sistema del Cliente in modo da
consentire al fornitore di operare sul sistema stesso. Le modalità di collegamento possono
essere le seguenti:
44 / 47
• attivazione da parte del Cliente di una linea telefonica commutata o ISDN con idoneo
modem/router
• attivazione da parte del Cliente di un accesso alle rete Internet.
Assistenza all'utente on-site / remota
L'Assistenza on-site prevede interventi di specialisti del fornitore presso il Cliente per il
numero prestabilito di giorni/uomo al fine di:
a) risolvere problemi denunciati dal Cliente causati da condizioni indicate al precedente
punto 3.1 "Limitazione al servizio di manutenzione ordinaria"
b) effettuare interventi preventivi atti a migliorare l'utilizzo, a mantenere il tuning del
sistema ed ottimizzare il Data base
c) installare nuove release o personalizzazioni frutto di manutenzione evolutiva del
Prodotto con eventuale conseguente riallineamento degli archivi
d) effettuare attività di allineamento/formazione agli utenti o agli amministratori di sistema
Manutenzione evolutiva
nuove personalizzazioni della piattaforma atti a risolvere specifiche esigenze del Cliente
manutenzione di personalizzazioni, integrazioni e sviluppi ad hoc effettuate con la fornitura iniziale
o successivamente alla stessa
MODALITÀ DI EROGAZIONE DEI SERVIZI DI MANUTENZIONE ED ASSISTENZA
Il Cliente provvede a nominare uno o più System Administrator del Prodotto quali interfaccia
permanente con il fornitore .
Che a sua volta sia il capoprogetto on-site che un servizio di Call Center a cui si devono rivolgere i
System Administrator del Cliente.
Il Call Center provvede all'accoglimento telefonico delle richieste di intervento ed effettua una
prima azione di filtro catalogando la gravità del malfunzionamento segnalato:
45 / 47
Livello 1 : l'intero sistema è indisponibile agli utenti;
Livello 2: funzionalità critiche del sistema sono indisponibili agli utenti;
Livello 3: funzionalità non critiche del sistema sono indisponibili agli utenti;
Livello 4: funzionalità non critiche del sistema sono indisponibili, ma non c'è immediato
impatto sulla operatività degli utenti.
Livelli di servizio per le attività tecniche previste in gara.
La Ditta aggiudicataria deve indicare in offerta i livelli minimi di servizio in termini di:
Td Tempo massimo di disservizio espresso in ore
Tp Tempo di ritardo espresso in giorni nella consegna delle personalizzazioni come previsto dal
gantt di progetto
I livelli di servizio minimi che devono essere garantititi prevedono Td come da tabella, Tp = 7 gg
lavorativi
Livello Guasto Td Tempo max di disservizio (h lavorative) 1 8 h 2 16 h 3 72 h
Il calcolo di Td decorre dalla segnalazione del problema effettuata da SoReSa tramite email
all’indirizzo che verrà indicato dalla Ditta aggiudicataria.
Il Calcolo di Tp decorre trascorso il giorno indicato per il rilascio della personalizzazione prevista
dal progetto esecutivo
In particolare, si considera ripristinata la funzionalità anche tramite l’adozione di un bypass, un
workaround o un circumvention che consentano il ripristino delle funzionalità principali, purché
seguito dalla immediata correzione definitiva.
Qualora non siano rispettati i livelli di servizio, troveranno applicazione le seguenti regole:
(i) SoReSa dovrà informare il Fornitore per iscritto di qualsivoglia intervento che abbia avuto
risposta in tempi maggiori dello SLA;
46 / 47
(ii) (ii) il Fornitore esaminerà tale richiesta e fornirà una relazione scritta che confermerà oppure no la
correttezza dell’inadempimento;
(iii) (iii) ove sia necessario, SoReSa dovrà fornire al Fornitore una ragionevole assistenza per consentirle
di rispettare gli SLA;
TABELLA - CALCOLO DELLE PENALI
Voce Penale Modalità di calcolo
Ritardo nella consegna
delle personalizzazioni
0,1% dell’importo contrattuale per ogni
giorno di ritardo
NA
Ritardo nel ripristino
del sistema
0,01% dell’importo contrattuale per ogni ora eccedente il livello massimo previsto dalla tipologia di guasto .
VIII. Piano finanziario
Quadro economico di massima per fornitura iniziale su 18 mesi
Sistemisti (SPT) € 700.000,00
Operatore (OPE) € 1.188.000,00
Tirocini (TIR) € 49.500,00
Hardware e Licenze comprensive 18 mesi manutenzione € 550.000,00
Licenze aggiuntive comprensive 18 mesi manutenzione € 150.000,00
Importo totale presunto € 2.637.500,00
Quadro economico di massima per estensione su ulteriori 6 mesi
Attività operative e manutenzione per ulteriori 6 mesi
Sistemisti (SPT) € 100.000,00
Operatore (OPE) € 396.000,00
Tirocini (TIR) € 16.500,00
Manutenzione Licenze € 65.000,00
Importo presunto € 577.500,00
IX. Gantt di Progetto di massima
ID Modalità
attivitàNome attività
1 Aspetti preliminari e condivisione degli obiettivi creazione del Gruppo di Progetto –
2 Predisposizione Porta di dominio SoReSa3 Predisposizione Connettività AASSLL 4 Verbale Consegna attività BDU5 Predisposizione Infrastruttura Tecnologia ed
applicativa6 Formazione personale interno7 Analisi flusso banca dati unificata8 Attivazione procedura gestione contenzioso
e acquisizione dati anagrafe fornitori ‐ Formazione personale AASSLL
9 Costruzione del sistema di analisi dei dati finanziari 12
10 Bonifica dati gestionali provenienti dalle aziende sanitarie
11 Definizione flusso gestione debito12 Completamento piattaforma applicativa –
Migrazione piattaforma MEP13 Conduzione tecnica operativa14 Attività operativa15 Gestione Evolutiva . 1316 Attività di monitoraggio
Responsabile Area Finanza SoReSa[5%];Responsabile Area Informatica SoReSa[5%];UO Assessorato[10%]
02/09
Hardware[1];Licenze Piattaforma[1];Sistemisti SPT[200%]
Sistemisti SPT[300%];Responsabile Area Debito SoReSa[10%];Responsabile Area Finanza SoReSa[10%];Responsabile Area Informatica SoReSa[10%]
Sistemisti SPT;Responsabile Area Debito SoReSa[10%]
Sistemisti SPT[200%];Responsabile Area Debito SoReSa[5%];Responsabile Area Finanza SoReSa[5%];Responsabile Area Infor
Sistemisti SPT[200%];Responsabile Area Finanza SoReSa[5%];Responsabile Area Debito SoReSa[5%]
Responsabile Area Debito SoReSa[5%];Responsabile Area Finanza SoReSa[5%];Responsabile Area Informatica SoReS
Sistemisti SPT;Responsabile Area Debito SoReSa[10%]
Responsabile Area Liquidazioni SoReSa[5%];Responsabile Area Informatica SoReSa[5%];Responsabile Area Fina
Estensione Licenze [1];Sistemisti SPT[200%]
Operatore OPE[1.500%];Tirocini TIR[500%]
Responsabile Area Informatica SoReSa[5%];UO Assessorato[10%];Responsabile Area
M D V M L S G M D V M L S G M D V M L S G M D V M L S G M21 feb 11 16 mag 11 08 ago 11 31 ott 11 23 gen 12 16 apr 12 09 lug 12 01 ott 12 24 dic 12 18 mar 13 10 giu 13 02 set 13 25 nov 13 17 feb 14
