Il dilemma che si sta delineando

Ciao.

Nelle PAl si stanno delineado questi due scenari:

  1. ogni fornitore vuole diventare partner tecnologico:
    questo semplifica la vita al fornitore che così non dove integrarsi con l’unico partner tecnologico già presente, del resto la complica al cittadino che per pagare la cosap andrà sul portale del fornitore 1, per la tari sul portale del fornitore 2 etc etc

  2. il fornitore si integra all’unico partner tecnologico
    questo richiede una integrazione ma il cittadino va su un portale solo per pagare tutti i tributi all’ente

è una scelta non tecnica, non procedurale, ma secondo me di filosofia

si vuole davvero semplificare la vita al cittadino o come pa continuiamo a fare quello che il fornitore vuole ed è più comodo per “noi” come pa?

Cosa ne pensate?

Andrea

2 Mi Piace

Ciao Andrea. Per me alla fine conta quello che semplifica di più la vita al backoffice del tuo ente.
Se hai un unico partner tecnologico per tutto l’ente, sei legato mani e piedi a lui, ma probabilmente hai soluzioni integrate che fanno andare più liscio il lavoro (e in enti con personale risicato non è poco, anzi!). E il vantaggio dell’unico portale per i tributi.
Se hai più partner tecnologici diventa più semplice cambiarli in caso di problemi o anche di opportunità migliori che compaiano sul mercato, perchè hai dei silos operativi abbastanza autonomi tra loro. Ma il vantaggio vero è che probabilmente hai il migliore sulla piazza per il calcolo della cosap, il migliore per la gestione delle mense, ecc ecc ecc. perchè è difficile che chi fa tutto sia il migliore in tutto.
Alla fine al cittadino dovrebbe cambiare poco, perchè sempre su pagoPA si va a confluire, o no? O non ho capito io il problema?

2 Mi Piace

AHHHHHHHHHHHHHHHHHHH vado retro Satana!!!
Silos, meglio per backoffice ente, tu mi vuoi far svenire mentre leggo!

L’ente deve diventare un’unica piattaforma integrata: è piu importante l’integrazione che non avere il TOP per tari, ilTOP per cosap, il TOP per mensa.

Le informazioni devono essere strutturate, integrate, e facilmente fruibili dal cittadino non solo dal backoffice.

Io muoro…

Andrea

1 Mi Piace

Eccerto, “deve”, ma se hai i soldi e l’hardware… (torniamo al discorso dei piccoli comuni a te così caro).
Poi gli accidenti degli impiegati perchè non gli funziona più una certa procedura e alcuni conteggi e riconciliazioni se le devono fare a mano li prendi tu :wink: Purtroppo ne ho sentiti molti di operatori, ma di gente che ha tutto integrato ed è contenta ne ho sentita davvero poca. Le sw house hanno ancora molto da migliorare, perchè spesso NON integrano le informazioni e l’operatore impazzisce (e il servizio al cittadino peggiora). Questo è il vero problema.

1 Mi Piace

E’ questa la chiave.

2 Mi Piace

Dalla mia (piccola) esperienza, meglio pochi PT qualificati (pagoPA è un sistema complesso e articolato, del quale la componente tecnologica è solo una minima parte) e fornitori che adeguano i loro prodotti alle specifiche del PT scelto. Meglio ancora se intermediari tecnologici regionali, che perseguono l’interesse pubblico e che, in quanto unici interlocutori per gli enti più piccoli, fungono da aggregatori di richieste ed esigenze (è poi compito degli enti sollecitare le Regioni ed esercitare la pretesa di attivarle). Certo, in quest’ultimo caso i tempi non sono quelli di un soggetto privato ma si ha comunque la garanzia di rilasci omogenei per tutti e un’evoluzione della piattaforma aderente alle normative, interoperabile e magari pubblicata in riuso sul catalogo dei servizi. Al contrario, pensate ad avere tanti PT, ognuno con i propri tempi di risposta agli adeguamenti normativi e delle linee guida tecniche…

Il rischio di avere tanti PT è di replicare su una piattaforma abilitante la logica a silos a cui AgID sta tentando di porre rimedio da tempo (e sono sforzi che costano). Di fronte a tutto questo, l’eventuale intercambiabilità del PT resta una chimera (non è mica così semplice e nemmeno a costo zero).

Visto che pagoPA non fa da DB centralizzato dei pagamenti, che toglierebbe da tutti questi impicci, puo’ andare bene uno o piu’ partenr tecnologici, basta che a un certo punto ci sia un punto di raccordo tenendo in mente che, come da linee guida agid, la vita di un pagametno nasce con l’esigenza di pagamento e si conclude con la regolarizzazione dell’incasso in banca e la contabilizzazione.
Dall’unico punto di raccordo (che puo’ coincidere anche col software dell’unico PT) ci si collega all’unica pagina di pagamenti esposta (se poi sono piu’ di una non e’ che sia una tragedia, basta che si capisca dove andare) e, soprattutto, alla contabilità e ai gestionali che generano i pagamenti dovuti (o pagamenti in attesa).

Verissimo che ogni fornitore si propone di fare da PT.

