Da un'integrazione al processo che le produce tutte

Contesto

Opencontent è una società cooperativa di Trento che costruisce e gestisce una piattaforma di servizi digitali per gli enti locali: il posto da cui un cittadino accede ai servizi del proprio comune, presenta una pratica e paga ciò che deve pagare. La usano alcune centinaia fra comuni ed enti.

È un cliente diverso da quasi tutti gli altri che raccontiamo qui: il software non è uno strumento del suo mestiere, è il suo mestiere, e dall’altra parte del tavolo c’è un’organizzazione tecnicamente competente. Ma il problema che ci ha portato è lo stesso che ha una piccola impresa con due gestionali che non si parlano. Cambia soltanto la scala.

Il problema

Una piattaforma che serve centinaia di enti non arriva mai su un tavolo vuoto.

Ogni comune ha già i propri sistemi: il software di back office con cui gestisce le pratiche, i propri canali di incasso, i propri fornitori, scelti in anni diversi e da persone diverse. Perché un servizio digitale funzioni davvero — che il cittadino paghi online e che l’incasso arrivi dove deve arrivare, riconciliato, senza che nessuno rimetta le mani su niente — la piattaforma deve parlare con ciò che quell’ente ha già. Non con uno standard immaginario: con quello.

Il risultato è che la crescita della piattaforma non è limitata dalla piattaforma. È limitata dalle integrazioni: ciascuna con un sistema diverso, ciascuna un progetto a sé, ciascuna che consuma il tempo delle stesse persone che dovrebbero far evolvere il prodotto.

E le integrazioni non arrivano una per volta: si accumulano in una coda. È lì che il problema cambia natura, perché dietro ogni voce di quella coda non c’è un desiderio, c’è una data. Un comune che ha annunciato un servizio ai propri cittadini, un partner che ha preso un impegno, un integratore che aspetta il proprio pezzo per fare la sua parte. In fondo alla catena le date di tutti dipendono da quando quel collegamento è pronto.

Cosa c’era prima

Capacità interna, competente e già impegnata. Non un vuoto di conoscenza: un vuoto di ore, e la consapevolezza che ogni integrazione nuova le avrebbe sottratte al prodotto.

Il «prima» di questo caso non è un sistema da sostituire. È un lavoro che non si riusciva a fare in parallelo a tutto il resto, mentre la coda restava dov’era e le date che ci stavano attaccate si avvicinavano.

Da qui la decisione che rende questo caso quello che è: portare quel lavoro fuori. Un’organizzazione il cui mestiere è il software, con dentro le competenze per farlo da sé, ha scelto di affidarne l’esecuzione a qualcun altro per non fermare il resto. È una scelta che si fa solo se chi la riceve la porta a termine.

Cosa abbiamo costruito

Un componente di integrazione fra la piattaforma e i sistemi attraverso cui passano i pagamenti verso la pubblica amministrazione, portato fino in produzione sull’ambiente di un ente reale: installato, configurato, funzionante su traffico vero, con la documentazione consegnata e un periodo di garanzia dichiarato.

La parola che porta il peso, in quel paragrafo, è produzione. Un’integrazione che funziona in prova non ha ancora incontrato le cose che rendono difficili le integrazioni: il dato scritto in un modo che nessuna specifica prevedeva, la risposta che non arriva, la transazione da riconciliare quando qualcosa si è interrotto a metà. Il valore di questo lavoro sta tutto dopo quella soglia, non prima.

E poi la seconda metà, che è la ragione per cui il lavoro è stato impostato così fin dall’inizio: dalla prima integrazione è uscito il processo con cui si producono le altre. Ciò che si ripete identico da un ente al successivo, separato da ciò che cambia davvero, e messo in fila una volta sola — così la seconda integrazione non è la prima rifatta da capo, e la terza non riapre le domande già chiuse nella seconda.

È la differenza fra consegnare un pezzo e consegnare il modo di produrli. E si misura in una cosa sola: le integrazioni sono state consegnate nei tempi concordati. In una catena in cui la data di ciascuno dipende da quella di chi lo precede, è l’unico risultato che si propaga fino in fondo — a Opencontent, ai partner e agli integratori che lavorano sulla piattaforma, ai comuni e alle province che avevano un servizio da aprire, e al cittadino che quel servizio se lo trova acceso il giorno in cui gli è stato promesso.

Valore

• Un componente di integrazione in produzione su un ambiente reale, documentato e con garanzia dichiarata: non un prototipo, non una dimostrazione
• I pagamenti verso la pubblica amministrazione attraversano la piattaforma e i sistemi già in uso presso l’ente, senza che nessuno faccia da ponte a mano
• Il processo con cui escono le successive: ciò che si ripete separato da ciò che cambia da ente a ente, così la seconda non ricomincia dalla prima
• Le consegne nei tempi concordati, che in una catena di soggetti che si aspettano a vicenda è il risultato da cui dipendono tutti gli altri
• Capacità specialistica aggiunta senza sottrarla al prodotto: le ore del team interno sono rimaste dov’erano più utili

Perché questo caso parla a te

Se in azienda hai due sistemi che dovrebbero scambiarsi dati e ogni volta è una persona a riallinearli a mano, il problema che riconosci è questo, e non cambia con la dimensione.

Non conta che qui si tratti di enti pubblici e di pagamenti. Conta la forma: un sistema che funziona bene, un altro sistema che funziona bene, e in mezzo qualcuno che copia, controlla e ricontrolla — perché farli parlare è sempre sembrato un progetto troppo grande da cominciare.

E conta una seconda forma, che pesa anche di più. Il lavoro che non riesci a incastrare non è il lavoro che conta meno: è quasi sempre quello su cui qualcun altro — un cliente, un fornitore, un ufficio — ha già messo una data. Farlo fare a qualcuno di fuori non toglie niente a chi lo saprebbe fare: libera le ore di chi, intanto, deve tenere in piedi tutto il resto.