ICAR
Skip Navigation LinksHOME PAGE » ICAR PLUS » RAPPORTO ICARPLUS » Accordi di Servizio
CISIS

Accordi di Servizio

L’esperienza maturata nel progetto ICAR dimostra che lo strumento dell’Accordo di Servizio è centrale nel percorso di concreta attuazione delle cooperazione applicativa. ICAR, esplorando SPCoop, tratteggia un futuro “rivoluzionario”. Infatti, oltre a dare finalmente concretezza all’integrazione evoluta e strutturata tra i back office, evidenzia l’ulteriore possibile integrazione, almeno per le identità digitali, la semantica e le ontologie, con i front office. ICAR offre la possibilità di segnare un passaggio decisivo verso l’amministrazione cooperativa.

Lo scenario sperimentato nel coinvolgimento delle Regioni e di alcune pubbliche amministrazioni centrali dimostra la possibilità di attuare il cambiamento attraverso la strada della cooperazione; l’accordo di servizio (AdS), quale strumento tecnico e giuridico abilitante la cooperazione applicativa, è funzionale al raggiungimento di questo obiettivo.

Nella sua forma tradizionale, l’accordo tra amministrazioni è uno strumento giuridico che si costruisce attraverso un processo che inizia con il disegno dell’architettura dei soggetti coinvolti nello scambio dei dati/informazioni e prosegue, talvolta, con la redazione di un decreto legge o altro apposito strumento attuativo e del relativo allegato tecnico; a cui può far seguito la fornitura in sussidiarietà da parte dell’ente erogatore della necessaria infrastruttura di collaborazione/cooperazione (cfr. caso INA/SAIA).

Con l’introduzione del SPCoop, “l’accordo di servizio” diventa uno strumento tecnico oltre che giuridico essenziale per la cooperazione applicativa e l’interoperabilità tra enti che introduce sostanziali novità rispetto all’accordo vecchia maniera. Esso diventa un’opportunità che le amministrazioni non possono tralasciare se desiderano realmente innovare i servizi e ripensare i processi nella logica erogatore/fruitore.

Nell’accordo di servizio risiedono, infatti, concetti e strumenti innovativi che sino ad oggi non hanno trovato applicazione nelle diverse forme di collaborazione tra pubbliche amministrazioni (semantica, service level agreement, sicurezza ed identità). L’AdS rappresenta il cardine del ciclo di vita del servizio tra un ente fruitore ed un ente erogatore, poiché definisce:
o l’oggetto del servizio e i relativi contenuti di scambio tra erogatore e fruitore;
o le funzionalità, i requisiti di qualità e sicurezza del servizio per entrambe le parti in causa;
o gli oneri tecnici e tecnologici, giuridici, amministrativi del fruitore e dell’erogatore;
o la semantica dell’informazione veicolata dal servizio, in quel dominio di applicazione, ovvero, definisce il lessico dell’oggetto di scambio (ad esempio i dati delle cartelle cliniche), proprio di quel dominio (ad esempio la sanità).

 Ciò significa che il servizio oggetto di un accordo diventa definitivamente “unico”, “omogeneo”, “accessibile”, “sicuro” nello scambio dei dati e delle informazioni, cioè di “qualità”.

Le regole tecniche del SPCoop  articolano la composizione di un AdS in due parti, quella comune e quella specifica (Tabella 1).

La prima può contenere oltre alle specifiche di interfaccia (WSDL) e di conversazione (WSBL) anche altri documenti come allegati (documenti non formali di interesse per l’accordo di servizio in un qualsiasi formato) e specifiche semiformali (XML, UML, HTML o anche in linguaggio naturale).
La seconda, invece, può contenere oltre alle specifiche dei porti di accesso (WSDL) anche altri documenti come allegati (documenti non formali di interesse per l’accordo di servizio in un qualsiasi formato), specifiche semiformali (XML, UML, HTML o anche in linguaggio naturale), specifiche dei livelli di qualità del servizio SLA (WS-Agreement e WSLA) e specifiche di sicurezza associata al servizio e redatte mediante WS-Policy o in linguaggio naturale.
Tale struttura, quindi, pone come obbligatorie le sole componenti che riportano le specifiche di interfacciamento del livello concettuale e dei livelli logici erogatore e fruitore (WSDL); mentre lascia opzionali le restanti parti, cioè quelle attinenti alla sicurezza, alla semantica, ai livelli di qualità del servizio. Queste ultime, sebbene non obbligatorie, sono essenziali per aumentare l’efficacia complessiva dell’AdS, finalizzata al miglioramento dei processi amministrativi della PA. 