SOLUZIONE: visto che pagoPA non fa da DB centralizzato (gia’ detto?) occorrerebbe definire delle interfacce di interoperabilità per gli applicativi che si affacciano sul mondo pagoPA. In che modo un gestionale comunica un’esigenza di pagamento al software dei pagamenti? come riceve risposta? come la contabilità preleve i flussi di rendicontazione dal sistema e riconcilia tutto? Se oltre agli schemi XML e i WS per parlare col nodo dei pagametni ci fosse convergenza sule regole per questi altri dialoghi a quel punto uno potrebbe avere tutti i PT che vuole, scegliere gli applicativi verticali che preferisce e scappare dalle suite e si darebbe anche un bel colpo al vendor lock-in, che, nonostante i proclami, sembra stia diventando sempre piu’ presente.

Nota:

  • il PT unico e’ una chimera, se per esempio usi impresainungiorno come portale SUAP (con il lodevole intento di rifarti a un portale unico nazionale, che e’ una cosa bella in se’) ti becchi per forza Infocamere come PT (e pure un PT rognoso privo di API);
  • senza regole c’e’ anche il problema che, se non acquisti uan suite completa e rendi il tuo s.i. monomarca , ti ritrovi con delle operazione fondamentali che nessun software ti fa perche’ sono rognose e si aspetta che le faccia un altro.
2 Mi Piace

L’idea sarebbe integrare il TOP di ogni cosa. Occorre definire i linguaggi di interoperabilità fra i componenti del sistema informativo. Per esempio nel mondo sanitario esiste HL7 CDA2.

Direi che bisogna affermare che le cose devono essere fatte come vuole l’amministrazione, non come vuole il fornitore. E bisogna rifiutare le soluzioni mediocri e miopi che affollano il mercato. Chi ha le competenze e i mezzi per trattare con i fornitori ha l’obbligo civico e morale di farlo.

Il problema esiste, figurati se non lo so io che, oltre all’Unione che ha già per fortuna una consistente parte di servizi a pagamento, 8 comuni con fornitori quasi tutti differenti. La soluzione sarebbe acquistare solo software che offre i giusti servizi di integrazione. Ma vi pare che quando si compra un software siano questi lati tecnici quelli che vengono maggiormente presi in considerazione ? no, almeno nel mio caso. Si compra il miglior software specialistico, non il miglior software tecnico. Mi è capitato il caso di non poter cambiare software finchè una certa persona non è andata in pensione, richiesta non della persona stessa che si sarebbe potuta anche ignorare, ma addirittura del sindaco. che strumenti abbiamo per contrastare questo più di esprimere e magari depositare un parere tecnico che nessuno capisce e che il più delle volte viene ignorato ?

sono cattiva ?

2 Mi Piace

il punto e’: quali sono i giusti servizi di integrazione?
Tutto si integra, basta pagare e trovare un fornitore che ha voglia di farlo.

Si dovrebbe arrivare al punto in cui tu compri un software (che ti soddisfa sia dal lato funzionale che dal lato sistemistico) e, con poche configurazioni da interfaccia, lo fai dialogare col resto del mondo del sistema informativo.
Per esempio, al software di contabilità inserisci url (utente, password, token, certificato) del sistema dei pagamenti a cui chiedere il dettaglio dei riversamenti con una chiamata che e’ uguale in tutto il mondo. Il software delle rette, allo stesso modo, con l’url e poco altro inserisce un pagamento dovuto nel sistema dei pagamenti, con una chiamata uguale in tutto il mondo (che potrebbe anche avere un linguaggio mutuato dai servizi web del nodo, uno schema XML estratto da quello di RPT/RT o dell’avvisatura digitale). La pagina dei pagamenti sa che ha da contattare un certo numero di repository di pagamenti per offrire all’utente autenticato SPID i pagamenti associati al suo codice fiscale: a ciascuno chiede “mi dai i pagamenti da pagare del codice fiscale XXXX?” “mi dai anche quelli pagati con l’url dove fare download della ricevuta?”. Anche il protocollo informatico espone i suoi bei servizi basati su un linguaggio condiviso (basterebbe salvare e completare poco poco gli schemi della circolare 61 prima che sia sepolta dalle nuove linee guida, sigh): coisi’, il software dei tributi, anche lui configurato in pochi passi, crea il pagamento in attesa sul sistema dei pagamenti, preleva l’avviso analogico (o se lo fa?), produce una lettera con i dettagli del tributo personalizzati per il destiantario, la protocolla con una chiamata uguale in tutto il mondo e chiede, con la stessa richiesta uguale in tutto il mondo, al protocollo di inviarla via PEC (o via INAD o via quello che ci sara’) insieme all’avviso analogico e poi controlla l’esito dell’invio. Già che c’e’ può mandare pure una notifica su IO.
A sua volta il software dei tributi espone servizi che si interrogano con un linguaggio condiviso, magari anche dall’esterno, cosi’ qualunque amministrazione titolata a farlo puo’ vedere se tizio e’ in regola con un pagamento, basta che sappia l’indirizzo a cui chiedere “tizio e’ in regola coi tributi comunali?”, oppure ancora al cittadino rendiamo disponibile una pagina che interroga vari componenti e db del sistema informativo e espone tutte le informazioni ricavate (i tuoi tributi, i tuoi pagamenti, i certificati richiesti da te o su di te, le tue istanze … ).
Quando poi un software non ci piace piu’, si cambia e nel nuovo ci si mettono gli estremi delle interfacce con gli altri componenti del sistema.

