~190K anno
In tutta l'amministrazione metropolitana
10K+ anno
Gestite attraverso processi istituzionali formali
92
All'interno dell'ecosistema istituzionale metropolitano
Un unico
Collegare le operazioni con i sistemi legacy e la storia istituzionale
1. La sfida enterprise
Un’importante autorità pubblica metropolitana nell’Europa meridionale governa un territorio di 92 comuni, circa 1.170 km² e quasi 3 milioni di residenti. Le sue responsabilità spaziano dalla pianificazione strategica, mobilità e strade, infrastrutture pubbliche, scuole metropolitane, appalti, sviluppo territoriale, ambiente, governance amministrativa e trasformazione digitale. Nel tempo, queste responsabilità avevano prodotto un panorama informativo altrettanto complesso.
Applicazioni aziendali, soluzioni sviluppate internamente, piattaforme di workflow, archivi dipartimentali, sistemi di corrispondenza, applicazioni per delibere amministrative e integrazioni personalizzate erano stati introdotti in momenti diversi per risolvere specifiche esigenze organizzative. Alcuni erano diventati tecnologicamente obsoleti. Altri contenevano ancora anni di informazioni e storia istituzionale che non potevano semplicemente sparire. E diversi ambienti di workflow apparentemente configurabili dipendevano in pratica da software personalizzati sostanziali per moduli, regole, integrazioni, generazione di documenti, eccezioni e interazione con l’utente.
L’autorità ha quindi scelto di non modernizzarsi ricostruendo ogni applicazione in modo indipendente. L’obiettivo era stabilire un livello informativo e operativo aziendale condiviso in grado di farsi carico progressivamente di funzionalità riutilizzabili come contenuti, business object, casi, processi, comunicazioni istituzionali, identità e firma digitale, ricerca, integrazione e prove documentali. I sistemi legacy potrebbero quindi essere sostituiti dove opportuno — o rimanere collegati dove la loro storia o responsabilità specialistica è ancora importante.
La modernizzazione è diventata una capacità architettonica continua piuttosto che una sequenza di progetti di sostituzione delle applicazioni.
2. Perché era complesso
La sfida non era semplicemente spostare il vecchio software su una tecnologia più recente. Era preservare il significato di business e la continuità istituzionale mentre i sistemi sottostanti cambiavano.
Modernizzare ogni applicazione legacy avrebbe preservato la frammentazione
Molte applicazioni esistenti duplicavano funzionalità che avrebbero potuto invece diventare servizi enterprise condivisi. Ricostruire ognuna individualmente avrebbe modernizzato la tecnologia mantenendo però gli stessi silos architettonici.
La profondità storica rende alcuni sistemi temporaneamente insostituibili
Un’applicazione può contenere anni di documenti, metadati, relazioni e storia istituzionale. Sostituire la sua interfaccia può essere facile. Sostituire il suo significato operativo è molto più difficile. Coopera consente a questi sistemi di continuare a contribuire con le loro informazioni mentre le nuove operazioni vengono orchestrate altrove.
Un diagramma di workflow non è l'operazione completa
Le piattaforme di processo esistenti spesso contenevano solo una parte del reale comportamento aziendale. L’applicazione di produzione dipendeva anche da: Moduli · Regole · Validazione · Dati · Documenti · Integrazioni · Eccezioni · Azioni Specializzate. La migrazione richiedeva quindi di recuperare ciò che fa realmente funzionare l’operazione amministrativa, non semplicemente riprodurre il suo diagramma di processo.
La corrispondenza può avviare operazioni molto più ampie
L’amministrazione gestisce circa 190.000 registrazioni di corrispondenza ogni anno. Una comunicazione può essere registrata e archiviata — ma può anche avviare una questione amministrativa, attivare una procedura, coinvolgere una struttura organizzativa responsabile e generare lavoro successivo. La registrazione è quindi spesso solo il primo evento.
Le decisioni istituzionali richiedono un'esecuzione governata
Più di 10.000 delibere amministrative formali ogni anno possono coinvolgere proposte, contenuti di supporto, revisione organizzativa, approvazioni, firme digitali, registrazione, pubblicazione ed evidenze risultanti. Il documento finale deve rimanere collegato al modo in cui la decisione istituzionale è diventata legittima.
3. Come Coopera tiene unita l'operazione
Coopera fornisce una base operativa comune tra i domini amministrativi invece di diventare un’altra applicazione verticale. Contenuti, contesto di business persistente, ciclo di vita, comunicazione, processi e integrazioni sono gestiti in modo coerente.
I Business Object Viventi
Non esiste un unico oggetto di business universale o un unico workflow universale. Ma ognuno può mantenere il contesto che deve sopravvivere mentre persone, documenti, sistemi e processi cambiano attorno ad esso: Identità · Stato · Contenuto · Relazioni · Responsabilità · Approvazioni · Storia · Evidenze · Cosa può succedere dopo.
- Un workflow può iniziare e finire.
- Un’applicazione può essere eventualmente sostituita.
- Un documento può essere generato.
- Un sistema legacy può continuare a contribuire con informazioni storiche.
L’oggetto di business amministrativo rimane il punto di continuità persistente. Questo è ciò che permette alla modernizzazione di procedere senza costringere l’amministrazione a ridefinire le proprie operazioni attorno a ogni generazione di software.
4. Come Appare nella Pratica
Delibere amministrative
Il documento registra la decisione, il business object preserva il modo in cui è diventata legittima. Una Delibera Amministrativa inizia prima che esista il documento istituzionale finale. Il suo contesto operativo può includere: Struttura proponente · Oggetto · Contenuto di supporto · Riferimenti a budget o appalti · Revisione · Approvazioni · Firme digitali · Documento finale · Registrazione · Pubblicazione · Prove documentali. La composizione del documento diventa quindi parte dell’esecuzione attorno alla Delibera. Diverse famiglie di delibere e determinazioni possono preservare le proprie responsabilità e requisiti di approvazione pur utilizzando la stessa base operativa sottostante.
Il documento finale è di fondamentale importanza. Ma non è l’operazione completa.
La delibera preserva il contesto, la responsabilità e le evidenze attraverso cui la decisione istituzionale è diventata legittima.
Dalla corrispondenza alla delibera
La registrazione può diventare l’inizio dell’operazione. Le comunicazioni istituzionali possono entrare tramite email, canali certificati, portali e altri meccanismi di acquisizione. Una comunicazione può essere: Ricevuta → Registrata → Collegata a una pratica → Inoltrata al responsabile → Utilizzata per avviare il lavoro → Risolta. Il record della corrispondenza fornisce ancora l’evidenza formale che la comunicazione è entrata o uscita dall’amministrazione. Ma la questione di business creata da quella comunicazione può persistere molto più a lungo.
Coopera permette alla corrispondenza di diventare parte dell’appropriato contesto amministrativo persistente invece di terminare la sua vita operativa alla registrazione.
La registrazione annota la comunicazione. L’oggetto di business ne porta avanti le conseguenze.
Pratiche amministrative
Le procedure pubbliche complesse possono sopravvivere ai singoli workflow. Una pratica può durare mesi o anni, coinvolgendo diversi processi in fasi differenti:
- Un processo di revisione può iniziare e finire.
- Può seguire un processo di approvazione.
- Un’altra procedura può essere introdotta in seguito.
La pratica sopravvive a loro. Il lavoro può cambiare senza richiedere che la realtà amministrativa stessa venga ricostruita.
Sostituzione delle applicazioni legacy
L’applicazione può scomparire senza portare con sé l’operazione. Alcune applicazioni legacy forniscono funzionalità che sono ora disponibili orizzontalmente attraverso la piattaforma condivisa: archiviazione di documenti, workflow, moduli, attività, ricerca, gestione semplice delle pratiche o integrazione. Dove questi sistemi non forniscono più un valore unico, le loro responsabilità possono spostarsi progressivamente nell’ambiente comune. L’applicazione legacy può quindi essere ritirata. Dove un sistema possiede ancora informazioni storiche o funzionalità specialistiche che non possono ancora essere sostituite economicamente, può rimanere collegato.
Questo crea una regola di modernizzazione pragmatica: Sostituisci dove possibile. Integra dove la storia o la specializzazione contano ancora.
L’amministrazione può quindi modernizzare diverse aree a velocità differenti senza forzare ogni dominio operativo nello stesso calendario di migrazione.
5. Preservare le informazioni istituzionali attraverso il cambiamento
Una conseguenza centrale di questa architettura è che il contenuto aziendale diventa meno dipendente dall’applicazione che lo ha originariamente creato.
Storicamente, il rapporto era spesso: L’applicazione → possiede i suoi documenti.
Il nuovo modello si muove verso: L’azienda → possiede le sue informazioni e prove documentali
Le applicazioni → partecipano al loro ciclo di vita. Documenti, metadati, relazioni, provenienza e prove storiche possono quindi rimanere accessibili anche quando l’applicazione di origine cambia.
Questo è particolarmente importante nel governo, dove contratti, delibere, concessioni, procedure di appalto, opere pubbliche e corrispondenza possono rimanere istituzionalmente rilevanti per anni dopo che il loro processo originale è stato completato. L’interoperabilità standardizzata applica lo stesso principio ai sistemi. Un’applicazione specialistica può partecipare oggi senza diventare l’architettura che l’amministrazione dovrà preservare domani.
Le informazioni e le operazioni diventano più durevoli della tecnologia che le sta attualmente eseguendo.
6. Modernizzazione continua
Il livello operativo condiviso consente alla modernizzazione di avvenire progressivamente.
- Un’applicazione documentale legacy può essere ritirata mentre le sue informazioni rimangono.
- Un’applicazione con un workflow pesante può essere ricostruita attorno a business object persistenti ed esecuzione configurabile invece di ricreare la sua vecchia architettura personalizzata.
- Un sistema specialistico può rimanere collegato finché la sua sostituzione non diventa giustificata.
- Un nuovo servizio amministrativo può consumare le stesse funzionalità di contenuto, processo, ricerca e integrazione senza creare un altro stack tecnologico indipendente.
La piattaforma si è anche spostata su una moderna infrastruttura cloud come parte della più ampia trasformazione. Ma il cloud non è la storia centrale.
Spostare il panorama applicativo esistente su un’infrastruttura diversa avrebbe preservato la frammentazione sottostante. Il cambiamento importante è architettonico: Informazioni condivise · Oggetti di business persistenti · Esecuzione riutilizzabile · Integrazione standardizzata · Sostituzione progressiva dei sistemi legacy.
L’infrastruttura moderna supporta la trasformazione. Il modello operativo condiviso la rende possibile.
6. Il Risultato
L’autorità metropolitana sta progressivamente sostituendo un panorama frammentato di applicazioni legacy e soluzioni personalizzate con una base operativa enterprise condivisa. Circa 190.000 record di corrispondenza ogni anno possono partecipare allo stesso ambiente utilizzato per governare le informazioni e i processi amministrativi. Più di 10.000 delibere amministrative annuali possono conservare i loro contenuti, responsabilità, approvazioni ed evidenze risultanti all’interno di contesti operativi persistenti. Ma il volume delle transazioni non è il risultato più importante.
Il cambiamento più profondo è che le responsabilità precedentemente ricostruite ripetutamente all’interno di singole applicazioni sono ora capacità condivise. L’amministrazione può ora:
- sostituire un’applicazione senza perdere le sue informazioni;
- riprogettare un processo senza perdere il suo significato aziendale;
- mantenere un sistema legacy senza renderlo l’architettura del futuro.
Il risultato non è semplicemente una nuova piattaforma di gestione documentale o di workflow. È un livello di modernizzazione continua che consente alle operazioni del settore pubblico e alla storia istituzionale di rimanere coerenti mentre applicazioni, workflow, integrazioni e infrastrutture si evolvono attorno a loro.
5. Cosa Dimostra Questo Caso
La modernizzazione enterprise non richiede una sostituzione radicale
Sistemi diversi possono evolversi a velocità diverse mentre il contesto amministrativo persistente fornisce continuità attraverso la trasformazione.
L'applicazione non è l'operazione di business
Delibere amministrative, pratiche e procedure pubbliche possono sopravvivere a più generazioni di software perché la loro identità e storia operativa rimangono separate dall’applicazione che attualmente esegue parte del lavoro.
La storia istituzionale può sopravvivere alla sostituzione delle applicazioni
Le informazioni e le evidenze rimangono accessibili e governate mentre applicazioni, workflow, integrazioni e infrastrutture cambiano progressivamente attorno a loro — preservando la continuità istituzionale attraverso la modernizzazione.
L'interoperabilità può creare libertà di modernizzazione
Un sistema legacy o specialistico può partecipare oggi senza diventare l’architettura che l’organizzazione deve preservare domani.