Infatti, due o più soggetti che intendono cooperare su un servizio (ad esempio in seno alla comunicazione e trasferimento dei dati relativi ad un lavoratore, tra Centri per l’impiego di due Regioni) definiranno nell’AdS le annotazioni semantiche con un’ontologia che permette di catalogare e strutturare l’insieme dei riferimenti semantici propri del servizio e del dominio di cooperazione (ad esempio il Lavoro).
In altre parole, il soggetto erogatore e il soggetto fruitore, forniranno un significato preciso al flusso informativo scambiato tra i propri sistemi, consentendo di risolvere eventuali ambiguità interpretative e individuare corrispondenze e differenze fra i concetti di domini diversi. Ciò significa che verranno definiti tutti gli elementi dirimenti (sintassi, terminologie, ecc) che caratterizzano il dominio di cooperazione applicativa per la fruizione ed erogazione di un servizio di qualità e per lo scambio di dati omogenei: chi è e cosa si intende per datore di lavoro, chi è e cosa si intende per lavoratore, cosa è il rapporto di lavoro, il profilo del lavoratore, ecc.
 
 Nella fattispecie, supponiamo di voler descrivere l’ontologia di dominio associata alla Scheda Anagrafica Professionale e che il servizio sia fruibile dalla Regione e dal Centro per l’Impiego regionale. In tal caso, si procederà alla formalizzazione dei concetti del dominio rilevanti per la cooperazione applicativa, come, appunto quello di attore del dominio:
• soggetto abilitato, Regione, Centro per l’impiego regionale, Ministero del Lavoro;
e alla formalizzazione dei concetti e delle relazioni tra essi; associati ai dati scambiati tra erogatore e fruitore dei servizi, come, appunto, il concetto di scheda anagrafica professionale che può essere scomposto nelle componenti di profilo, di anagrafe amministrativa e insieme dei rapporti di lavoro.

L’annotazione semantica dell’accordo consente, quindi, maggiore accessibilità alla cooperazione in quel dominio specifico da parte dei soggetti diversi da quelli già appartenenti a un gruppo di dominio consolidato. Altresì, a livello di servizio con un’ontologia dedicata, la sicurezza e la qualità della cooperazione è assicurata dalla possibilità di monitorare l’efficacia dell’accordo e quindi verificare la qualità del servizio, attraverso la definizione dei parametri prestazionali del servizio stesso. La definizione di uno SLA consiste in un contratto tangibile tra le parti che, se da un lato assicura la fornitura dei servizi a livelli pre-negoziati, dall’altro comporta penalità in caso di mancato raggiungimento di tali livelli. Per cui l’erogatore e il fruitore avranno l’interesse a definire e poi monitorare, ad esempio: i tempi di disponibilità del dato, i tempi di risposta, la disponibilità della rete 100%; la velocità di collegamento (round trip) garantita; che in caso di problemi di qualsiasi natura al collegamento giunga un’informazione proattiva entro “x” minuti dal rilevamento.

Un accordo siffatto diventa propedeutico alla semplificazione del servizio. Esso agendo a livello di back office produce le condizioni necessarie perché si possa procedere ad una riduzione della complessità del processo amministrativo e alla soddisfazione armonica della pluralità di interessi degli attori istituzionali coinvolti.

Tuttavia, tale accordo non va confuso con il tradizionale “accordo tra pubbliche amministrazioni”, introdotto dalle Leggi 142 e 241 del 1990 (ripreso nel D.lgs. 267/00), di cui rispecchia l’istituto di base, ma dal quale si differenzia per la presenza degli elementi su citati che li consentono di essere “stabile”, “attendibile”, “unico e replicabile”, “pubblico e accessibile”, “sicuro”, e soprattutto “operativo” perché parte integrante di una infrastruttura tecnologica ed organizzativa comune a tutte le amministrazioni, coinvolte e coinvolgibili.

