Contract
Procedura aperta di carattere comunitario, volta alla stipula di un Accordo Quadro con unico Fornitore ai sensi degli artt. 54, comma 3 e 60 del D.Lgs. n. 50 del 18 aprile 2016, volta all’affidamento dei “Servizi di gestione integrata e recapito della corrispondenza automatizzata dell’INPS”, suddivisa in 4 Lotti.
ISTITUTO NAZIONALE PREVIDENZA SOCIALE Direzione Centrale Risorse Strumentali |
CENTRALE UNICA ACQUISTI |
SPECIFICHE TECNICHE DEI PRINCIPALI SISTEMI IN USO PRESSO L’INPS (Allegato 5 al Disciplinare di gara) Procedura aperta di carattere comunitario, volta alla stipula di un Accordo Quadro con unico Fornitore ai sensi degli artt. 54, comma 3 e 60 del D.Lgs. n. 50 del 18 aprile 2016, volta all’affidamento dei “Servizi di gestione integrata e recapito della corrispondenza automatizzata dell’INPS”, suddivisa in 4 Lotti.
|
Via Xxxx il Grande, 21 – 00000 Xxxx tel. x000000000000 - fax x000000000000 C.F. 80078750587 - P.IVA 02121151001
|
Sommario
1. Cenni sul sistema informatico INPS 3
1.2 Il portale intranet e modalità di integrazione con i servizi applicativi 8
1.3 Ciclo di sviluppo del software INPS 8
1.3.1 Il processo e gli strumenti di gestione del ciclo di vita del software 11
1.3.2 Il change management applicativo 11
1.4 Misure di Sicurezza e Strumenti di Interfaccia 12
1.4.1 Accesso alla rete (Virtual Private Network) 12
1.4.2 Accesso ai Web Service della SOA 12
2. Sistemi di gestione documentale e protocollo informatico in uso presso l’Istituto 14
2.1 Gestione dei Flussi Documentali (GFD) 14
2.2 Gestione Documenti Protocollati (GDP-2) 14
2.3 Protocollo Informatico Unificato (PIU - WSPIA) 14
2.4 Nuovo Sistema unico di Gestione Documentale (SGD) 15
3. Sistemi di predisposizione, preparazione e gestione della corrispondenza in uscita 17
3.1 Sistemi di generazione della Corrispondenza Massiva in uscita 17
3.1.1 STDP (Sistema Trasmissione Dati Postali) 17
3.1.2 CEU (Comunicazioni Epistolari con l’Utenza) 18
3.1.3 CDPU (Composizione Documentale della Posta in Uscita - Mailroom out) 19
3.1.4 Generazione da Contact Center 19
3.1.5 CEU e STDP: Elementi comuni 20
3.2 Sistemi relativi alla ricezione dei “ritorni” 20
3.2.1 Richiesta originale della cartolina A/R e copia conforme 21
3.2.2 Restituzione delle archiviazioni ottiche e richiesta di cancellazione 21
3.3 Procedure di invio comunicazioni in uscita con metodi non tradizionali 24
3.4 Cassetta Postale on-line 24
3.5 Cruscotto di monitoraggio delle comunicazioni spedite all’utenza 24
1. Cenni sul sistema informatico INPS
L’INPS ha da sempre un ruolo centrale nel sistema di Welfare e gestisce uno dei più grandi patrimoni di dati e applicazioni del sistema Italia; attraverso la gestione dei sistemi informativi basati sui dati anagrafici, retributivi e pensionistici della maggioranza degli italiani offre fondamentali servizi per la vita quotidiana dei cittadini. Le tecnologie dell’informazione e della comunicazione rivestono un ruolo centrale per la realizzazione ed erogazione di questi servizi pertanto è necessario che il sistema informatico dell’Istituto sia fondato su di un’infrastruttura allineata allo stato dell’arte e disponibile 24 ore al giorno e per ogni giorno dell’anno.
Il sistema informatico dell’INPS è un sistema complesso, distribuito ed eterogeneo sia dal punto di vista delle componenti infrastrutturali sia di quelle applicative, con architetture elaborative basate su sistemi Mainframe e Unix/AIX e industry standard (Linux/Windows).
Inoltre l’architettura complessiva si avvale di una soluzione di Business Continuity e DisasterRecovery basata su di un’architettura a tre siti: due siti in campus per la continuità operativa e per la protezione dalla indisponibilità di un singolo componente (sia dell’infrastruttura IT che di quella degli impianti tecnologici a servizio del data center) e un sito di disaster recovery a protezione da eventi disastrosi.
Le
due successive figure rappresentano sinteticamente l’architettura
ICT del Data Center del Centro Elettronico Nazionale dell’Istituto.
La piattaforma Mainframe costituisce il cuore del sistema, in quanto è il repository centralizzato, data hub, dei principali archivi di rilievo nazionale (anagrafica unica, casellario…), inoltre costituisce l’ambiente applicativo/transazionale dove vengono eseguite le principali elaborazioni di massa (rinnovo e calcolo delle pensioni, gestione dei conti assicurativi, elaborazioni contributive...). L’attuale ambiente di produzione è costituito da un Cluster a due nodi interconnessi tra loro tramite architettura Parallel Sysplex, mentre l’HA per la parte dati è realizzata attraverso le funzionalità di replica dei sottosistemi a disco, i nodi del cluster sono localizzati presso i due poli del campus del Centro Elettronico Nazionale.
L’ambiente Server farm, a prevalenza Microsoft, è composto da macchine a IBM xSeries, IBM Blade Center, con Sistemi Operativi Windows 2003/2008 e middleware Microsoft .Net, IBM WebSphere Application Server e DBMS Microsoft SQL Server. L’architettura adottata per l’alta affidabilità ed il Disaster Recovery estende a tutte le componenti elaborative la funzionalità di cluster e di load balancing, mentre per quanto riguarda lo storage è basata sulle funzionalità di copia remota dei sottosistemi a disco analogamente ai sottosistemi a disco dell’ambiente Mainframe.
La Server Farm INPS è logicamente suddivisa in:
DB server;
Application Server, WEB Server;
Batch Server;
Server di Infrastruttura (servizi di directory, DNS, WINS, WSRR, ESCM, WSRR, etc.);
Infrastruttura VMWare;
Infrastruttura di backup.
I principali ambienti della piattaforma UNIX sono costituiti dalla componente del sistema informativo istituzionale della gestione exINPDAP, e dal DataWareHouse.
La piattaforma SAP è basata su piattaforma virtuale Linux e la componente DB è su sistemi Oracle Exadata
A seguito dalla legge n. 214 del 22 dicembre 2011 che prevede la soppressione degli Enti previdenziali ed il loro accorpamento nell’INPS, la DCSIT e l’omologa struttura della gestione exINPDAP ha provveduto alla realizzazione di un importante consolidamento e adeguamento dell’infrastruttura CED dell’INPDAP nei datacenter del Centro Elettronico Nazionale.
Il sistema di gestione dei processi economici, finanziari e di gestione del personale dell’Istituto si basano sul prodotto ERP SAP R/3 .
La piattaforma del Datawarehouse fornisce un supporto decisionale per i vertici dell’Istituto basata sull’elaborazione di dati statistici estratti attraverso funzione ETL (Extract-Transform-Load) dai database istituzionali.
Il Servizio di Identity & Access Management è indirizzato a gestire un infrastruttura centralizzata di user provisioning, autenticazione, autorizzazione, single sign-on ed auditing e fa riferimento ad un modello capace di fornire un framework integrato di servizi d'identità, disaccoppiato dallo strato applicativo.
Il servizio di Cooperazione Applicativa (FCAX – Porta di dominio INPS per l’eGovernment) consiste essenzialmente nel mettere a disposizione di altri enti le applicazioni e le informazioni presenti in Istituto, utilizzando gli standard di comunicazione appositamente emessi in ambito SPC- Coop.
Per i servizi IM&M (Identity Management e Access Management), FCAX (Cooperazione Applicativa e porta di Dominio) la piattaforma di riferimento è Oracle Supercluster in una architettura omogenea all’attuale architettura di campus della Server Farm che vede meccanismi standardizzati di replica tra il sito primario e secondario e garantisce, attraverso tali meccanismi, una consistenza globale dei dati ripristinati a seguito di eventi quali l’indisponibilità di un singolo componente o di un intero sito.
L’architettura di rete dei due siti in Campus del Centro Elettronico Nazionale è organizzata in diversi livelli ognuno con caratteristiche e ruoli diversi ma fondamentalmente con architetture identiche a livello di sito:
livello di Core: realizzato attraverso apparecchiature con caratteristiche architetturali simili tra loro costituisce lo strato più importante delle rete dell’Istituto. Da queste apparecchiature (Cisco NEXUS) partono le connessioni principali verso la rete interna (servizi ed utenze) e verso la connettività esterna (sedi INPS remote /DMZ/ enti esterni);
livello di distribuzione ed accesso rete interna: apparecchiature di rete che veicolano e gestiscono sia i flussi principali degli ambiente OPEN che Z/Series attestati direttamente ad essi, sia quelli verso le apparecchiature di Core. Tale ambiente è costituito da diverse tipologie di apparecchiature scalabili e ridondate che consentono l’accesso ai servizi in maniera diretta con connessioni rame e/o fibra ottica. Le apparecchiature di questo livello servono anche a veicolare le funzionalità di Bilanciamento (F5) e XML Accelerator (IBM Data Power);
livello di rete per attestazioni esterne: le apparecchiature di questo livello hanno connessioni verso la rete interna per i flussi di attestazione al core e connessioni verso l’esterno attestati alla rete di “service provider” SPC. Un esempio sono le attestazioni dei servizi Extranet/Portale/Posta elettronica. Possono essere considerati appartenenti a questo livello anche le connessioni DMZ, in quanto verso l’esterno servizi dell’Istituto.
L’architettura software dell’Istituto è multi-tier e multi-language e si è costituita nel tempo attraverso costanti interventi evolutivi. In particolare, nel corso degli ultimi anni sono state introdotte tecnologie software component-based che oltre a facilitare la rapidità di erogazione dei servizi offerti dall’Istituto attraverso la piattaforma web, consentono un efficace riuso dei componenti software stessi.
L’Area Istituzionale fa essenzialmente riferimento ai Sistemi Centrali, ossia la piattaforma z/OS che ospita le componenti CICS, IMS e DB2 sulle quali sono eseguite le applicazioni COBOL sviluppate e consolidate nel corso di molti anni e legate al core business dell’Istituto (calcolo delle pensioni, gestione dell’anagrafica unica, gestione delle contribuzioni, ecc.).
Oggi, i Servizi Applicativi che risiedono sui Sistemi Centrali sono essenzialmente dei seguenti tipi:
Base dati DB2 disponibili per accessi da componenti distribuite;
Logica di business realizzata in Java che accede alle componenti CICS/IMS/DB2;
Servizi realizzati per un accesso controllato alla base dati DB2 (ad es., query sull’anagrafica);
Transazioni CICS e IMS disponibili per accesso diretto da componenti distribuite;
Esposizione di transazioni CICS ed IMS come Consumer o Provider di Web Service
Con riferimento ai sistemi distribuiti Unix e Windows, sono presenti applicazioni JEE su piattaforma WebSphere Application Server e applicazioni .NET su piattaforma Microsoft .NET.
Le basi dati sono, per questa tipologia di applicazioni, principalmente basate sui DBMS MS SQL Server e Oracle. In particolare, le basi dati relative ai servizi Internet sono sul DBMS MS SQL Server.
Il Sistema di Data Warehouse dell’Istituto si basa su meccanismi automatici di estrazione, trasformazione e caricamento del dato, e ad oggi opera su diverse sorgenti di informazione, tra esse le principali aree sono:
Le Pensioni
I Lavoratori
Le Prestazioni a Sostegno del Reddito
Le Aziende
L’Anagrafica.
Il sistema di DWH gestisce in modo automatico l’estrazione del dato, fino alla realizzazione e presentazione dei report ed infine la storicizzazione dei Datamart, in modo da consentire nel tempo una analisi comparativa delle informazioni acquisite.
L’architettura su cui si basa il DWH si fonda essenzialmente sui seguenti software:
Infosphere Warehouse;
Infosphere DataStage;
Infosphere QualityStage;
Infosphere Information Analyzer;
Business Objects;
COGNOS.
II sistema SAP R/3 dell'INPS si compone dei seguenti moduli:
Contabilità Economico – Patrimoniale – Finanziaria;
Approvvigionamenti di beni cespite;
Contabilità industriale, budget e controllo di gestione
Personale;
Cruscotto direzionale BW (DWH);
TDMS (Test Data Management System);
Solution Manager;
PI (Process Integration);
Enterprise Portal;
SRM per la realizzazione del sistema di e-procurement dell’Istituto;
SAP Business Objects componente che si aggiunge alla suite di business intelligence e che consente il reporting evolutivo;
Componente di gestione documentale Open Text per la dematerializzazione della documentazione amministrativa.
Nel corso degli ultimi anni, l’Istituto ha progressivamente esteso l’adozione del paradigma SOA definendo standard, policy ed architettura di riferimento a livello Enterprise. Questa scelta ha reso possibile la realizzazione di architetture applicative indipendenti e di servizi riusabili e facilmente integrabili in ambienti eterogenei, che hanno, tra l’altro, consentito di:
favorire il riuso del software, secondo le indicazioni fornite da DigitPA, sia dalla prospettiva interna in ottica di riduzione dei costi, sia per quanto concerne la possibilità di condividere il consistente patrimonio applicativo di cui è dotato l’Istituto con le altre Pubbliche Amministrazioni;
accelerare i tempi di realizzazione delle nuove applicazioni attraverso l’utilizzo di componenti software già disponibili e consolidate;
garantire l'interoperabilità tra diversi sistemi consentendo l'utilizzo dei singoli servizi come componenti di un processo di business per soddisfare le richieste degli utenti in modo integrato e trasparente;
gestire in modo uniforme e centralizzato le applicazioni e i servizi esistenti attraverso una Governance unitaria.
L’architettura SOA di riferimento dell’Istituto utilizza diverse tecnologie. Di seguito alcuni dettagli riguardo alcuni specifici aspetti:
La Governance:
un Centro Governance della SOA incardinato nella DCSIT sovrintende all’applicazione di standard, policy e del processo che porta dalla identificazione alla distribuzione di un Servizio;
Un Registro dei Servizi centralizza metadati ed artefatti dei Servizi attualmente in essere nell’Istituto, supportando tecnologicamente i vari processi di Governance;
La qualità dei Servizi è garantita da componenti di sicurezza (ESB), strumenti di monitoring e di gestione (Business Monitor, tracciatura, Ibm ITCAM);
Il processo di sviluppo è supportato da componenti di coreografia e workflow management (sistema di Application LifeCycle Management, basato sulla personalizzazione del prodotto IBM BPM) che consentono la realizzazione di applicazioni composite, ad esempio basate sulla semplice orchestrazione di servizi esistenti e la gestione del workflow di sviluppo.
Da un punto di vista infrastrutturale, già da alcuni anni, i Sistemi Centrali sono parte integrante del modello SOA dell’Istituto, in particolare le componenti che ospitano le applicazioni “legacy” (CICS ed IMS) sono in grado di agire come Consumer o Provider di Servizi, riducendo così i costi di sviluppo applicativo ed accrescendo la rapidità di integrazione della piattaforma z/OS con quelle distribuite, aumentando di conseguenza il valore del patrimonio applicativo basato su COBOL.
Altro elemento importante dell’architettura di riferimento è nei framework applicativi, componenti software capaci di indirizzare specifiche funzioni comuni a tutte le applicazioni, realizzati quindi al fine di standardizzare lo sviluppo applicativo. Tale approccio, oltre a consentire un maggiore controllo, ha consentito di isolare lo sviluppo applicativo dalla complessità dalla complessità tecnologica dovuta ad aspetti comuni ed obbligatori come la sicurezza e la tracciatura dei flussi applicativi. Nello specifico, è stato realizzato un framework per ognuna delle piattaforme di sviluppo attualmente promosse dall’Istituto, ossia Java e .NET.
Per quanto riguarda il portafoglio applicativo, a fine 2015, la dimensione del patrimonio applicativo custom dell’Istituto è di oltre 220 milioni di LOC, corrispondenti a circa 5 milioni di punti funzione, dei quali circa il 74% è relativo ad applicazioni in ambiente distribuito e il 26% ad applicazioni mainframe.
I componenti applicativi archiviati nei sistemi di change management (singoli “progetti” gestiti) sono circa 4.000 (1.000 circa dei quali afferenti al sistema di gestione della previdenza e del welfare per i pubblici dipendenti, il c.d. sistema “SIN”), il 90% dei quali in ambiente distribuito. Il 10% circa di questi componenti è scritto in Cobol, il 58% in .NET, il 29% in J2EE. Le applicazioni Cobol sono mediamente più grandi di quelle in ambiente distribuito. La crescita del numero di componenti applicativi è oggi quasi esclusivamente dovuta all’ambiente distribuito.
Quasi il 53% dei componenti applicativi ha subito almeno una modifica nel 2015. La maggior parte dei rilasci in esercizio è oggi dovuta a interventi di manutenzione del software, per xxx xxx xxxxxxxxxxxxxx xxx xxxxx xxxxxxxxxxx dell’Istituto, la cui realizzazione è iniziata ormai da molti anni. Quasi la metà dei rilasci è in ambiente Cobol Mainframe (per effetto degli interventi di manutenzione), il 37% è .NET, l’12% J2EE (il resto riguarda applicazioni in altre tecnologie, residuali).
1.2 Il portale intranet e modalità di integrazione con i servizi applicativi
Il Portale Intranet è ospitato su una batteria di server Windows 2008 x64 E.E. SP2 con IIS 7.0 e Windows Server 2012 il cui servizio è distribuito tramite un bilanciatore. L’accesso al portale è gestito tramite autenticazione Windows con riconoscimento dell’utenza di rete.
I contenuti del portale, come anche le voci del menu, sono gestiti tramite un sistema di Content Management (CMS), realizzato e personalizzato all’interno dell’Istituto, che consente a diverse redazioni, attraverso un sistema di workflow, di inserire e aggiornare i contenuti di propria competenza.
Le applicazioni esposte dal Portale risiedono su server Web e sono sviluppate in ambiente Windows su server Windows 2008 x64 E.E. SP2 con IIS 7.0 o Windows Server 2008 R2 E.E. con IIS 7.5 e Framework .Net 2.0, 3.x, 4.0, 4.5 oppure in ambiente IBM WebSphere Application Server Network Deployment 7.0 su sistemi AIX per la componente middleware e su front-end Linux per la componente presentation. Le basi dati sono gestite tramite MS SQL Server 2008 e MS SQL Server 2012. Tutte le applicazioni sono accessibili dalla Intranet INPS con autenticazione tramite Single Sign On (IAM) o tramite Windows Authentication.
Per le applicazioni INTRANET è disponibile un sistema di Web Identity che permette di gestire in modo centralizzato la grafica delle applicazioni, in modo da avere all'interno del sito un'interfaccia di navigazione uniforme. Il sistema fornisce agli sviluppatori tutti gli elementi grafici e di stile necessari ad un applicativo che debba essere inserito all'interno della intranet INPS, coerentemente con gli standard di navigazione e di accessibilità fissati dall'Istituto. L’integrazione della testata del portale con le applicazioni è realizzabile richiamando un dispositivo HTTP Module centralizzato.
1.3 Ciclo di sviluppo del software INPS
Per lo sviluppo e manutenzione del software, il ciclo di lavoro standard definito in Istituto, conforme alle prescrizioni dello standard ISO/IEC 12207:2008 System and Software Engineering – Software Life Cycle Processes adattate al contesto INPS, prevede le seguenti fasi:
Definizione e avvio di un intervento
Specifica dei requisiti (raccolta, analisi e specifica, inclusi i casi di test)
Definizione change request e messa sotto configurazione del software
Specifica e richiesta degli ambienti tecnologici (per sviluppo, test ed esercizio)
Progettazione tecnica e costruzione del software, che include le attività di:
Disegno tecnico
Realizzazione
Test funzionale
Test non funzionali, che include le attività di:
Definizione del Piano dei Test
Test di Integrazione
Test Prestazionali e Stress Test
Test di Sicurezza
altri Test di Qualità (rilevazione misure di qualità del software)
Collaudo
Messa in Esercizio
Le fasi di cui sopra sono svolte di norma in maniera iterativa e incrementale, ricorrendo dove necessario allo sviluppo di prototipi.
Nella tabella che segue le fasi del ciclo sono associate ai prodotti standard di fase richiesti.
id |
Fase del ciclo |
Principali Prodotti di fase |
1 |
Definizione e avvio Intervento |
|
2 |
Specifica dei requisiti |
|
3 |
Definizione Change Request e configurazione software |
|
4 |
Progettazione tecnica e costruzione software |
|
6 |
Testing (pre-esercizio e certificazione) |
|
7 |
Collaudo |
|
8 |
Messa in esercizio |
|
I prodotti di fase, laddove siano previsti in forma di modelli e diagrammi, devono essere realizzati di norma ricorrendo al linguaggio di modellazione e alle notazioni UML (versioni più recenti, secondo le specifiche OMG e lo standard ISO/IEC 19505), salvo diversi accordi tra le parti. Ogni prodotto di fase deve essere consegnato all’Istituto in formato elettronico.
L’Istituto si riserva di richiedere, in casi particolari, cicli di sviluppo che seguono solo parzialmente la sequenza standard sopra definita. Ad esempio, nel caso di interventi urgenti e/o di piccola entità, o su applicazioni già esistenti, per le quali si dispone di una ottima conoscenza del contesto tecnico e funzionale. In particolare, tali cicli semplificati possono essere caratterizzati da:
un minore effort nelle fasi di specifica (documentazione ridotta rispetto a quella standard);
la non necessità di predisporre ex novo gli ambienti di sviluppo / test / esercizio, in quanto si presume che già esistano, in tutto o in parte (ad es. per essere stati creati a supporto di altri progetti);
il piano di test ridotto quanto a perimetro e tipologia dei test (ad es in quanto alcuni test non sono necessari non essendo stati variati requisiti funzionali o prestazionali);
la conseguente opzionalità di alcuni dei test di pre-esercizio.
Tutte le fasi del ciclo di vita standard di cui sopra sono supportate da strumenti informatici già in uso in Istituto, descritti nel successivo capitolo, che devono essere utilizzati dagli addetti allo sviluppo. In ogni caso, i prodotti di fase devono risultare compatibili con gli strumenti standard in uso in Istituto, provvedendo al caricamento di tali prodotti nei repository dell’Istituto stesso.
La fasi di change management e test pre-esercizio sono supportate da team specifici messi a disposizione dall’Istituto, che supportano i referenti dei progetti applicativi nel processo di change management, nella predisposizione dei Piani, casi e scenari di test non funzionali, nella predisposizione degli ambienti di test, di eventuali script e nel mascheramento dei dati di test, qualora necessario ai fini di salvaguardia della privacy.
Non è possibile portare in esercizio una applicazione se non si sono superati con esito positivo tutti i test previsti dal Piano dei Test.
La messa in esercizio delle applicazioni avviene in maniera controllata, a cura di team ad hoc che seguono un workflow controllato di release management.
Nel caso di fornitori esterni, le attività di sviluppo possono e sono di norma svolte presso proprie sedi, ad eccezione di quelle per le quali è necessariamente richiesta la presenza presso le sedi dell’Istituto (in particolare attività di raccolta e analisi requisiti, alcuni test svolti su ambienti messi a disposizione dall’Istituto, altre attività specifiche concordate tra le Parti in corso d’opera).
1.3.1 Il processo e gli strumenti di gestione del ciclo di vita del software
La gestione del ciclo di vita del software in Istituto è in gran parte automatizzata e centralizzata, grazie all’utilizzo di un insieme di strumenti che permettono il governo del processo di lavoro, la gestione operativa delle attività, i controlli e le verifiche. In sintesi:
la definizione del budget degli interventi di sviluppo e il loro affidamento ai fornitori sono gestiti dai Referenti applicativi sul sistema GeCo dell’Istituto; a valle della approvazione dell’intervento e dell’affidamento dello stesso da parte dell’Istituto, i fornitori possono iniziare ad operare;
per il governo del processo di sviluppo e MEV software è disponibile una piattaforma di Application Lifecycle Management (basato sulla personalizzazione del prodotto IBM Business Process Manager), sul quale i Referenti applicativi, Dirigenti, sviluppatori, team di supporto al change management, al test e alla gestione sistemistica degli ambienti di sviluppo, test e collaudo possono definire e gestire le attività di loro competenza nel workflow di lavoro, scambiandosi informazioni e documentazione e tracciando quanto effettuato;
per la gestione e archiviazione dei requisiti del software è disponibile la piattaforma Rational Doors Next generation (DNG) con il quale sono gestiti anche i casi di test che devono permettere la verifica del soddisfacimento dei requisiti nel software sviluppato;
la gestione del processo di test è effettuata con il supporto della piattaforma Rational Quality Manager (RQM); i test non funzionali sono effettuati con strumenti della suite Rational e della suite HP Business Technology Optimization (LoadRunner, Business Process Monitor, Business Availability Center, Quality Center), nonché del prodotto CAST per alcune analisi di qualità del software.
Gli strumenti di cui sopra permettono la gestione completa del ciclo di sviluppo. E’ comunque possibile che nel ciclo ridotti (interventi urgenti, di piccola entità etc) una parte delle comunicazioni tra gli attori del processo di sviluppo sia scambiata via email, e che le informazioni relative agli asset applicativi e ai progetti di sviluppo (inclusi requisiti, casi di test, disegni tecnici etc) siano gestite con formati non strutturati (files word, fogli excel).
1.3.2 Il change management applicativo
Per la gestione delle change request nel processo di sviluppo e/o modifica del software applicativo deve essere obbligatoriamente utilizzata la soluzione SERENA Dimension, che consente la gestione e il controllo della configurazione del software e la gestione centralizzata delle informazioni relative a tutti i cambiamenti apportati al software. La piattaforma svolge anche da source code repository.
L’uso della piattaforma è assistito da un apposito team di supporto, che svolge anche funzioni di help desk di secondo livello per i problemi sull’uso del prodotto. Per gli sviluppatori che devono utilizzare la piattaforma l’Istituto organizza comunque corsi periodici di formazione in aula e rende disponibili manuali d’uso.
In sintesi, le macro fasi di Change Management supportate da Serena Dimensions sono le seguenti:
Censimento dell’applicazione nella piattaforma. Gli sviluppatori forniscono al team di supporto al Change Management le informazioni necessarie al censimento nella piattaforma di Change Management dell’applicazione su cui dovranno operare (informazioni tecniche e di descrizione funzionale dell’applicazione).
Caricamento dell’applicazione nella piattaforma. Gli sviluppatori inseriscono in appositi path predisposti dai sistemisti gli oggetti software da caricare nella piattaforma di Change Management; da qui vengono prelevati dal team di supporto e caricati nella piattaforma.
Lavorazione del software. Una volta caricati nella piattaforma di Change Management, gli oggetti software sono lavorati direttamente dagli sviluppatori nelle aree messe loro a disposizione per lo sviluppo e il test; gli sviluppatori provvedono anche alla compilazione dei pacchetti, direttamente nella piattaforma di Change Management.
Oltre i test funzionali è possibile effettuare in questa fase anche test di tipo prestazionale, di integrazione, di qualità, di sicurezza; questi test possono essere progettati dagli sviluppatori con il supporto di un team di assistenza centralizzata (team di supporto al test e collaudo), che provvede poi all’esecuzione degli script, a predisporre i report sull’esito dei test, a trasmetterli agli sviluppatori e a dar loro supporto nella problem determination.
Messa in esercizio. La piattaforma di Change Management non provvede direttamente alla messa in esercizio del software. Completati i test con esito positivo, gli sviluppatori trasferiscono i pacchetti software in un’area di staging pre-esercizio, dalla quale sono prelevati dai sistemisti e messi in produzione (utilizzando strumenti ad hoc), previa autorizzazione dei Dirigenti DCSIT di riferimento.
1.4 Misure di Sicurezza e Strumenti di Interfaccia
I sistemi applicativi del fornitore devono garantire il rispetto dei requisiti minimi di sicurezza di cui all’allegato B del Dlgs 196/2003, e successive modificazioni, e la tracciabilità delle operazioni di trattamento dei dati. Tali sistemi applicativi dovranno, inoltre, integrarsi con i sistemi di Identity & Access Management adottati dall’Istituto e con i sistemi di tracciamento degli eventi di sicurezza.
1.4.1 Accesso alla rete (Virtual Private Network)
I servizi SOA sono raggiungibili solo attraverso la rete privata dell’Istituto. Per consentire il colloquio dei servizi del fornitore con i servizi SOA dell’Istituto è necessario instaurare un canale di comunicazione VPN di tipo Site-to-Site secondo gli standard IPSEC. Il fornitore dovrà dunque dotarsi di un apparato idoneo all’instaurazione del canale VPN IPSEC, attraverso la rete internet, con il terminatore dell’Istituto.
In alternativa, l’Istituto si rende disponibile a consentire l’interconnessione diretta con linea dedicata qualora il fornitore lo ritenesse necessario per garantire idonei livelli di servizio. In tal caso i costi della linea dedicata devono ritenersi interamente a carico del fornitore.
1.4.2 Accesso ai Web Service della SOA
Nell’ambito dell’architettura SOA adottata dall’Istituto, l’accesso ai Web Service avviene attraverso un Firewall XML che svolge le funzioni di validazione, routing e instradamento delle richieste, nonché per tutte le operazioni di sicurezza necessarie: autenticazione del chiamante, autorizzazione della richiesta, logging.
Per le fasi di autenticazione l’applicazione consumer dovrà impostare un Custom SOAP Header con le informazioni necessarie per la sua identificazione e per le operazioni di tracciatura degli accessi.
Le informazioni rappresentanti l’identità del chiamante viaggiano quindi all’interno dei messaggi SOAP, nella specifica sezione relativa agli headers.
2. Sistemi di gestione documentale e protocollo informatico in uso presso l’Istituto
Nell’ambito del sistema integrato di gestione documentale dell’Istituto i sotto-sistemi attualmente disponibili si possono raggruppare in:
sistemi per l’acquisizione, il riconoscimento e l’archiviazione di documenti con contestuale costruzione del fascicolo elettronico dei soggetti fisici e giuridici;
sistemi per la protocollazione in entrata ed in uscita dei documenti;
sistemi per la gestione dei procedimenti sia interni che esterni;
sistemi per la consultazione delle documentazioni tramite l’utilizzazione di applicazioni web-oriented.
2.1 Gestione dei Flussi Documentali (GFD)
La piattaforma GFD rende disponibili tutte le funzionalità necessarie per la gestione del ciclo di vita dei documenti protocollati e non. L’integrazione con il Protocollo Informatico Unificato (PIU) garantisce la totale sincronia fra i dati di protocollazione e gli ulteriori metadati introdotti dalla gestione documentale: tipo documento e tipo fascicolo, trasmissioni effettuate e ricevute, versioni, catene documentali, fascicolazione ecc.
Sono abilitati all’accesso tutti gli utenti delle Direzioni Centrali, Coordinamenti generali delle attività professionali, Uffici di supporto agli organi, Direzioni Regionali.
Accesso da Intranet, autenticazione tramite Single Sign On (IAM), tecnologia .Net e Microsoft SQL Server 2012.
2.2 Gestione Documenti Protocollati (GDP-2)
Sistema preposto alla gestione del ciclo di vita dei documenti in entrata protocollati sul PIU (Protocollo Informatico Unificato) e dei relativi allegati.
Attraverso questo strumento è possibile seguire tutte le fasi di lavorazione di una pratica protocollata. Il sistema è in grado di fornire una serie di servizi a valore aggiunto per supportare l’Istituto nel raggiungimento di risultati significativi sulle aree tematiche di seguito illustrate:
Efficienza interna: supporto alle attività di programmazione e gestione delle attività di produzione in termini di organizzazione delle attività lavorative, gestione dei picchi, delle emergenze e sussidiarietà di lavoro, gestione delle priorità dei singoli procedimenti, gestione dell’impegno delle risorse in funzione di presenze, assenze, turnazioni, piani ferie e percorsi formativi.
Trasparenza: sviluppo di nuovi servizi on line per fornire al cittadino informazioni sullo stato della pratica di sua pertinenza (utilizzato ad es. dal Contact Center).
Misura delle performance: potenziamento degli strumenti a supporto della valutazione della misura dell’azione amministrativa.
Accesso da Intranet, tecnologia .Net e Microsoft SQL Server 2012.
Gli utenti abilitati all’uso di tale sistema sono i componenti delle Sedi periferiche e regionali.
2.3 Protocollo Informatico Unificato (PIU - WSPIA)
Nell’ambito della Gestione Documentale dell’Istituto è in essere il sistema di Protocollo Informatico Unificato (PIU) e del servizio di protocollo ad esso correlato (WSPIA).
Il servizio è richiamabile in modalità web Service e provvede alla protocollazione dei documenti pervenuti tramite gli utenti (sportello, back office, CRM) o attraverso i flussi applicativi (procedure di gestione quali CISCO, PEC, CCBFF, PDA, WEBDOM ecc.). Attualmente attraverso il modulo di front-end viene dato supporto alla protocollazione ad oltre 30 mila utenti offrendo tutti i servizi di protocollazione, repository per documenti digitalizzati, trasferimenti ad altra sede e notifiche al cittadino.
La modalità di autenticazione è integrata a livello di dominio e l’informazione utilizzata per l’identificazione dell’utente è l’utenza NT. L’applicazione prevede la profilazione basata sull’import massivo da Metaprocesso sia delle utenze che dei ruoli (Amministratore, Responsabile di Protocollo informatico, Utente e Utente Sussidiario) a cui vengono attribuite le varie autorizzazioni, dando accesso attualmente agli utenti distribuiti su tutto il territorio, offrendo oltre al servizio di protocollazione anche i servizi di repository per i documenti digitalizzati, trasferimento ad altra sede e notifiche al cittadino (SMS/EMAIL).
WSPIA (Web Service di Protocollo Informatico per le Applicazioni) è il Web Service (componente software modulare e interoperabile che mette in comunicazione tra loro applicazioni, sistemi ed aziende, tutti elementi distribuiti ed eterogenei) invocato sulla rete intranet che fornisce l’interfaccia software con il sistema di protocollazione PIU.
Il servizio viene reso da un’architettura SOA (Service Oriented Architecture), che è una funzionalità di business che combina informazioni e comportamento, nasconde i dettagli implementativi interni presentando una semplice interfaccia verso gli altri componenti.
Il web service può essere invocato utilizzando una URL esposta sulla intranet dell’Istituto. Ogni metodo del Web Service che interessa il trasferimento o il retrive di immagini o allegati deve essere effettuato tramite un client che supporti il protocollo DIME, non è sufficiente un semplice accesso http.
I metodi pubblici messi a disposizione del web service sono ad esempio:
funzioni di interoperabilità dei sistemi di protocollo informatico (possibilità di trattamento automatico, da parte del sistema ricevente, delle informazioni trasmesse dal sistema mittente, per automatizzare le attività ed i processi amministrativi conseguenti – cfr. articolo 55, comma 4, del DPR 28 dicembre 2000, n. 445 ed articolo 15 del DPCM 31 ottobre 2000, pubblicato su G.U. del 21/11/2000, n. 272);
2.4 Nuovo Sistema unico di Gestione Documentale (SGD)
Il nuovo sistema documentale SGD si pone l’obiettivo strategico di progettare e realizzare una nuova e moderna piattaforma documentale che possa progressivamente sostituire, in un’ottica di unificazione e centralizzazione, i sistemi documentali attualmente in uso presso l’Ente, con evidenti benefici in termini di efficienza (riduzione dei costi di gestione) e di efficacia (utilizzo di un sistema software condiviso, utilizzando regole e strumenti archivistici condivisi).
La nuova piattaforma documentale, che possiede tutte le funzioni dei sistemi sopra illustrati (GFD, GDP2, PIU, FaPers), permettendone la loro sostituzione, è articolata in quattro “macro-componenti”: sistema di gestione documentale corrente SGD (che permette la creazione, ricerca, condivisione, gestione, aggregazione, etc dei documenti e fascicoli appartenenti a processi, procedimenti o pratiche in corso o di recente conclusione), un archivio di deposito SGD (che permette la ricerca e consultazione di documenti e fascicoli appartenenti a processi, procedimenti o pratiche concluse), un sistema di conservazione a norma (integrato nativamente con i due precedenti macro-componenti, ma integrabile anche da parte di altri sistemi esterni), un sistema di data warehouse per l’estrazione aggregata di metadati relativi alla gestione documentale, con report personalizzati in funzione delle esigenze.
Scendendo più nel dettaglio, il sistema corrente di gestione documentale SGD è composto dei seguenti componenti (frontend, backend, base dati), che operano in sinergia:
DM – DOCUMENT MANAGEMENT. Cuore del sistema documentale alla gestione documentale (documenti, fascicoli, trasmissioni, etc). Frontend per l’utente.
TR – TRANSCRIPT RECORDING. Cuore del sistema di protocollo informatico. E’ un sistema ad alta affidabilità dedicato esclusivamente all’erogazione dei protocolli e al loro reperimento. Il sistema, dispone di uno strato di webservice WSPIA, concettualmente analogo a quanto descritto nel paragrafo 1.3, che ne permette l’utilizzo da parte di applicazioni esterne.
DS – DOCUMENT STORE. Sistema dedicato esclusivamente alla registrazione e alla lettura dei file fisici associati ai documenti, vale a dire il documento principale e gli allegati, con le eventuali versioni. Il sistema DS è acceduto principalmente dai componenti DM e TR, tramite uno strato di servizi web fruibili anche dalle applicazioni verticali.
REG – REGISTRY Sistema dedicato alla gestione dei metadati comuni a tutto il sistema, in particolare l’organigramma documentale, a sua volta sincronizzato con l’organigramma Agenda Sedi dell’Ete, il titolario di classificazione e l’anagrafica dei corrispondenti.
Il rilascio in produzione del sistema SGD, e la contestuale dismissione dei precedenti sistemi documentali (GFD, GDP2, PIU), è iniziato nel 2015 ed ha interessato nel corso dell’anno tutte le strutture della Direzione Generale, mentre il progressivo avvio del sistema per le restanti Aree Organizzative Inps è previsto nel corso del 2016. Durante la fase transitoria che precede la completa sostituzione degli attuali sistemi documentali su tutte le Aree Organizzative dell’Ente, saranno operativi sia gli attuali sistemi documentali (GFD, GDP2, PIU) sia il nuovo sistema documentale (SGD), tra i quali sarà attivo un apposito componente tecnico di integrazione per il trasferimento in interoperabilità dei documenti.
Accesso da Intranet, autenticazione tramite dominio, tecnologia .Net MVC e Microsoft SQL Server 2012.
3. Sistemi di predisposizione, preparazione e gestione della corrispondenza in uscita
L’interazione tra i sistemi attualmente in uso presso l’Istituto e l’appaltatore del lotto 1 avviene mediante protocollo CFT (AXWAY) per:
l’invio dei lotti in stampa;
la ricezione delle ricevute di avanzamento stati di lavorazione e di recapito;
la restituzione dell’archiviazione ottica dell’immagine delle singole comunicazioni in formato PDF, dell’archiviazione ottica delle ricevute di ritorno delle Raccomandate A/R per le spedizioni di tipo raccomandata e dell’archiviazione ottica della busta per le spedizione di tipo NON raccomandata;
la richiesta di cancellazione per i documenti che sono stati completamenti memorizzati all’interno degli archivi dell’Istituto relativamente a:
PDF che rappresentano il documento;
archiviazioni ottiche delle ricevute di ritorno delle raccomandate A/R;
archiviazioni ottiche delle buste della posta non raccomandata.
La gestione della schedulazione, il relativo monitoraggio e la manutenzione dei trasferimenti previsti dal protocollo CFT è a carico dell’appaltatore del lotto 1.
Sono di seguito descritte le tipologie, i processi di gestione e monitoraggio e le principali caratteristiche tecniche dei sistemi INPS deputati alla predisposizione e preparazione della corrispondenza in uscita.
3.1 Sistemi di generazione della Corrispondenza Massiva in uscita
Per la corrispondenza massiva in uscita sono attualmente utilizzati in Istituto tre sistemi, di seguito descritti in dettaglio per quanto riguarda le caratteristiche e gli elementi in comune.
3.1.1 STDP (Sistema Trasmissione Dati Postali)
Il Sistema consiste di una catena di funzioni (eseguite parte su mainframe e parte su sistemi MS Windows) che, a valle della definizione e approvazione di un dato formato di stampa:
acquisiscono, validano e completano le informazioni dinamiche delle comunicazioni fornite dalle sedi o dalle Direzioni Centrali;
generano lotti di comunicazioni in formato xml per elaborazioni successive;
elaborano, adattano, trasformano in metalinguaggio @ (“chiocciola”) i lotti oppure elaborano e adattano i lotti di comunicazioni di tipo PDF;
generano informazioni statistiche;
gestiscono gli stati di elaborazione dei lotti ritornati dall'appaltatore del lotto 1;
gestiscono l’associazione tra le raccomandate ed i relativi codici fornita dall’appaltatore del lotto 1;
gestiscono tutte le informazioni relativi al recapito o al mancato recapito della raccomandata/lettera;
gestiscono le richieste e le restituzioni, presso la sede competente, dell’originale della cartolina che rappresenta l’esito positivo o negativo della raccomandata;
gestiscono la catalogazione e l’archiviazione negli archivi dell’Istituto dei PDF relativi alle comunicazioni spedite e delle scansioni ottiche delle cartoline o delle buste;
gestiscono le richieste di cancellazione inoltrate all’appaltatore del lotto 1 dei PDF e delle scansioni di cui al punto precedente;
gestiscono la visualizzazione, su richiesta, delle copie conformi dei documenti sottoposti ad conservazione ottica sostituiva.
In quest’ambito si opera in base a due distinti macroprocessi di seguito descritti.
Acquisizione comunicazioni tramite metadati:
I dati utili per la creazione delle comunicazioni sono resi disponibili attraverso apposite interfacce in tabelle DB2;
Le funzioni di acquisizione provvedono ad una validazione dei valori forniti ed eventualmente, se necessario, completano aggiungendo altre informazioni disponibili nella base dati;
Gli indirizzi dei destinatari delle comunicazioni sono sottoposti ad una prima fase di normalizzazione;
Sono creati file XML contenenti lotti di comunicazione su host per le elaborazioni successive;
I files sono acquisiti in ambiente MS Windows e, qualora necessario, trasformati da EBCDIC a ASCII;
I lotti sono elaborati e creano strutture dati di riferimento su database MS SQL SERVER;
I lotti sono adattati (trasformazione di caratteri, indirizzi) e trasformati via XSL/XSLT in metalinguaggio @ (“chiocciola”) o @++ (“chiocciola plus plus”), secondo specifiche di rappresentazione grafica della stampa;
I lotti sono completati con files che riportano le specifiche di rappresentazione grafica della stampa;
I lotti sono inviati con protocollo CFT (AXWAY) all’appaltatore del lotto 1;
L’appaltatore del lotto 1 restituisce, con protocollo CFT, lo stato di avanzamento dei lotti e le informazioni relative al recapito o al mancato recapito delle comunicazioni; tali stati sono elaborati e le informazioni ricavate popolano strutture dati di riferimento per il monitoraggio.
Acquisizione comunicazioni tramite metadati e file PDF:
I dati utili per la creazione delle comunicazioni sono resi disponibili attraverso invocazioni di Servizi Web;
Vengono messi a disposizione i PDF da spedire ai destinatari in un’area condivisa su File System;
Le funzioni di acquisizione provvedono ad una validazione dei valori forniti ed eventualmente, se necessario, completano aggiungendo altre informazioni disponibili nella base dati;
Sono quindi creati file XML contenenti lotti omogenei di comunicazioni per le elaborazioni successive;
I lotti sono elaborati e creano strutture dati di riferimento su database MS SQL SERVER;
I lotti sono completati con files che riportano le specifiche di rappresentazione grafica della stampa;
I lotti sono inviati con protocollo CFT (AXWAY) all’appaltatore lotto 1;
L’appaltatore lotto 1 restituisce, con protocollo CFT, lo stato di avanzamento dei lotti e le informazioni relative al recapito o al mancato recapito delle comunicazioni; tali stati sono elaborati e le informazioni ricavate popolano strutture dati di riferimento per il monitoraggio.
Le informazioni, i dati relativi alle comunicazioni, le immagini della comunicazione, dell’eventuale cartolina di ritorno, gli esiti e gli inesiti di recapito sono memorizzati sugli archivi dell’Istituto.
3.1.2 CEU (Comunicazioni Epistolari con l’Utenza)
Nuova piattaforma per la predisposizione e l’invio di comunicazioni cartacee massive, non massive, ed in formato elettronico all’appaltatore del lotto 1, prevista per la progressiva e graduale sostituzione di STDP. Le finalità dei due sistemi sono pertanto le medesime, che in CEU beneficiano di alcune evoluzioni funzionali e tecnologiche di seguito riassunte:
I macroprocessi “Acquisizione comunicazioni tramite metadati” e “Acquisizione comunicazioni tramite metadati e file PDF” sono uniformati per quanto riguarda la centralizzazione della logica dei controlli;
Unica base dati in ambiente mainframe (DB2), che non necessita del trasferimento di flussi XML fra host e piattaforme MS Windows;
Le funzioni possono essere eseguite in parallelo;
Nuove funzioni di controllo e monitoraggio:
gestione delle priorità nella lavorazione dei lotti;
controllo delle lavorazioni con blocco/sospensione di lavorazioni, storno delle lettere con errori e ripresa delle lavorazioni;
generazione di informazioni di monitoraggio.
Nuovo workflow di creazione e gestione di una comunicazione in uscita, che comprende:
gestione immagini, per i contenuti statici delle lettere;
censimento lavorazioni/attività/formati.
3.1.3 CDPU (Composizione Documentale della Posta in Uscita - Mailroom out)
Per gli invii di comunicazioni è anche disponibile per le sedi INPS e per le Direzioni un’interfaccia web che consente di:
scegliere il tipo di documento da postalizzare a partire da modelli già predisposti e presenti sul repository centralizzato;
personalizzare il documento inviando testi da inserire nell'impaginazione prescelta (parti variabili);
caricare gli indirizzi di spedizione;
visualizzare a schermo un'anteprima dei documenti prima di autorizzarne l’invio in stampa;
scegliere la modalità di spedizione (posta massiva, prioritaria o posta raccomandata);
controllare l'avanzamento della lavorazione;
creare nuovi modelli e metterli a disposizione degli interessati;
gestire l'archivio dei documenti e dei modelli.
L’applicativo in oggetto consente di semplificare e velocizzare le attività di gestione della corrispondenza “spot”, in quanto il processo viene controllato e gestito direttamente sui sistemi dell’istituto rendendone possibile la tracciatura e la rendicontazione.
La soluzione integrata è composta dai seguenti moduli:
applicativo web per la composizione online della posta in uscita;
applicativo batch per scarico dei dati ai fini dell’alimentazione delle piattaforme STDP e CEU che, a seguire, inoltrano i lotti ai sistemi produttivi dell’appaltatore del lotto 1 secondo le modalità descritte in precedenza.
I lotti da inviare all’appaltatore del lotto 1 sono di tipo PDF e i pacchetti sono formati da un file pdf relativo al modello da applicare all’intera lavorazione, più un file dati contenenti le informazioni necessarie alla personalizzazione delle singole lettere ed ai dati utili alla postalizzazione.
3.1.4 Generazione da Contact Center
A seguito di richieste pervenute al contact center da parte dell’utenza sono possibili invii di nuove comunicazioni o nuovi invii di comunicazioni già protocollate e residenti sui sistemi di gestione documentale dell’Istituto.
I dati vengono inviati all’appaltatore del lotto 1 in modalità PDF over XML (attraverso un incapsulamento in XML). Il blocco XML conterrà i dati di corredo (Cognome e nome, indirizzo, cap, ecc.) e, eventualmente, il ByteCode del Pdf. Il ByteCode è la sequenza dei byte che compongono il file Pdf codificati in Base64.
Il blocco XML risultante viene inviato via Http/Https verso un’apposita URL dell’appaltatore del lotto 1 che risponde con un blocco XML con i risultati delle operazioni di parse ed import.
Il lotti generati contengono file pdf di tipologia “multibusta”, che contiene cioè al proprio interno le pagine che comporranno le varie buste (lettere).
Sono attualmente in corso implementazioni mirate a far transitare le spedizioni generate dal Contact Center attraverso le piattaforme STDP e CEU.
3.1.5 CEU e STDP: Elementi comuni
Ognuno dei due sistemi di predisposizione comunicazioni crea 1 file compresso contenente un numero di file variabili secondo il macroprocesso:
Macroprocesso “Acquisizione comunicazioni tramite metadati”:
lotto di posta in formato .zip, contenente le lettere che saranno stampate ed inviate all’appaltatore del lotto 1;
un file che contiene tutti i dati necessari a stampare correttamente le comunicazioni.
Macroprocesso “Acquisizione comunicazioni tramite metadati e file PDF”:
lotto di posta in formato .zip, contenente le lettere che saranno stampate ed inviate all’appaltatore del lotto 1;
un file XML contenente le informazioni relative alle singole missive presenti in un lotto;
due file che contengono tutti i dati necessari a stampare correttamente le comunicazioni.
Il file inviato all’appaltatore lotto 1, contenente i lotti da postalizzare, può essere di varie tipologie in base al formato:
lotti in formato @ e @++: file ASCII strutturati secondo le codifiche del formato @ o @++ , contenenti i dati utili alla composizione e postalizzazione;
lotti in formato raw-data: file ASCII studiati volta per volta in base alle esigenze del layout finale, contenenti i dati utili alla composizione e postalizzazione;
lotti in formato pdf: file PDF e file dati contenenti i dati della spedizione .
I lotti da stampare possono contenere anche bollettini di C/C, MAV elettronici o RAV; le personalizzazioni da effettuare in fase di stampa comprendono anche l’inserimento delle codifiche di codici a barre in OCR e di glifi bidimensionali, utili all’identificazione univoca delle lettere, alla loro securizzazione elettronica o all’inserimento di informazioni aggiuntive.
3.2 Sistemi relativi alla ricezione dei “ritorni”
A fronte dell’invio della corrispondenza massiva in uscita sono previsti flussi di ritorno i cui dettagli vengono illustrati di seguito.
3.2.1 Richiesta originale della cartolina A/R e copia conforme
Le ricevute di consegna delle comunicazioni inviate come raccomandate A/R, dovranno essere conservate dall’appaltatore del lotto 1 per essere disponibili qualora pervenisse una richiesta dell’originale da una Sede INPS.
Le copie conformi delle comunicazioni sottoposte a conservazione ottica sostitutiva devono essere fornite dall’appaltatore del lotto 1 ad ogni richiesta effettuata da una Sede INPS: tale disponibilità deve essere garantita attraverso la realizzazione di opportune interfacce web, ad esempio Web Services, opportunamente esposte e raggiungibili dalla rete INPS. L’interazione con tali interfacce deve essere conforme ai criteri di sicurezza e tracciatura.
Il sistema integrato prevede che tali richieste vengano elaborate per essere inviate all’appaltatore del lotto1 tramite file XML, secondo uno schema definito, attraverso il protocollo CFT.
Tale file, con nome univoco, conterrà l’indicazione della raccomandata, della sede e del dipendente a cui consegnare l’originale della cartolina A/R.
Al termine del processo di elaborazione delle richieste sarà inviata una mail riepilogativa, alla casella di posta indicata dall’appaltatore del lotto 1, contenente il nome dei file inviati ed il numero di richieste contenute in ognuno.
Sempre attraverso il protocollo CFT l’appaltatore del lotto 1 consegnerà tramite file XML, quando disponibili, gli stati di elaborazione delle richieste:
PRESA IN CARICO
RICHIESTA IN LAVORAZIONE
ORIGINALE NON RIENTRATA
ORIGINALE GIA RESTITUITA
ORIGINALE SPEDITA
ORIGINALE RECAPITATA
Gli stati 3, 4 e 6 chiudono il processo.
3.2.2 Restituzione delle archiviazioni ottiche e richiesta di cancellazione
Per ogni lotto inviato, affinchè sui sistemi dell’appaltatore del lotto 1 siano effettuate anche le lavorazioni che prevedono la restituzione delle immagini online (immagine della lettera oppure scansione ottica della cartolina di ritorno o della busta), occorre che venga impostato opportunamente il file relativo alle impostazioni di stampa, attraverso l’impostazione del tag “PRODOTTO_ARCH” al valore “WEB,FTP”.
L’appaltatore restituirà, veicolandoli attraverso i canali descritti, il pacchetto di archiviazione contenente i PDF relativi alle comunicazioni ed il pacchetto contenente le scansioni ottiche, oltre a un file XML (per ciascuno) contenente le chiavi di archiviazione: una struttura associativa tra l’identificativo della comunicazione ed il codice della raccomandata, utile ad identificare correttamente il PDF (o la scansione) restituito.
Ogni archivio compresso sarà strutturato come segue:
1 file informativo;
N file pdf (immagine lettera multipage) oppure N file tiff (scansione ottica della cartolina di ritorno oppure della busta);
1 file degli indici – solo per procedura RACC2.
e sarà accompagnato dal corrispondente file “.t”
Il pacchetto di archiviazione sarà compresso, avrà estensione “.zip” ed avrà, per la restituzione dei PDF, la seguente nomenclatura:
NomeLotto_[IDsottolotto].ZIP contenente:
[IDsottolotto].inf;
Codice destinazione1/codice raccomandata1.pdf;
Codice destinazione2/codice raccomandata2.pdf;
Codice destinazioneN/codice raccomandataN.pdf;
IDsottolotto _I.pdf.xml – il file delle chiavi è presente SOLO nel caso di classe documentale RACC2.
Il pacchetto di archiviazione delle scansioni ottiche delle cartoline di ritorno (oppure delle buste) è attualmente ancora in fase di definizione.
La nomenclatura delle immagini pdf e delle scansioni ottiche sarà:
Classe documentale “PEC”, “DOCPERACH”, “ORDINARIO”: codice destinazione.pdf oppure codice destinazione.tiff;
Classe documentale “RACC2”: codice raccomandata.pdf oppure codice raccomandata.tiff;
Il pdf raccomandata (o la tiff) verrà rinominato con il codice raccomandata a 12 cifre.
La struttura del file inf, per la restituzione dei PDF, è la seguente:
[info_job]
Id_utente= Z0000887
Job_name= id sottolotto Postel.afp
Id_lotto= nome lotto Postel
Id_sottolotto= id sottolotto Postel
Numero_sottolotti=N
Data_elaborazione=gg/mm/aaaa xx.xx.xx
Numero_documenti=N
Numero_pagine=N
File_Indici=nome file indici
NomeLotto=nome lotto INPS
[info_archive]
servizio= WEB,FTP
Nome_procedura=Ordinario; PEC, RACC2, DOCPERARCH
Platform=1
Ad esempio:
[Info_job]
Id_utente=Z0000887
Job_name=GIC140015B7E0010001.afp
Id_lotto=GIC140015B7E001
Id_sottolotto=GIC140015B7E0010001
Numero_sottolotti=1
Data_elaborazione=17/11/2014 16.55.13
Numero_documenti=500
Numero_pagine=2084
File_Indici=GIC140015B7E0010001_I
NomeLotto=M3E56002
[Info_archive]
Servizio=WEB, FTP
Nome_procedura=RACC2
Platform=1
A seguito dell’avvenuta archiviazione dei PDF e delle scansioni ottiche delle ricevute di ritorno delle raccomandate AR, oppure delle buste, verrà prodotto un file che rappresenta una richiesta di cancellazione che riporta i dettagli delle comunicazioni correttamente archiviate. A fronte di tale richiesta sarà possibile procedere alla cancellazione di quanto riportato, che risulta correttamente archiviato nei sistemi dell’Istituto.
Si tratta di un file xml compresso “.zip” che conterrà l’elenco dei pdf archiviati (o delle “tiff” – scansioni ottiche delle ricevute di ritorno delle raccomandate AR oppure delle buste), verrà prodotto un file xml per ogni classe documentale ed avrà il pattern di naming “<classe_documentale>_<timestamp>.zip”.
Il contenuto sarà, ad esempio:
<ElencoFileElaborati classedocumentale="ORDINARIO">
<NomeFile>15PRF2D0000001.pdf</NomeFile>
<NomeFile>15PRF2D0000004.pdf</NomeFile>
<NomeFile>15PRF2D0000008.pdf</NomeFile>
</ElencoFileElaborati>
oppure
<ElencoFileElaborati classedocumentale="ORDINARIO">
<NomeFile>15PRF2D0000001.tiff</NomeFile>
<NomeFile>15PRF2D0000004.tiff</NomeFile>
<NomeFile>15PRF2D0000008.tiff</NomeFile>
</ElencoFileElaborati>
Dovrà essere inoltre prodotto un file “.t” a chiusura dell’invio che non sarà oggetto di invio cft.
3.3 Procedure di invio comunicazioni in uscita con metodi non tradizionali
Le procedure di invio con metodi non tradizionali comprendono le comunicazioni via PEC in generale, la posta elettronica ordinaria, gli SMS ed altri canali alternativi che l’Istituto può attivare in funzione delle esigenze di servizio e di comunicazione con l’utenza.
Nell’ambito dei processi di dematerializzazione e contenimento della spesa, è prevista la possibilità di ricorrere ai canali di invio telematici (PEC, SMS, e-mail) al fine di recapitare le comunicazioni nella modalità che consenta il minore aggravio di costi.
E’ stato pertanto definito un sistema di “tentativi” di invio della singola comunicazione su canali differenti a fronte di un esito negativo di recapito. Il sistema quindi identifica una lista di canali utili all’invio della comunicazione (strutturati tramite apposito censimento) e, in caso di esito negativo, effettua l’invio della comunicazione attraverso il canale presente immediatamente dopo nella lista (ordinata) dei canali.
L’utilizzo di tali canali è effettuato in maniera automatica ed autonoma all’interno dei sistemi STDP e CEU.
In particolare per la PEC consiste nel determinare se il soggetto destinatario della comunicazione sia o meno in possesso di un indirizzo di posta elettronica certificata: in tal caso la comunicazione viene inviata allegata alla PEC.
In caso di mancata consegna della PEC il sistema procederà, nei casi previsti, all’invio in cartaceo della comunicazione attraverso i canali descritti in precedenza.
Si tratta di un servizio, rivolto ai cittadini, (identificati per mezzo di Codice PIN e Codice Fiscale) e pubblicato sul sito istituzionale INPS xxx.xxxx.xx, attraverso il quale l’utente può consultare e visualizzare tutte le comunicazioni inviategli dall’Istituto, tramite i sistemi CEU e STDP, dal 2006 ad oggi. Tali comunicazioni sono messe a disposizione dal fornitore tramite le apposite procedure di integrazione con l’Istituto descritte nei paragrafi precedenti.
Attraverso la Cassetta Postale è possibile:
reperire informazioni fino al dettaglio della singola lettera;
accedere, per ogni lettera, al documento nel formato elettronico PDF, copia della lettera spedita;
visionare, in caso di raccomandata A/R, l’immagine della cartolina che rappresenta l’esito positivo o negativo della raccomandata con la data di ricezione e l’eventuale motivo di mancata consegna o, in caso di esito negativo di posta non raccomandata, può visualizzare la scansione della busta con il motivo della mancata consegna.
3.5 Cruscotto di monitoraggio delle comunicazioni spedite all’utenza
Si tratta di un servizio intranet, rivolto ai dipendenti dell’Istituto ed agli operatori del Contact Center, identificati con autenticazione tramite Single Sign On proprietario, attraverso il quale l’utente può consultare e visualizzare le comunicazioni inviate dall’Istituto, tramite i sistemi CEU e STDP, dal 2006 ad oggi.
Il servizio mette a disposizione un cruscotto web per la gestione, il monitoraggio ed il controllo continuo di quanto prodotto e postalizzato, le statistiche sugli eventi relativi alla postalizzazione e mail giornaliere di riepilogo degli eventi.
Gli utenti sono profilati (Dirigenti, Amministrativi, manager, Direzione Generale, Utente di sede, Contact Center) e hanno ciascuno un proprio livello di visibilità, in funzione del quale possono:
reperire informazioni sulle spedizioni fino al dettaglio della singola lettera;
accedere, per ogni lettera, al documento nel formato elettronico PDF, copia della lettera spedita;
visionare lo stato di postalizzazione delle missive spedite, di un eventuale indirizzo errato, di un inesito e del suo motivo e di tutte le altre informazioni necessarie;
visionare, in caso di raccomandata A/R, l’immagine della cartolina che rappresenta l’esito positivo della raccomandata con la data di ricezione o viceversa, in caso di esito negativo, visualizzare la scansione della busta con il motivo della mancata consegna;
esportare su MS Excel gli elenchi visualizzati;
richiedere l’originale della ricevuta di ritorno.
Il Sistema inoltre fornisce in modalità grafica e tabellare statistiche sugli eventi relativi alla postalizzazione, come ad esempio:
distribuzione geografica degli invii, suddivisi per tipologia di Documento, Lavorazione e Direzione committente;
statistica grafica degli invii, su base geografica mittente, suddivisa per scaglioni di importo;
distribuzione temporale degli invii;
statistica grafica delle missive Raccomandate per periodo, suddivise tra Ricevute, Non Ricevute, In attesa di esito ed errate;
Viene effettuata la tracciatura per tutti i documenti richiesti in visualizzazione dall’applicazione e per ogni documento viene registrato sul DB di sicurezza l’identificativo dello stesso e l’utente che ha effettuato la richiesta. Vengono infine tracciate all’interno di un log applicativo tutte le operazioni effettuate dal singolo utente con il dettaglio delle stesse.