Governance · Consolidamento
Duecento app di approvazione sono duecento processi che nessuno governa.
Nessuno ha deciso di costruirne duecento. Si è partiti da una, per un reparto che aveva fretta, e ha funzionato benissimo. Poi ne è servita un'altra, poi un'altra ancora — e oggi nessuno in azienda sa dire con certezza quanti iter autorizzativi esistano, dove siano, né chi li mantenga.
Come nasce un parco di app, senza che nessuno lo decida
La proliferazione non è un fallimento del low-code: è la sua promessa mantenuta. Dare a chi conosce il processo la possibilità di costruirselo, senza aspettare l'IT, è esattamente ciò che serviva — e ha funzionato. Ogni singola app è nata risolvendo un problema vero, spesso in pochi giorni.
Il conto arriva più tardi, e non arriva sulla singola app: arriva sull'insieme. Quando gli strumenti erano cinque, chiunque li teneva a mente. A cinquanta, nessuno li tiene più a mente, e non esiste un posto dove guardare per scoprirlo.
I costi che compaiono solo su scala
- Nessun registro dei processi: la domanda "quanti iter autorizzativi abbiamo?" non ha una risposta verificabile, solo stime.
- La stessa regola in decine di copie: alzare una soglia di firma o cambiare un responsabile significa toccare ogni app che la contiene — e ricordarsele tutte.
- Nessun versionamento: la modifica sovrascrive la precedente, quindi ricostruire quali regole valevano un anno fa diventa impossibile.
- Concetto di ritardo assente: senza SLA nativi, ogni app dovrebbe implementare da sola il proprio concetto di scadenza. In pratica quasi nessuna lo fa.
- Dati frammentati: il tempo medio di autorizzazione dell'azienda non è calcolabile, perché sta in decine di archivi separati con schemi diversi.
- Proprietà evaporata: chi ha costruito l'app ha cambiato ruolo, e chi la usa non sa a chi chiedere quando smette di funzionare.
- Superficie di accesso: ogni archivio ha i propri permessi, quindi verificare chi può vedere quali richieste è un esercizio che nessuno completa.
Nessuno di questi problemi è drammatico preso da solo. Insieme producono l'effetto che si osserva in quasi tutte le organizzazioni arrivate a questo punto: le approvazioni funzionano, ma non sono governate — e la differenza si scopre quando arriva una verifica o una riorganizzazione.
Prima di consolidare, contate
Il censimento è il passaggio che quasi tutti saltano, ed è quello che rende prevedibile tutto il resto. Va fatto sui dati, non con le interviste: gli ambienti low-code espongono un inventario di applicazioni e flussi con proprietario, data di creazione e ultimo utilizzo.
Ordinate quell'elenco per utilizzo effettivo e leggetelo dai due estremi. In cima trovate i pochi processi che reggono l'azienda — sono quelli da consolidare per primi. In fondo trovate la sorpresa: strumenti che nessuno apre da mesi, ma che qualcuno considera ancora ufficiali, e che continuano a ricevere permessi e manutenzione.
La scoperta ricorrente è che il numero di processi è molto più piccolo del numero di app. Sei varianti dell'autorizzazione di spesa, una per divisione, sono un solo processo con una condizione sul centro di costo.
Un motore, molte definizioni
| Un'app per processo | Un motore, molte definizioni |
|---|---|
| Ogni app reimplementa instradamento, notifiche e stato da capo. | Instradamento, SLA, deleghe e notifiche sono del motore: la definizione descrive solo il flusso. |
| Cambiare una soglia richiede di modificare ogni app che la contiene. | La condizione vive in una definizione versionata, e la si modifica in un punto solo. |
| L'archivio è un elenco per app, con schemi diversi. | Le richieste vivono in un modello unico, quindi sono confrontabili fra processi. |
| Il tempo medio di autorizzazione non è calcolabile. | Il tempo per step è registrato allo stesso modo per ogni processo. |
| La tracciabilità dipende dai permessi di ciascun archivio. | Il registro delle decisioni è unico e protetto da un vincolo di database. |
| Il ventesimo processo è la ventesima applicazione da mantenere. | Il ventesimo processo è una definizione in più: la piattaforma resta una. |
Come si consolida senza fermare l'azienda
Censite e raggruppate
Inventario dalle piattaforme, ordinato per utilizzo. Poi raggruppate le app che sono lo stesso iter con nomi diversi: è qui che duecento diventano venti.
Partite dal processo più usato, non dal più semplice
Il processo ad alto volume è quello che vi dà il ritorno visibile e che insegna davvero al sistema come lavorate. Un caso marginale non convince nessuno e non mette alla prova il modello.
Girate in parallelo, poi chiudete
Le nuove richieste entrano nel nuovo flusso, quelle aperte finiscono dove sono. Poi disattivate l'app vecchia: è il passaggio che decide l'esito, perché finché restano due strade qualcuno userà quella di prima.
Archiviate invece di migrare
Congelate gli archivi storici in sola lettura e mantenete l'accesso per il periodo di conservazione previsto. Riportare anni di pratiche chiuse dentro il nuovo sistema costa molto e serve raramente.
Che cosa non ha senso consolidare
Un consolidamento che punta a inglobare tutto fallisce, e merita di fallire. Vector si occupa di approvazioni: una richiesta che passa da una o più persone, con un esito e una scadenza. Se un'applicazione non è questo, spostarla non le fa guadagnare nulla.
- App di sola raccolta dati, senza nessuno che debba decidere: restano dove sono.
- Cruscotti e strumenti di consultazione: non sono processi.
- Automazioni brevi fra sistemi, senza intervento umano: è esattamente ciò per cui il low-code va bene.
- Strumenti operativi di un singolo reparto, usati da poche persone e che nessuno deve certificare.
Il criterio pratico è una domanda sola: se questa cosa si blocca, qualcuno se ne accorge e c'è una scadenza da rispettare? Se la risposta è no, non è un processo approvativo e non appartiene a Vector.
E chi ha costruito quelle app?
È la preoccupazione che emerge sempre, di solito non detta ad alta voce. Vale la pena affrontarla, perché la risposta è controintuitiva: chi ha scritto quelle app conosce le regole reali dei processi meglio di chiunque altro in azienda, comprese le eccezioni che non compaiono in nessuna procedura scritta.
Nella pratica sono quelle persone a disegnare le definizioni nel nuovo sistema, ed è il lavoro che sanno fare meglio. Quello che perdono è la parte che nessuno rimpiange: mantenere trenta copie della stessa logica e rincorrere le modifiche organizzative su ognuna.
Che cosa resta a Microsoft
Il consolidamento degli iter autorizzativi non è un'uscita dall'ecosistema, e non conviene raccontarlo così a nessuno. L'identità resta su Entra ID — Vector si autentica lì via OIDC, quindi gli account e le disattivazioni continuano a seguire le vostre procedure. Le automazioni brevi, i file, gli elenchi e le notifiche in Teams restano dove sono e funzionano bene.
Ciò che cambia è dove vive l'atto autorizzativo. Vector lo prende in carico e restituisce ogni esito via webhook firmati HMAC-SHA256 su otto eventi, quindi le automazioni a valle continuano a scattare come prima — il dettaglio del collegamento è nella pagina su Power Automate e i webhook.
Domande frequenti
Come si scopre quante app di approvazione esistono in azienda?
Partendo dai dati, non dalle interviste. Gli ambienti low-code espongono un inventario delle applicazioni e dei flussi con proprietario e data di ultimo utilizzo: già quell'elenco, ordinato per utilizzo, racconta quasi tutto. Le sorprese emergono in fondo — le app che nessuno apre da mesi ma che qualcuno continua a considerare ufficiali.
Vanno consolidate tutte?
No, e sarebbe un errore. Ha senso consolidare ciò che è davvero un'approvazione: una richiesta che passa da una o più persone, con un esito e una scadenza. Le app di sola raccolta dati, i cruscotti, i piccoli strumenti operativi di un singolo reparto non guadagnano nulla dallo spostamento e vanno lasciate dove sono.
Quanto dura una migrazione del genere?
Dipende da quanti processi migrate, non da quante app avete: molte app sono varianti dello stesso iter con nomi diversi, e collassano in una sola definizione con condizioni. Il primo processo richiede in genere qualche settimana, compreso il periodo in parallelo; i successivi molto meno, perché la piattaforma e le abitudini ci sono già.
Che cosa succede allo storico delle richieste già chiuse?
Di norma resta dove si trova: riportare anni di pratiche concluse dentro un nuovo sistema costa molto e serve raramente. La regola pratica è congelare gli archivi in sola lettura, far partire il nuovo processo per le richieste nuove, e mantenere l'accesso al vecchio per il periodo di conservazione previsto.
Chi ha costruito quelle app perde il proprio lavoro?
Al contrario: chi le ha scritte conosce le regole reali dei processi meglio di chiunque altro, comprese le eccezioni che non stanno in nessuna procedura. Nella pratica sono le persone che disegnano le definizioni in Vector, e smettono di fare la parte che nessuno ama — manutenere decine di copie della stessa logica.
Che cosa resta nell'ecosistema Microsoft?
Tutto ciò che quell'ecosistema fa bene: identità con Entra ID, automazioni brevi, movimentazione di file, aggiornamento di elenchi, notifiche in Teams. Vector prende in carico gli iter autorizzativi e restituisce gli esiti via webhook firmati, quindi le automazioni a valle continuano a funzionare come prima.
Continua a leggere
Quante ne avete davvero?
Portateci l'inventario del vostro ambiente, anche grezzo. In mezz'ora vi diciamo quante di quelle app sono in realtà lo stesso processo con nomi diversi.