Premesse
Ogni funzionalità potente porta con sé un rischio speculare: la stessa capacità che permette di aggiornare in un colpo solo lo stato di mille asset filtrati, o di concatenare automaticamente più operazioni in sequenza su una selezione di record, è anche la capacità che, mal governata, può produrre un danno esteso a mille record in un colpo solo, oppure diventare una scorciatoia per aggirare permessi che dovrebbero restare validi record per record.
Negli articoli precedenti ho descritto come un motore dati configurabile permetta azioni di massa e catene di automazioni senza scrivere codice: qui voglio affrontare la domanda che ogni responsabile IT si pone, giustamente, di fronte a questa potenza: come si mantiene il controllo?
Perché un aggiornamento massivo deve rispettare, riga per riga, gli stessi controlli di permesso di una modifica singola?
È una tentazione tecnica comprensibile, ma pericolosa: per velocizzare un’operazione su migliaia di righe, si potrebbe essere tentati di eseguire l’aggiornamento con una query diretta che bypassa i controlli applicativi pensati per l’editing di una singola cella. È esattamente l’errore da evitare.
Un Software FM evoluto ha un motore ben progettato che applica la stessa logica di permesso – chi può modificare quel campo, su quali righe, in base a quale ruolo o gruppo di appartenenza – anche quando l’operazione riguarda mille righe contemporaneamente, filtrando silenziosamente le righe su cui l’utente non avrebbe comunque diritto di intervenire, invece di applicare l’aggiornamento indiscriminatamente a tutto ciò che rientra nel filtro.
Questo richiede, tecnicamente, che la Row-Level Security , in alcuni software chiamata anche “VPA”, dove i permessi a livello di singolo campo siano implementati come un livello trasversale applicato sempre, indipendentemente dal punto di ingresso della richiesta, e non come un controllo aggiunto solo sul percorso della modifica singola e dimenticato su quello dell’aggiornamento massivo. È un dettaglio che si verifica solo mettendo alla prova il sistema, non leggendo la documentazione commerciale.
Come si progetta una catena di azioni automatizzate senza costruire, di fatto, un motore di workflow incontrollabile?
Concatenare più azioni – aggiorna un campo, poi invia una notifica, poi genera un documento – in un’unica operazione configurabile è potente, ma introduce un problema di prevedibilità: se la catena può crescere senza limiti, con logiche condizionali complesse e ramificazioni, si finisce per costruire un motore di workflow completo, con tutta la sua complessità di test, debug e manutenzione, ma senza gli strumenti di osservabilità che un motore di workflow dedicato offrirebbe.
Un approccio più maturo accetta un compromesso esplicito: la catena resta una sequenza lineare di passi configurabili, ciascuno con un effetto chiaro e isolato, senza pretendere di sostituire un motore di processo completo per i casi che davvero lo richiedono.
Questo compromesso ha un vantaggio tecnico concreto: una catena semplice e lineare è facile da verificare a colpo d’occhio anche per un amministratore non sviluppatore, che può leggere la sequenza di passi configurati e capire esattamente cosa succederà, senza dover ragionare su condizioni annidate e biforcazioni logiche.
Che ruolo ha l’audit log nel rendere un’automazione potente anche un’automazione responsabile?
Ogni azione di massa e ogni automazione configurata dovrebbe lasciare una traccia verificabile: chi ha lanciato l’operazione, quando, su quale insieme di righe, con quale esito per ciascuna di esse. Non è un dettaglio accessorio: è ciò che trasforma una funzionalità potente da un rischio silenzioso a uno strumento responsabilizzante.
Se un aggiornamento massivo produce un risultato inatteso, un log dettagliato permette di ricostruire esattamente cosa è successo e su quali record, invece di dover indovinare retroattivamente la causa di un’anomalia scoperta giorni dopo. Un log di questo tipo dovrebbe essere immutabile – scrivibile solo in append, mai modificabile o cancellabile da chi ha eseguito l’operazione – così da restare una fonte affidabile anche in caso di contestazione o di verifica interna.
Perché limitare chi può configurare nuove azioni e automazioni è importante quanto permettere di usarle?
C’è una distinzione tecnica e organizzativa da tenere ben separata: usare un’azione già configurata dovrebbe essere alla portata di molti utenti operativi, in base ai propri permessi sul dato; configurare una nuova azione o una nuova catena di automazioni dovrebbe restare riservata a un numero ristretto di amministratori, con un proprio livello di permesso dedicato e distinto da quello di utilizzo.
Un sistema che confonde questi due livelli – permettendo a chiunque abbia accesso a una griglia di creare anche nuove azioni automatizzate – espone un rischio operativo reale: un’automazione configurata male, magari con un filtro troppo ampio o un’azione distruttiva non intenzionale, può propagare un errore su una scala molto più ampia di quanto farebbe un errore umano in una modifica singola.
Che differenza fa questo approccio per la ditta esterna o il global service, che spesso opera con permessi più limitati del cliente proprietario?
Un fornitore esterno lavora tipicamente con un sottoinsieme di permessi definito dal proprietario o dal building manager, e un sistema che applica coerentemente i controlli di permesso anche alle operazioni di massa garantisce che quel sottoinsieme resti effettivamente rispettato, anche quando il fornitore usa strumenti potenti come l’aggiornamento massivo o le catene di automazione. È una garanzia che rafforza la fiducia reciproca nel rapporto contrattuale: il cliente sa che il fornitore non può, nemmeno per errore, superare i confini dei permessi assegnati semplicemente perché sta usando una funzionalità più potente della modifica singola.
Conclusioni
Le funzionalità che rendono un sistema informativo per il FM davvero produttivo – aggiornamenti di massa, catene di automazione configurabili senza codice – sono le stesse che, senza una governance progettata con attenzione fin dall’architettura, possono trasformarsi in un rischio esteso invece che in un vantaggio. Permessi granulari sempre applicati, catene di azioni deliberatamente semplici e leggibili, audit trail immutabile e separazione netta tra chi usa e chi configura sono gli ingredienti tecnici che rendono la potenza compatibile con il controllo. Con questo si chiude il capitolo dedicato alla piattaforma dati universale: nei prossimi articoli entriamo nel cuore del ciclo di vita della manutenzione, a partire da come si pianificano interventi su interi gruppi di asset invece che uno a uno.
Se vuoi un supporto qualificato sull’argomento puoi contattarmi qui