Capitolato Tecnico
Servizio Innovazione Tecnologica
ALLEGATO A
Capitolato Tecnico
PROCEDURA APERTA PER LA FORNITURA DI UN SOFTWARE DI GESTIONE DOCUMENTALE E APPLICATIVI CORRELATI DEL TIPO DOCUMENT MANAGEMENT SYSTEM. DETERMINA A CONTRARRE N. 203 DEL 15.11.2011 CIG. 3561692138
Software di Gestione Documentale e Applicativi correlati Document Management System
Procedura aperta per la fornitura di software tipo Gestione Documentale, con software correlati per la Gestione Giuridica del Personale,
Gestione Concessione Beni e Xxxxxxx, Gestione Xxxxxxxxx Xxxxx,
fornitura di servizi di manutenzione e servizi accessori, per la implementazione, personalizzazione e gestione di detto software
1. PREMESSA 3
2. OGGETTO DELL’ APPALTO 5
2.1. Fornitura di software applicativo (Componenti A , B, C) 6
2.2. Servizio di manutenzione 9
2.3. Attività di supporto specialistico 9
2.4. Servizio di formazione 10
3 CRONOPROGRAMMA | 10 | |
4 REQUISITI TECNICI DEL SISTEMA | 11 | |
4.1 Architettura applicativa del DMS | 11 | |
4.2 Requisiti tecnico/funzionali del DMS | 11 | |
5 FUNZIONALITÀ DEL DMS | 12 | |
5.1 Caratteristiche Generali | 12 | |
5.2 Processi di acquisizione dei Dati e dei Documenti | 14 | |
5.3 Tracciatura delle operazioni | 14 | |
5.4 Sistema di Reportistica | 15 | |
5.5 Modulo profilazione | 15 | |
5.6. Moduli di Monitoraggio | 16 | |
6 PRINCIPALI PROCESSI CHE IL DMS DEVE SUPPORTARE | 16 | |
7 SLA | 18 |
1. PREMESSA
L’ Ente Foreste della Sardegna intende dare attuazione alla realizzazione della infrastruttura tecnologica su sistemi in propria dotazione, sottesa alla gestione di una serie di procedure critiche connesse ad ambienti eterogenei. In questo quadro l’ obiettivo della presente procedura è l’ acquisizione di una adeguata soluzione alla Gestione Documentale, alla Gestione Giuridica del Personale, alla Gestione Concessioni beni e Pascoli e alla Gestione di Richieste di Xxxxx. Il sistema in oggetto verrà di seguito denominato Document Management System (DMS) dell’ Ente Foreste della Sardegna.
Il presente capitolato illustra dunque le specifiche necessarie ai concorrenti per permettere la presentazione delle soluzioni da fornire.
Il concorrente, pertanto, dovrà descrivere le modalità e le caratteristiche della soluzione proposta capace di supportare la gestione delle procedure e dei servizi richiesti.
Con riferimento alla normativa vigente si ricorda che:
Nel sistema giuridico italiano, nel giugno 2002, con il documento ufficiale dal Ministro per l’Innovazione e le Tecnologie intitolato “Linee guida del Governo per lo sviluppo della Società dell’Informazione nella legislatura” è stata introdotta la definizione nominale di “open source”, in particolare, al capitolo 1.2 si riporta la seguente considerazione: “Si diffonderanno gli standard aperti e i software open source, cioè i software liberi, la cui proprietà non sia di un singolo fornitore ma governati da una licenza d’uso che ne garantisce la possibilità di libero utilizzo, scambio, studio e modificabilità.”.
In data 19 dicembre 2003 il Ministro per l’Innovazione e le Tecnologie ha emanato una Direttiva “Sviluppo ed utilizzazione dei programmi informatici da parte delle pubbliche amministrazioni.” il cui contenuto è stato, poi, posto a fondamento di alcune disposizioni contenute nel Decreto Legislativo 7 marzo 2005, n. 82 “Codice dell'amministrazione digitale”. In tale Direttiva il Ministro per l’Innovazione espressamente prevedeva, all’art.3 che “1. Le pubbliche amministrazioni, nel rispetto della legge 7 agosto 1990, n. 241 e del decreto legislativo 12 febbraio 1993, n. 39, acquisiscono programmi informatici a seguito di una valutazione comparativa tra le diverse soluzioni disponibili sul mercato. 2. In particolare, valutano la rispondenza alle proprie esigenze di ciascuna delle seguenti soluzioni tecniche: a) sviluppo di programmi informatici ad hoc, sulla scorta dei requisiti indicati dalla stessa amministrazione committente; b) riuso di programmi informatici sviluppati ad hoc per altre amministrazioni; c) acquisizione di programmi informatici di tipo proprietario mediante ricorso a licenza d'uso; d) acquisizione di programmi informatici a codice sorgente aperto; e) acquisizione mediante combinazione delle modalità' di cui alle lettere precedenti.”. All’art. 4 la Direttiva prevede, inoltre, che “Le pubbliche amministrazioni, nella predisposizione o nell'acquisizione dei programmi informatici, privilegiano le soluzioni che presentino le seguenti caratteristiche: a) soluzioni informatiche che, basandosi su formati dei dati e interfacce aperte e standard, assicurino l'interoperabilità e la cooperazione applicativa tra i diversi sistemi informatici della pubblica amministrazione, salvo che
ricorrano peculiari ed eccezionali esigenze di sicurezza e segreto; b) soluzioni informatiche che, in assenza di specifiche ragioni contrarie, rendano i sistemi informatici non dipendenti da un unico fornitore o da un'unica tecnologia proprietaria; la dipendenza è' valutata tenendo conto dell'intera soluzione; c) soluzioni informatiche che, con il preventivo assenso del C.N.I.P.A. ed in assenza di specifiche ragioni contrarie, garantiscano la disponibilità del codice sorgente per ispezione e tracciabilità da parte delle pubbliche amministrazioni, ferma la non modificabilità' del codice, fatti salvi i diritti di proprietà intellettuale del fornitore e fermo l'obbligo dell'amministrazione di garantire segretezza o riservatezza; d) programmi informatici che esportino dati e documenti in più formati, di cui almeno uno di tipo aperto.”.
Il Decreto Legislativo 30 dicembre 2010 n.235 entrato in vigore il 25/01/2011 non fa che rinforzare tale disciplina privilegiando le soluzioni siano open source che chiuse che consentano all’Amministrazione un risparmio ed una efficienza superiore.
Con riferimento all’oggetto del servizio richiesto, il concorrente dovrà mettere in evidenza l’ aspetto “documentale” in ogni procedura proposta, essendo questo l’ obiettivo che l’ EFS vuole perseguire. Si tratta quindi di fornire e mettere in sevizio non tanto una mera piattaforma RDBMS che permetta la gestione dei dati e delle funzionalità relative ad ogni procedura richiesta, ma soprattutto una adeguata piattaforma documentale che permetta una efficiente gestione dei documenti correlati.
Attualmente l’ EFS dispone di una proprio sistema informativo distribuito sul territorio. Più precisamente l’ Ente è dotato di un CED CENTRALE dislocato nella sede di Cagliari dove sono collocati le seguenti procedure:
Gestione delle paghe: procedura Zucchetti con DataBase MS-SQL 2008 64bit Gestione presenze: procedura Zucchetti con Database MS-SQL 2008 64bit Gestione contabile : procedura Civilia con Database Oracle Rel . 10.2 Gestione del protocollo : procedura CSE con Database Lotus Domino Rel. 8.x Gestione dei BackUp: procedura Legato Networker Rel. 6.2
Gestione Concessioni beni e Pascoli: procedura EFS su IBM/Lotus Approach Rel. 9.8
Gestione Xxxxxxxxx Xxxxx: procedura EFS su IBM/Lotus Approach Rel. 9.8
L’ Ente è inoltre dotato di CED Periferici disclocati in ogni servizio territoriale (Oristano, Sassari, Nuoro, Lanusei, Tempio, Decimomannu ) dove sono collocati i Server che ospitano le seguenti procedure:
Gestione contabile : procedura Civilia con Database Oracle Rel. 10.x
Gestione del protocollo : procedura basata su Database Lotus Domino Rel. 8.x
Gestione dei BackUp: procedura Legato Networker Rel. 6.2
Tutti i server sono di recente fornitura (anni 2008 /2011 ) e non si richiede quindi la sostituzione di server . Non è richiesta altresì’ la sostituzione di database, software di gestione attualmente in servizio quali la Gestione del Personale, la Gestione delle Presenze, la gestione Contabile e la Gestione del Protocollo.
Il sistema offerto verrà dunque, nel suo insieme, strutturato in maniera tale da salvaguardare gli investimenti che l’ Ente ha avviato sia per quanto riguarda l’ Hardware, il Software e soprattutto le conoscenze degli operatori e degli amministratori del Sistema Informativo. A tal fine sarà compito dell’amministrazione fornire tutte le informazioni relative al funzionamento e interfacciamento dei sistemi presenti.
Il presente progetto prevede l’acquisizione del software e dei servizi minimi necessari al raggiungimento degli obiettivi succitati, riutilizzando, se possibile, tutte le implementazioni già in servizio, riducendo al minimo i costi di licenza.
Il presente progetto non prevede quindi l’acquisizione e la implementazione di nuovo hardware.
Sono altresì compresi nella fornitura i servizi di installazione, personalizzazione ed avviamento del sistema completo.
Al sistema dovrà essere garantita l’assistenza necessaria per il raggiungimento di un elevato livello di servizio.
2. OGGETTO DELL’ APPALTO
Oggetto del presente appalto è:
Componente A
- Fornitura di software applicativo di Gestione Documentale [SoGeDo]
- Servizi di installazione del software SoGeDo presso il CED dell’ EFS sito in Xxxxxxxx, Xxx Xxxxxxx 00; I seguenti sevizi sono richiesti:
- Servizi di manutenzione della durata minima di 12 mesi dalla data di collaudo del SoGeDo;
- servizi di personalizzazione del prodotto;
- Svolgimento di corsi di formazione sul sistema, compreso il materiale didattico.
Componente B
- Fornitura di software applicativo di Gestione Giuridica del Personale [SoGiPe]
- Servizi di installazione del software SoGiPe presso il CED dell’ EFS sito in Xxxxxxxx, Xxx Xxxxxxx 00; I seguenti sevizi sono richiesti:
- servizi di personalizzazione del prodotto;
- Servizi di manutenzione della durata minima di 12 mesi dalla data di collaudo del SoGiPe;
- Svolgimento di corsi di formazione sul sistema, compreso il materiale didattico.
Componente C
- C1) Fornitura di software applicativo di Gestione Concessioni Beni , Pascolo e Alveari [SoBePa]
- C2) Fornitura di software applicativo di Software Richieste di Legna [SoRiLe]
- Servizi di installazione del software SoBePa e SoRiLe presso il CED dell’ EFS sito in Xxxxxxxx, Xxx Xxxxxxx 00 con conseguente utilizzo e/o installazione presso i clients dislocati nei servizi territoriali dell’ Ente ;
I seguenti sevizi sono richiesti:
- Servizi di personalizzazione del prodotto;
- Servizi di manutenzione della durata minima di 12 mesi dalla data di collaudo;
- Svolgimento di corsi di formazione sul sistema, compreso il materiale didattico.
Componente D
Laddove utilizzate e non sostituibili, fornitura di tutte le licenze necessarie al corretto funzionamento dei Sistemi sopra indicati al fine da garantire l’utilizzo ad almeno 100 postazioni client con installazione, amministrazione ed aggiornamenti per la durata minima di un anno. Saranno privilegiate soluzioni open source.
2.1. Fornitura di software applicativo (Componenti A , B, C)
2.1.A) Software di Gestione Documentale [SoGeDo];
Con la presente procedura di gara si intende acquisire un sistema di gestione documentale (di seguito SoGeDo) da installare su server in dotazione EFS.( Le caratteristiche del server sono indicate in allegato)
Obiettivo primario della fornitura sarà, pertanto, quello di acquisire una soluzione in grado di gestire il ciclo di vita dei documenti e di supportare l'evoluzione del sistema per la fruizione dei documenti da parte del personale dell’ EFS e , possibilmente, da parte delle procedure software .
Attualmente gran parte dei i documenti sono memorizzati nel database Lotus Domino gestito dal software di protocollo. Le funzionalità minime richieste al SoGeDo devono essere tali da:
a) permettere la memorizzazione di documenti di qualsiasi formato;
b) razionalizzare i flussi documentali;
c) gestire le assegnazioni dei documenti;
d) gestire fascicoli di documenti omogenei;
e) gestire il controllo di accesso ai documenti; Inoltre, l’ aggiudicatario deve garantire:
- il regolare funzionamento;
- la diagnosi e rimozione di malfunzionamenti;
- l’ adeguamento a versioni/releases successive delle componenti applicative e dei prodotti software facenti parte della soluzione;
- la fornitura di almeno una copia aggiornata della documentazione tecnica relativa ai sistemi facenti parte della soluzione.
Il concorrente dovrà dunque descrivere in sede di offerta tecnica le funzionalità del sistema proposto entro i termini e secondo le specifiche tecniche che sono analiticamente dettagliate nei capitoli successivi del presente documento.
L’ offerta dovrà dettagliare con chiarezza la soluzione proposta, essendo un punto critico del presente progetto, saranno valutate positivamente tutte le proposte che permettano di integrare, razionalizzare e semplificare i flussi documentali.
2.1.B) Gestione Giuridica del Personale [SoGiGe]
Attualmente il Servizio Innovazione Tecnologica [SIT] dell’ EFS utilizza la Gestione Paghe Zucchetti su RDBMS MS-SQL.
Il Software di Gestione Giuridica Proposta dovrà possibilmente essere in grado di colloquiare con le tabelle di detti DB.
Il software dovrà essere in grado di gestire le seguenti tabelle: B1.1) Anagrafe unica dei Dipendenti
B1.2) Matricole B1.3) Aziende B1.4) Dipendenze
B1.5) Complessi Forestali B1.6) Foreste/Cantieri B1.7) Livelli
B1.8) Rapporti di Lavoro B1.9) Contratto di Lavoro B1.10) Scatti
B1.11) Status
B1.12) Pianta Organica B1.13) Istituti previdenziali
B1.14) Anzianità / Suddivisione
Funzionalità:
- Previsione del costo aggiuntivo
- Previsioni di licenziamento
- Gestione del Fascicolo del Dipendente
- Relazione Mansionario/Livello
- Verifica Mansionario/Livello
Il software di gestione dovrà inoltre gestire statistiche , diagrammi, grafici.
L’ offerta dovrà dettagliare con chiarezza la soluzione proposta, essendo un punto critico del presente progetto, saranno valutate positivamente tutte le proposte che consentano di razionalizzare e semplificare la gestione della procedura. Positivamente saranno inoltre valutate le soluzioni che integrino la gestione documentale di cui al Punto A1.
2.1.C1) Gestione Concessioni Beni , Pascolo e Alveari [SoBePa] La procedura deve consentire:
1) di gestire l’ anagrafica del richiedente;
2) di calcolare gli oneri dovuti salla base dei pascoli e dei capi di bestiame;
3) di effettuare tutte le stampe ivi compresi i bollettini postali.
2.1.C2) Software Richieste di Legna [SoRiLe] La procedura deve consentire:
1) di gestire l’ anagrafica del richiedente;
2) di calcolare gli oneri dovuti salla base delle richieste;
3) di effettuare tutte le stampe ivi compresi i bollettini postali.
L’ offerta dovrà dettagliare con chiarezza la soluzione proposta, essendo un punto critico del presente progetto, saranno valutate positivamente tutte le proposte che consentano di razionalizzare e semplificare la gestione della procedura. Positivamente saranno inoltre valutate le soluzioni che integrino la gestione documentale di cui al Punto A1.
2.2. Servizio di manutenzione
Con riferimento alla piattaforma fornita, il concorrente è tenuto a descrivere, in sede di offerta tecnica, le modalità operative con cui sarà espletato il servizio di manutenzione per un periodo minimo di 12 mesi dalla data del collaudo della fornitura della piattaforma proposta. Il costo relativo a detto servizio è incluso nella base d’ appalto.
Il servizio di manutenzione deve riguardare:
1. correzioni al software standard (patch);
2. adeguamento del software standard a mutamenti legislativi;
3. rilascio di nuove versioni del software standard.
E’ altresì richiesto che il concorrente descriva le modalità con cui espleterà il servizio di manutenzione correttiva ed adeguativa da espletarsi nei 12 mesi successivi al completamento della fase sopra richiamata.
2.3. Attività di supporto specialistico
Il concorrente deve descrivere in offerta tecnica le modalità operative con cui sarà erogato il servizio di supporto specialistico per le attività di seguito individuate.
Si specifica che dette attività saranno “ a consumo” per un minimo di 50 ore annue e pertanto dovranno essere erogate solo a seguito di formale richiesta da parte della stazione appaltante all’ aggiudicatario e validate dalla stazione appaltante di volta in volta previa opportuna documentazione.
- Supporto alla conduzione tecnico-sistemistica e gestione operativa (Back-Office): ove necessario, la stazione appaltante potrà richiedere servizi rivolti alla gestione del Sistema Informativo che, pur non interfacciandosi direttamente con gli utenti finali del Sistema Informativo, sono essenziali per il supporto tecnico e la conduzione operativa dei sistemi.
- Supporto alla gestione dei servizi di assistenza sistemistica: ove necessario, la stazione appaltante potrà richiedere servizi di assistenza sistemistica eseguita da tecnici esperti di area sistemistica di base (sistema operativo, connettività di rete ed interoperabilità fra piattaforme tecnologiche eterogenee, database) e sistemistica specialistica per le varie componenti software oggetto del presente capitolato.
- Supporto alla manutenzione evolutiva degli applicativi: ove necessario, la stazione appaltante potrà richiedere servizi che hanno l’ obiettivo di garantire il supporto per la manutenzione evolutiva degli applicativi richiesti o per lo sviluppo di nuove funzionalità non incluse nel servizio di manutenzione indicato precedentemente.
Il servizio dovrà essere erogato da personale specializzato con l’ esperienza richiesta nell’ ambiente di sviluppo proposto.
2.4. Servizio di formazione
Oggetto della presente fornitura è altresì la realizzazione di corsi di formazione rivolti a personale tecnico informatico della stazione appaltante aventi la finalità di consentire allo stesso di acquisire un completo know how della piattaforma software proposta. I singoli corsi dovranno essere modulati per classi di non più di 12 persone.
A corredo dell’ erogazione della formazione, l’aggiudicatario dovrà fornire un’ adeguata documentazione in grado di consentire ai discenti uno studio di tipo autodidattico. L’aggiudicatario dovrà provvedere a proprio carico alla individuazione di una adeguata sede, conforme agli standard di sicurezza, per la formazione e alla strumentazione da utilizzare previo accordo con la stazione appaltante.
L’ offerente dovrà, in sede di offerta tecnica descrivere l’ attività di formazione proposta indicando:
- la tipologia dei corsi proposti;
- per ogni tipologia, indicare il numero di corsi che la stazione appaltante potrà richiedere entro il termine di 12 mesi decorrenti dalla consegna dei lavori;
- la metodologia didattica che si utilizzerà;
- la durata di ogni tipologia di corso;
- il modello di testo didattico che si intende proporre;
- le caratteristiche dell’aula in termini di dimensioni numero e configurazioni delle stazioni di lavoro, delle caratteristiche del collegamento in rete delle stazioni, supporti didattici, etc. necessarie allo svolgimento delle singole sessioni previste.
L’ubicazione della suddetta sede dovrà essere obbligatoriamente nel Comune di Cagliari ovvero Comuni limitrofi.
3 CRONOPROGRAMMA
L’ offerente dovrà indicare in offerta tecnica le tempistiche relative all’ esecuzione dell’ appalto In particolare, dovrà essere predisposto un piano di progetto che ottemperi ai seguenti requisiti:
• Completamento delle fasi propedeutiche allo start-up entro 60 giorni lavorativi dalla data di avvio lavori comunicato dalla stazione appaltante.
• Tempo di completamento della fase di insourcing (installazione presso il CED dell’ EFS della piattaforma Software con l’ eventuale porting dei dati) entro 60 giorni lavorativi dall’ inizio della fase di insourcing comunicato dall’ EFS;
• Tempo di completamento dei test e correzione di eventuali anomalie seguenti alla fase di insourcing entro i 60 giorni lavorativi a partire dalla data di completamento della fase precedente.
4 REQUISITI TECNICI DEL SISTEMA
Il concorrente dovrà descrivere in offerta tecnica la soluzione proposta ivi compresi tutti i requisiti della stessa, corredata da documenti di analisi e progettazione, diagrammi uml e schemi dei db.
E’ altresì necessario che la descrizione evidenzi come la soluzione proposta sia in grado di soddisfare tutti i requisiti richiesti nei seguenti paragrafi.
4.1 Architettura applicativa del DMS
La piattaforma DMS deve essere stata realizzata secondo le più recenti metodologie al fine di risultare modulare, efficiente e flessibile.
Costituiranno elementi di particolare rilievo, le soluzioni realizzate secondo gli standard tecnologici maggiormente diffusi, in particolare:
- Sistema Operativo: Microsoft Windows e/o Linux;
- Application Server: uno dei prodotti consolidati nel mercato ICT;
4.2 Requisiti tecnico/funzionali del DMS
4.2.1. Separazione dati
La soluzione DMS deve garantire che ciascun soggetto autorizzato possa accedere solo ai dati di propria competenza, cui sarà stato preventivamente autorizzato.
4.2.2. Dati in linea e fuori linea
Qualora si renda necessario, il DMS deve sempre consentire di procedere alla esportazione su supporti fuori linea dei dati presenti, antecedenti, ad esempio, ad una certa data (o in base ad altro parametro configurabile). Deve inoltre essere possibile il loro ripristino temporaneo al fine di poter effettuare ricerche su tali dati.
4.2.3. Aggiornamento tecnologico / normativo
Deve essere garantito l’ aggiornamento tecnologico e l’ aggiornamento ad eventuali variazioni della normativa anche in materia di privacy per tutto il periodo contrattuale.
4.2.4. Scalabilità
Deve essere garantita la scalabilità dell’ architettura nelle sue varie componenti per rispondere, ad esempio, ad eventuali incrementi di accesso o di carico o a necessità di maggiori capacità di storage.
4.2.5. Affidabilità e continuità del sistema
Devono essere dettagliate soluzioni e modalità tecniche fisiche e logiche con cui si garantisce affidabilità e continuità del sistema.
4.2.6. Backup
Devono essere dettagliate le modalità tecniche e logiche con cui si effettuerà il backup di sistemi e dati e come saranno mantenuti i backup stessi.
Attualmente i backup sono effettuati tramite il software Legato Networker. Verrà valutato positivamente un piano di Backup e recovery che sia corredato da un progetto di Tuning e manutenzione di tale sistema.
4.2.7. Sicurezza
Il sistema nel suo complesso impone particolari vincoli di sicurezza (logica, informatica, sui locali, etc.) in considerazione della delicatezza del suo compito. In sede di offerta tecnica, dovranno pertanto, essere specificati i criteri di sicurezza seguiti nella gestione del controllo di accesso ai documenti, con descrizione delle misure di sicurezza previste.
5. FUNZIONALITÀ DEL DMS
5.1 Caratteristiche Generali
Nel seguito sono riportate le caratteristiche che il DMS deve supportare, nonché delle relative funzionalità che dovranno essere garantite dalla stessa piattaforma DMS per gestire genericamente qualsiasi tipo di documento, a prescindere, quindi, dal processo di gestione richiesto.
L’ offerente deve descrivere dettagliatamente quali tipi di documenti il DMS gestisce.
E’ tuttavia necessario che il DMS proposto sia in grado di supportare almeno documenti PDF ed i formati dei documenti più diffusi.
Il DMS deve essere in grado di gestire fascicoli personalizzati e più esplicitamente:
• fascicolo del dipendente;
• richieste Legna;
• richieste Beni;
Il DMS deve essere unico per tutti gli applicativi richiesti, deve poter essere interrogabile indipendentemente dalle interfacce programmi di gestione (gestione giuridica, gestione richieste legna, gestione richieste beni).
Di seguito viene riportato un diagramma a blocchi del DMS.
A titolo esemplificativo viene evidenziato il software di gestione ERM Zucchetti che contiene varie tabelle rilevanti per la gestione giuridica del personale.
L’ obiettivo dell’ EFS è quello di arrivare ad avere un unico sistema di gestione di documenti che si correli con i vari applicativi già in servizio.
DIAGRAMMA A BLOCCHI DMS
5.2 Processi di acquisizione dei Dati e dei Documenti
Di seguito vengono illustrati i principali processi che la piattaforma DMS deve supportare.
5.2.1. Acquisizione di dati e documenti da procedure software già in servizio presso l’ EFS
Il Sistema di gestione documentale deve avere uno o più moduli che si interfaccino con i software già in servizio presso l’ EFS.
In particolare come requisito minimo deve essere sviluppato un modulo che interfacci il software ERM di Zucchetti con il software Gestione Giuridica del Personale oggetto della presente procedura di acquisto.
Di seguito sono elencate le tabelle che devono obbligatoriamente essere interfacciate:
• Tabella Anagrafe
• Tabella Matricole
• Tabella Business Units
• Tabella Agreaments
• Tabella Agreaments Level
• Tabella Qualification
• Tabella Dependency
• Tabella Profession
(si fa presente che le tabelle di cui sopra sono elencate a puro titolo esemplificativo in quanto i dati di cui alle tabelle 5.2.1.x sono in realtà contenuti in diverse tabelle , il numero totale di tabelle presenti in Zucchetti - ERM è di circa 14.000). Sarà cura del personale dell’EFS preposto al suo utilizzo fornire tutta l’assistenza in merito.
5.2.2. Acquisizione dati e documenti da utenti esterni via portale WEB
Come indicato nel diagramma a blocchi , le procedure di concessioni di beni e richieste di legna sono interfacciate con i richiedenti, tramite una modulistica digitale che dovrà inizialmente essere gestita in modalita ASP dall’ aggiudicatario. Questo per evitare che il caricamento dati venga effettuato manualmente dal personale dell’ EFS.
5.3 Tracciatura delle operazioni
Il DMS deve possedere in modo nativo la tracciatura, in apposito database, di tutte le operazioni effettuate sul DMS da parte di qualsiasi operatore abilitato.
In particolare, si richiede al concorrente di descrivere la modalità con la quale i dati nel DB possono essere utilizzati per verifica e/o onere della prova delle operazioni effettuate sui documenti.
5.4 Sistema di Reportistica
Il concorrente deve descrivere in offerta tecnica il sistema di reportistica del DMS proposto secondo le specifiche minime sotto dettagliate.
Requisiti minimi richiesti:
Il DMS deve possedere un adeguato sistema di reportistica atto a fornire una documentazione analitica su tutte le attività di rilievo. In particolare deve rendere disponibile un modulo applicativo in grado di seguire le fasi di elaborazione del sistema in base alle esigenze informative e di monitoraggio, fornendo dati di analisi e report in diversi formati di visualizzazione (grafici o tabellari).
Il DMS deve permettere di configurare le estrazioni dei dati, definendo la loro sorgente e la loro struttura e i raggruppamenti desiderati a livello di risultato.
Deve, inoltre, essere possibile configurare Report con frequenza ripetuta oppure una tantum; infine deve essere possibile definire:
• la frequenza produzione report;
• il formato documenti prodotti (ad esempi documenti excel, pdf, xml, ecc…
• eventuale spedizione tramite posta elettronica o altro (ftp).
La documentazione prodotta deve essere opportunamente organizzata e resa disponibile agli operatori abilitati. Deve essere inoltre possibile configurare report attraverso un sistema dinamico per la loro generazione e definizione basato su file di configurazione gestibile dal cliente. Le soluzioni proposte saranno oggetto di valutazione.
5.5 Modulo profilazione
Il concorrente deve descrivere il “modulo profilazione” del DMS proposto secondo le specifiche minime sotto dettagliate.
Requisiti minimi richiesti:
Il DMS deve essere dotato di un modulo per il censimento e la profilatura degli utenti che hanno accesso al servizio. Il modulo deve permettere la configurazione e le abilitazioni a differenti livelli di utenti, censendo e organizzando in macro gruppi le diverse funzionalità del DMS.
Il DMS deve gestire le seguenti tipologie di utenti:
• utente amministratore (consente di censire gli operatori);
• utenti area amministrazione ente;
• utente cittadino da Portale WEB;
Il DMS, oggetto della fornitura deve gestire le regole definite nella normativa in vigore inerente le misure minime di sicurezza dei dati. L’ offerente dovrà descrivere i profili, i ruoli e le autorizzazioni assegnati agli utenti della piattaforma in correlazione con le varie funzionalità proposte .
5.6. Moduli di Monitoraggio
Il concorrente deve descrivere i “Moduli di Monitoraggio” del DMS proposto secondo le specifiche minime sotto dettagliate.
Requisiti minimi richiesti:
Il sistema di monitoraggio, interno o esterno al DMS, deve essere in grado di:
• interpretare particolari situazioni anomale (ad esempio analizzando i ritorni dalle invocazioni di web service, monitorando il corretto funzionamento dei canali di comunicazione tra DMS ed il mondo esterno, testando l’ attivita del Data Base e delle varie componenti software coinvolte);
• tracciare l’ anomalia rilevata;
• informare opportunamente le figure individuate all'interno del centro servizi (help desk) attraverso differenti canali di comunicazione (e-mail, SMS, caselle PEC di posta certificata)
• fornire adeguata reportistica del sistema di monitoraggio.
6. PRINCIPALI PROCESSI CHE IL DMS DEVE SUPPORTARE
Il presente paragrafo descrive i principali processi, procedure e flussi che il DMS deve supportare in riferimento alle attività in carico al EFS volte alla gestione del ciclo di vita dei documenti.
Il concorrente deve descrivere in offerta tecnica le modalità con cui il DMS intende garantire la fornitura dei sotto elencate procedure
- Gestione Giuridica del Personale [SoGiGe];
- Gestione Concessioni Beni , Pascolo e Alveari [SoBePa] ;
- Software Richieste di Legna [SoRiLe];
Il concorrente deve chiarire se e quali particolari prerequisiti debbano sussistere in ordine alla realizzazione della fornitura, specificando le forniture e i servizi aggiuntivi necessari rispetto a quanto richiesto e l’ espressa dichiarazione dell’ inclusione dei relativi oneri nell’ ambito dei prezzi offerti.
6.1.B Software Gestione Giuridica del Personale [SoGiGe]
Attualmente il Servizio Innovazione Tecnologica [SIT] dell’ EFS utilizza la Gestione Paghe Zucchetti su RDBMS MS-SQL.
Il Software di Gestione Giuridica Proposta dovrà possibilmente essere in grado di colloquiare con le tabelle di detti DB.
Il software dovrà essere in grado di gestire le seguenti tabelle: B1.1) Anagrafe unica dei Dipendenti
B1.2) Matricole B1.3) Aziende B1.4) Dipendenze
B1.5) Complessi Forestali B1.6) Foreste/Cantieri B1.7) Livelli
B1.8) Rapporti di Lavoro B1.9) Contratto di Lavoro B1.10) Scatti
B1.11) Status
B1.12) Pianta Organica B1.13) Istituti previdenziali
B1.14) Anzianità / Suddivisione Funzionalità:
Previsione del costo aggiuntivo Previsioni di licenziamento
Gestione del Fascicolo del Dipendente Relazione Mansionario/Livello
Verifica Mansionario/Livello
Il software di gestione dovrà inoltre gestire statistiche , diagrammi, grafici.
L’ offerta dovrà dettagliare con chiarezza la soluzione proposta, essendo un punto critico del presente progetto, saranno valutate positivamente tutte le proposte che consentano di razionalizzare e semplificare la gestione della procedura. Positivamente saranno inoltre valutate le soluzioni che integrino la gestione documentale di cui al Punto A1.
Si richiede comunque che il DataBase dei documenti sia in tecnologia compatibile e integrabile con l’esistente ed installato sul server in dotazione all’ EFS.
6.1.C1 Software di Gestione Concessioni Beni, Pascoli e Alveari [SoBePa]
La procedura deve consentire:
1) di gestire l’ anagrafica del richiedente,
2) di calcolare gli oneri dovuti salla base dei pascoli e dei capi di bestiame,
3) di effettuare tutte le stampe ivi compresi i bollettini postali.
6.1.C2 Software Richieste di Legna [SoRiLe]
La procedura deve consentire:
1) di gestire l’ anagrafica del richiedente,
2) di calcolare gli oneri dovuti salla base delle richieste,
3) di effettuare tutte le stampe ivi compresi i bollettini postali.
7 SLA
Il concorrente deve descrivere in offerta tecnica come intende realizzare e garantire gli SLA sotto richiesti. Eventuali elementi migliorativi rispetto ai requisiti minimi indicati saranno oggetto di punteggio tecnico.
7.1. SLA del servizio di manutenzione in condizioni normali
Tipologia | SLA minimo richiesto |
Tempo massimo di intervento su base trimestrale | - 8 ore lavorative nel 100% dei casi sul trimestre. |
Tempo di risoluzione parziale o provvisoria dell’inconveniente su base trimestrale | - 95% dei casi entro 12 ore lavorative sul trimestre; - 100% dei casi entro 24 ore lavorative sul trimestre. |
Tempo di risoluzione dell’ inconveniente su base trimestrale | - 95% dei casi entro 16 ore lavorative sul trimestre; - 100% dei casi entro 24 ore lavorative sul Trimestre. |
Si specifica che per “conduzioni di urgenza” si intendono tutte quelle situazioni che impediscono l’utilizzo del sistema.
7.2. SLA del servizio di manutenzione in condizioni di urgenza
Tipologia | SLA minimo richiesto |
Tempo massimo di intervento e di identificazione del problema su base trimestrale | - 4 ore lavorative nel 100% dei casi sul trimestre |
Tempo di risoluzione parziale o provvisoria dell’ inconveniente su base trimestrale | - 95% dei casi entro 8 ore lavorative sul trimestre; - 100% dei casi entro 12 ore lavorative sul |
trimestre. | |
Tempo di risoluzione dell’ inconveniente su base trimestrale | - 95% dei casi entro 12 ore lavorative sul trimestre; - 100% dei casi entro 24 ore lavorative sul trimestre |
7.3. SLA del servizio di supporto specialistico
Tipologia | SLA minimo richiesto |
Tempi e modalità per l’ attivazione di un operatore in loco | nel 90% dei casi sul trimestre sono richiesti massimo 5 giorni lavorativi dalla richiesta di intervento al fine della valutazione dell’ intervento. |
Tempi e modalità di progettazione dell’intervento | nel 90% dei casi sul trimestre sono richiesti massimo 10 giorni lavorativi dall’ conseguente alla richiesta di intervento |
Tempi e modalità di realizzazione dell’ intervento | nel 95% dei casi sul trimestre è richiesta la realizzazione dell’ intervento nei tempi prefissati in fase di progettazione a partire dalla data concordata con la stazione appaltante |
7.4. SLA del servizio di formazione
Tipologia | SLA minimo richiesto |
Tempi e modalità di attivazione | 15 giorni solari dalla richiesta di una sessione formativa |
8 ALLEGATI
Allegato 1 - Caratteristiche Software Richieste di Legna [SoRiLe]
Allegato 2 - Caratteristiche Software Concessioni Beni , Pascolo e Alveari [SoBePa] Allegato 3 - Caratteristiche Software Giuridica del Personale [SoGiPe]
Allegato 4 - Caratteristiche Server
Il Direttore del Servizio
Xxxxxxxx Xxxxxxx