3 Mi Piace

Mi sono trovata anch’io in questa situazione. Gestire il cambiamento è molto complicato e richiede pazienza e polso fermo ma soprattutto l’appoggio del vertice, senza quello non superi le resistenze. Ma se il vertice è con te, superi qualunque resistenza con un e un solo stratagemma: dimostrare che il nuovo sw migliora la vita dell’impiegato.
Varie volte mi sono trovata davanti muri di gomma, boicottaggi, proteste… poi una volta visto il sw venivano da me e dicevano “ma sai che la procedura X è veramente più semplice? Ma sai che hai ragione, adesso lavoro meglio!!” e diventavano loro stessi sponsor del sw presso i colleghi degli altri enti “prendetelo anche voi, è un altro mondo!” (e io che pensavo a tutte le imprecazioni che mi avevano fatto tirare prima…).
Il problema è che troppe volte i sw presentati come migliorativi si sono rivelati altrettante sole e l’impiegato è stufo di fregature, non è pura e semplice resistenza al cambiamento, sono decenni di esperienze negative.

2 Mi Piace

hai perfettamente ragione. ci vorrebbe un set minimo di webservices standard che un software deve garantire, poi se fa anche il ragù tanto meglio.
Ad esempio per il protocollo in Emilia Romagna avevano tentato di imporre a livello regionale una sorta di standard che si chiama DOCER (servizi di protocollazione e fascicolazione esposti tramite Web Services), anche per facilitare successivamente l’invio al conservatore che per noi in tutta la regione è lo stesso ed è il Parer. In teoria uno poteva comprare il protocollo che voleva, basta che avesse le webservices di DOCER. Ma molti fornitori, lavorando in tutta Italia avevano già un loro documentale con webservices differenti, e hanno cercato, ovviamente di vendere quello, riuscendoci. ovviamente poi hanno venduto anche il connettore al Parer… insomma queste cose vanno imposte a livello nazionale… si vuole evitare il lock-in ? ecco anche questo andrebbe nella direzione di evitarlo, perchè come giustamente dici tu favorisce il cambio più indolore del software… perchè se ogni volta mi devo ricomprare tutti i connettori allora è chiaro che mi conviene sempre meno anche dal punto di vista economico…

3 Mi Piace

realista, sono cose che + o - chiunque vive nella pa ha vissuto

Molto molto interessante.

La compliance agid dovrebbe prevedere anche queste sottoinsieme minimo di Ws o API di interfacciamento.

Ecco, si è ma sentito qualcuno di AgID, Team, Dipartimento, Ministero che abbia anche solo accennato a questo argomento? Eppure e’ la chiave.

AgID li dovrebbe proprio scrivere e imporre questi WS o API!

4 Mi Piace

Toc Toc … AGIIIIIIDDDDDD dove siete ?
:rofl: :rofl: :rofl:

a selezionare esperti.: https://www.agid.gov.it/it/agenzia/stampa-e-comunicazione/notizie/2020/07/14/avvisi-selezione-profili-professionali-agid
ma nessuno, temo, che si occupera’ di quanto sopra.

Credo pero’ che un set minimo di API con definizione di un linguaggio standard sia un risultato che si possa ottenere solo a partire dagli operatori economici coinvolti, cioe’ le software house che servono la p.a. In altri contesti internazionali mi sembra che si sia arrivati a questi risultati tramite consorzi e collaborazione di tutti i portatori di interesse.
Certo, finché il core business di molte software house e’ fatturare le giornate/uomo (non si sa perche’ col segno di divisione in mezzo e non all’inzio, w l’aritmetica) per configurazioni e personalizzazioni di poco conto…

Ci sto lavorando parecchio anche io su questo tema.
Sto puntando sul MyPay di regione Lombardia ed integrare tutti i servizi PagoPA con quella piattaforma: almeno saremo uniformi a livello di regione in un unico portale gratuito e gov.
Anche l’integrazione con l’App Io sarà semplificata a questo punto se tutti i pagamenti passeranno da questa soluzione.

Il problema è che la forza di un solo ente o pochi enti vale poco…
Ogni partner tecnologico propone la sua soluzione, ma noi dobbiamo resistere e richiedere i sistemi inter operabili!E’ una bella battaglia!
E’ necessario una grande sinergia e puntare i piedi a terra, oltre che di personale competente in questi temi.

4 Mi Piace

nel piano triennale mi pare che ci sia questo obiettivo, ma altrettanto la strada mi pare molto lunga… il gruppo di lavoro deve ancora costituirsi…
ne avremmo bisogno già ora

1 Mi Piace

Apprezzo molto il tuo sforzo. Spiace che la cosa sia demandata ai singoli e non sistemica.