Una architettura unica e condivisa che non deve essere di volta in volta riprogettata, rivista e riadattata, infatti, avvantaggia le amministrazioni della possibilità di concentrarsi a livello dei servizi, dei flussi di dati e dell’organizzazione. Questo ultimo aspetto è dirimente rispetto agli accordi di servizio tradizionali che si alimentavano del solo oggetto per il quale erano stati creati, tanto da risultare molto spesso autoreferenziali, non vincolanti, non monitorabili, facilmente eludibili.

Ad oggi, a livello regionale, non esistono esempi di accordi di servizio completi di tutte le caratteristiche dettate dal SPCoop, comprese quelle opzionali. I dati raccolti (Tabella 2pongono in evidenza come le Regioni costruiscano gli AdS solo attraverso le componenti obbligatorie previste; anche se alcune di esse (tredici) iniziano ad accostarsi al concetto più ampio ed esteso di accordo di servizio. In particolare, sette Regioni integrano le componenti obbligatorie con le specifiche di conversazione del livello concettuale e dei livelli logici erogatore e fruitore (WSBL); sei Regioni, con la specifica della semantica delle informazioni veicolate dal servizio (ontologia e schema concettuale).

 ADS
Tali dati rispecchiano l’evoluzione della dotazione infrastrutturale e la maturità con cui la Regione si è avvicinata alla gestione della cooperazione applicativa.
In particolare, in fig. 1 è rappresentato il posizionamento delle Regioni rispetto alla tipologia di AdS stipulati, commisurato al numero di accordi formalizzati e/o in corso di formalizzazione (Tabella 3e al livello di completezza rispetto alle specifiche SPCoop (Tabella 1).

Questo mette in evidenza come la maggior parte delle Regioni che ha provveduto a stipulare AdS ne ha stipulati un numero non superiore a dieci, ad indicare un limite nella dimensione cooperativa sul territorio e nell’organizzazione sottostante. L’AdS, infatti, richiede a monte un modello organizzativo che consenta ai due o più soggetti di potersi accordare, di definire i servizi, di mappare insieme i processi, di costruire un’ontologia, di definire gli standard, ecc; oltre ad una competenza tecnologica nella scrittura dell’accordo stesso.
E’ quindi ipotizzabile, viceversa, che le Regioni che in questi anni hanno stipulato il maggior numero di accordi (tra 50 e 100) abbiano sviluppato un modello organizzativo tale da consentirgli una gestione ampia della cooperazione sul territorio; anche se si tratta, pur sempre, di accordi rispondenti alle specifiche SPCoop solo per la parte obbligatoria.
In sostanza, i dati emersi dalla rilevazione consentono un esercizio di analisi utile ad evidenziare che l’accordo di servizio si compone di due dimensioni caratteristiche: quella tecnologia e quella organizzativa, fortemente integrate e imprescindibili, che rappresentano il cuore pulsante della cooperazione applicativa. Le Regioni sono, quindi, chiamate a far evolvere la propria infrastruttura e la propria organizzazione verso la piena attuazione delle specifiche SPCoop e la definizione di un modello organizzativo cooperativo.

Al momento, in Italia, la prima sperimentazione di un AdS completo è avvenuta all’interno dei task Ap3 e Ap4 del progetto ICAR, con la definizione degli schemi concettuali, dell’ontologia specifica di applicazione, dei livelli minimi del servizio e della sicurezza.

Affinché due o più soggetti possano costruire un accordo sui servizi da scambiarsi, infatti, è necessario dapprima che “…condividano i concetti…, ovvero, è necessario che a partire da un dominio di applicazione definiscano i sottodomini di interesse e ne elaborino le ontologie che verranno poi raccordate da una ontologia generale. La vera difficoltà risiede, infatti, nel raccordare i diversi sottodomini con una ontologia che non cada nell’eccessivo dettaglio descrittivo dell’intero dominio di applicazione (ad esempio il lavoro), ma che sia in grado di descrivere il contesto specifico di applicazione” (Silvia Martini, project manager di INSIEL S.p.A e responsabile tecnico dei task Ap3 e Ap4 del progetto ICAR per la Regione capofila - Friuli Venezia Giulia) .

L’esperienza maturata dalla Regione Friuli Venezia Giulia, capofila dei task Ap3 e Ap4, e dalle Regioni aderenti ai task è servita a verificare che l’AdS non è un accordo tradizionale tra enti e tantomeno la trasposizione in formato XML di un documento cartaceo. Essi hanno avuto l’occasione di approfondire i servizi resi dalle amministrazioni erogatrici, in termini di accessibilità, attraverso la definizione delle qualifiche, degli attributi, dei ruoli; di qualità, attraverso la definizione dei parametri di monitoraggio dei livelli minimi del servizio; di ontologie, attraverso la definizione degli schemi concettuali che sono alla base dei processi di produzione del servizio e del migliore formalismo in grado di fornire una rappresentazione dei concetti.
Un processo, questo, di condivisione dei bisogni e dei processi amministrativi tra gli attori coinvolti a diverso titolo all’interno dei task di progetto, frutto non solo di un’azione endemica al progetto; ma, soprattutto, di un modello di coordinamento interregionale che ha garantito la definizione dell’accordo di servizio, a livello organizzativo e tecnologico, oltrepassando i confini regionali.
In sostanza, ICAR attraverso la propria strutturazione di progetto interregionale (con la sua governance tecnica ed organizzativa) ha fatto da sfondo alla definizione del dominio d’indagine e dei singoli servizi oggetto di accordo, facilitando, da un lato, l’incrocio tra domanda e offerta di servizio, da parte rispettivamente delle Regioni e dei Ministeri; e, dall’altro, mettendo a disposizione le competenze organizzative e tecnologiche necessarie per lo studio delle ontologie, la definizione degli SLA, la reingegnerizzazione dei processi amministrativi.
La costruzione di un accordo di servizio, quindi, non essendo semplice ed immediata per le oggettive difficoltà nella compilazione fattuale delle singole componenti tecnologiche (parte comune e parte specifica) e, soprattutto, per:
  • la mancanza delle ontologie dei servizi di dominio di applicazione;
  • la capacità degli attori di essere in grado di combinare le competenze di dominio o materia con quelle tecnico/informatiche ed organizzative;
  • la volontà e la disponibilità delle amministrazioni (non sempre immediata) di aprirsi al confronto per una condivisione dei processi, dei servizi, dei dati, con altri enti;
  • necessita di un modello di governance più strutturato ed efficace, rispetto a quello che le amministrazioni hanno potuto sperimentare nelle forme (cartacee) tradizionali di accordo tra pubbliche amministrazioni.


Per queste ragioni e a fronte dell’esperienza maturata in ICAR le Regioni hanno ritenuto necessario definire un Accordo quadro di cooperazione permanente, attraverso cui dare consistenza alle priorità tematiche diffuse a livello sovra regionale e trasformarle in azioni di progetto, in grado di favorire la cooperazione interregionale tra i sistemi informativi.
L’Accordo quadro diventa lo strumento amministrativo idoneo ad attivare e coordinare le iniziative di collaborazione tra Regioni e Province autonome per dar vita a specifici interventi settoriali e di dominio, di natura tecnologica ed organizzativa, che definiranno a livello interregionale i servizi, i processi, le interfacce, gli standard, le ontologie e i livelli di qualità dei servizi (SLA) che verranno, poi, dispiegati sui singoli territori all’interno delle community network regionali.
Un disegno questo che mitiga la complessità dell’accordo di servizio poiché ne favorisce a priori, attraverso la strutturazione e gestione di un progetto:

  • la soluzione della ritrosia delle parti a cooperare;
  • la definizione dei servizi e dei relativi processi;
  • la definizione delle ontologie e della qualità dei servizi da erogare;
  • l’individuazione di luoghi deputati al confronto e alla condivisione degli standard;
  • l’integrazione tra competenze informatiche e competenze specifiche di materia e/o dominio.

La community diventa, dunque, il fulcro attorno a cui si evolve il concetto di accordo, poiché favorisce l’erogazione dei servizi quanto più integrata, condivisa, cooperativa e interoperabile, e consente un coordinamento paritario dei rapporti fra le diverse pubbliche amministrazioni che vi aderiscono. In essa trovano spazio forme e luoghi di confronto che consentono di definire lo scambio di dati e informazioni“…sulla base di un ‘linguaggio comune’ sviluppato dalla stessa comunità di soggetti partecipanti…. L’interoperabilità si basa, infatti, sull’esistenza di un linguaggio condiviso che stabilisce quali informazioni devono essere scambiate e il loro significato”  .
In alcune Regioni come la Toscana, il Friuli Venezia Giulia, l’Emilia Romagna, ecc. ciò si è tradotto in una Legge regionale che ne ha definito i confini, di concerto con gli enti del territorio. E’ stata istituita una “rete” per la concertazione e lo scambio di tecnologie e servizi per la cooperazione applicativa, in grado di valorizzare e condividere il patrimonio informativo in una logica di servizio per i cittadini, le imprese e la stessa pubblica amministrazione.
Nei casi più evoluti ciò si è anche tradotto nella codifica e regolamentazione del processo di definizione dell’accordo di servizio, al fine di garantire fra gli enti della rete regionale e il mondo delle imprese ICT condivisione degli obiettivi, dei requisiti e degli standard della cooperazione; e di favorire lo sviluppo e l’integrazione di servizi.
In particolare, nella esperienza regionale toscana “…il processo è attuato, all’interno della community network regionale, attraverso la presentazione di un documento ‘Request For Comments’ (RFC ) e con l’attivazione di gruppi di discussione on-line chiamati ad esprimere un’opinione sull’RFC e termina con l’approvazione di un RFC standard. …Attraverso tale RFC la comunità si dà un insieme di regole che definiscono il ‘comportamento corretto’ da rispettare nell’utilizzo dell’infrastruttura. …La possibilità di un RFC di diventare standard è subordinata quindi ad un’ampia e aperta discussione da parte della comunità degli sviluppatori i RFC che viene stimolata e alimentata dalla figura del ‘Gestore’…”(Walter Volpi, funzionario della Regione Toscana e responsabile tecnico del task INF1 del progetto ICAR per la Regione capofila – Toscana) .

Emerge quindi, sia a livello regionale, sia a livello interregionale, l’importanza della community quale presupposto fondamentale alla realizzazione della cooperazione applicativa tra i sistemi informativi. Attraverso la community network, la Regione diventa facilitatore di un sistema nel dialogo tra gli enti del territorio ed erogatore di servizi di natura tecnica, utili alla produzione e gestione di accordi di servizio. In particolare, la Regione è al tempo stesso membro paritario della comunità e garante dell’infrastruttura, delle azioni di semplificazione dei processi, coordinatore delle azioni di cooperazione tra gli esperti di materia e gli esperti informatici, monitore dell’equilibrio delle esigenze e dei bisogni dei diversi enti. Allo stesso modo all’interno di una community interregionale, che è per definizione una comunità di community network, i componenti sono posti allo stesso livello e mettono a fattor comune le proprie esperienze di erogazione dei servizi regionali in cooperazione, attraverso processi di cooperazione interregionale organizzativa e tecnologica e con l’adozione di strategie comuni.

A fronte di tale assetto che risulta consolidato a livello interregionale e che si sta sviluppando gradualmente in tutte le Regioni, non si trova attualmente traccia di un modello simile per la cooperazione tra gli enti della pubblica amministrazione centrale e tra questi e gli altri livelli di governo. La Commissione SPC è stata istituita dal CAD (art. 79) per:

  • assicurare il raccordo tra le amministrazioni pubbliche, nel rispetto delle funzioni e dei compiti spettanti a ciascuna di esse,
  • realizzare la cooperazione applicativa fra i servizi erogati dalle amministrazioni;
  • promuovere l’evoluzione del modello organizzativo e dell’architettura tecnologica del SPC in funzione del mutamento delle esigenze delle pubbliche amministrazioni e delle opportunità derivanti dalla evoluzione delle tecnologie
  • promuovere il recepimento degli standard necessari a garantire la connettività, l’interoperabilità di base e avanzata, la cooperazione applicativa e la sicurezza del Sistema.

In tal senso, appare evidente che ad essa possa esser ricondotto un ruolo forte di garanzia del funzionamento e della diffusione dei processi di cooperazione sul territorio nazionale, anche attraverso una valutazione della qualità degli accordi stipulati. La Commissione per la sua composizione (art. 80 del CAD) rappresenta il luogo idoneo ad un coordinamento tra gli attori di governo centrale, locale e periferico.

redatto da Giovanni Damiano