Un programma di automazione fallisce raramente a causa dell'inadeguatezza della piattaforma. Il fallimento è dovuto a dati sottostanti incompleti, incoerenti, inaccessibili o scollegati dal processo che dovrebbero supportare. Questa guida alla preparazione dei dati aziendali è pensata per i leader che devono trasformare dati operativi sparsi in una base affidabile per l'automazione, l'analisi e l'intelligenza artificiale.
Per le organizzazioni fortemente orientate alle operazioni, la preparazione dei dati non è un'attività di pulizia IT, bensì un requisito fondamentale per l'esecuzione aziendale. Se un team di assistenza utilizza identificativi cliente diversi nei vari sistemi, se le eccezioni relative alle fatture vengono classificate in modo differente a seconda della regione o se le fasi critiche del processo risiedono nelle caselle di posta elettronica, l'automazione riprodurrà l'incoerenza con maggiore rapidità. L'intelligenza artificiale fornirà raccomandazioni basate su contesti incerti. Le dashboard genereranno dibattiti anziché indicazioni.
L'obiettivo non è avere dati perfetti in ogni sistema. L'obiettivo è avere dati adeguati allo scopo, che supportino un risultato aziendale definito, con responsabilità chiare e controlli scalabili.
Iniziate dal processo, non dall'inventario dei dati
Molti programmi di gestione dei dati iniziano catalogando ogni database, applicazione, campo e report. Questo lavoro è utile, ma può trasformarsi in una documentazione costosa senza alcun effetto operativo. Un punto di partenza più efficace è il processo in cui le prestazioni contano maggiormente.
Scegliete un processo con un volume di transazioni significativo, un certo impegno manuale, costi elevati, rischi consistenti o un impatto rilevante sul cliente. Esempi comuni sono il ciclo ordine-incasso, il ciclo acquisto-pagamento, la gestione dei reclami, l'assegnazione dei servizi e l'inserimento dei nuovi dipendenti. Successivamente, mappate il flusso di lavoro effettivo tra persone, sistemi, decisioni ed eccezioni. La differenza tra il processo progettato e quello reale è solitamente il punto in cui emergono i problemi relativi ai dati.
Ad esempio, un team addetto alla contabilità fornitori potrebbe apparentemente avere un l'automazione della fatturazione . Un'analisi più approfondita potrebbe rivelare la mancanza di riferimenti agli ordini di acquisto, la duplicazione dei dati anagrafici dei fornitori e la gestione differente dei limiti di approvazione tra le diverse unità aziendali. L'acquisto di uno strumento di acquisizione più potente non risolverà questi problemi. L'azienda necessita di una corretta progettazione dei processi e di regole di dati affidabili prima di poter automatizzare la gestione delle eccezioni su larga scala.
Questo approccio incentrato sul processo crea anche un confine pratico per l'iniziativa. Invece di chiedersi "I nostri dati aziendali sono pronti?", i leader possono chiedersi "I dati necessari per automatizzare e misurare questo processo sono pronti?". Questa domanda è più concreta e più facile da finanziare.
Le quattro condizioni di prontezza dei dati
La disponibilità dei dati si basa su quattro condizioni interconnesse. Una debolezza in una di esse può limitare il valore delle altre.
- Qualità: I dati richiesti sono accurati, completi, tempestivi e sufficientemente coerenti per la decisione o l'azione automatizzata prevista.
- Contesto: definizioni aziendali, stato dei processi, relazioni e significato storico sono disponibili affinché utenti e sistemi possano interpretare correttamente i dati.
- Accesso: gli utenti, le applicazioni e i componenti di automazione autorizzati possono ottenere i dati necessari in modo affidabile, senza esportazioni manuali o soluzioni alternative complesse.
- Controllo: la proprietà, la sicurezza, la conservazione, la verificabilità e la gestione delle modifiche sono definite e applicate nelle operazioni quotidiane.
Spesso la qualità viene considerata l'unico problema, ma la sola presenza di valori corretti non basta. Un record cliente può essere accurato ma comunque inutilizzabile se nessuno è in grado di determinare quale gerarchia di account si applica a una decisione di prezzo. Allo stesso modo, i dati accessibili non sono pronti se l'accesso elude gli obblighi di privacy o se una modifica dello schema può compromettere silenziosamente un bot critico per l'azienda.
Il livello di preparazione adeguato dipende dal caso d'uso. Una dashboard di gestione può tollerare un ciclo di aggiornamento giornaliero e un volume ridotto di record non categorizzati. Lo sblocco di un credito o un flusso di lavoro relativo alla sicurezza possono richiedere dati quasi in tempo reale, una convalida molto più rigorosa e una traccia di controllo completa. Gli standard di preparazione dovrebbero riflettere il costo di una decisione errata, non un punteggio aziendale generico.
Creare una baseline di preparazione dei dati di proprietà aziendale
Una baseline trasforma le problematiche generali in una visione di rischio, impegno e valore pronta per il processo decisionale. Dovrebbe essere sviluppata congiuntamente dai team operativi, dei dati, IT, di gestione del rischio e dai responsabili dei processi. I team dei dati comprendono le strutture e i vincoli di integrazione; i responsabili dei processi comprendono dove un valore errato o mancante crea rilavorazioni, ritardi o rischi di non conformità.
Iniziate con gli oggetti dati critici per il processo di destinazione. Questi potrebbero includere record relativi a fornitori, clienti, prodotti, contratti, dipendenti, cespiti, ordini, fatture o casi. Per ogni oggetto, documentate la fonte del record, i sistemi che lo utilizzano, i campi chiave necessari per le decisioni e il responsabile della sua definizione aziendale.
In seguito, misurate le condizioni reali. Evitate di basarvi solo sulla percezione degli stakeholder. Quantificate i tassi di duplicazione, i tassi di campi mancanti, i valori contrastanti, gli aggiornamenti tardivi, i volumi di interfacce non riuscite e le correzioni manuali. Esaminate un insieme rappresentativo di eccezioni, non solo le medie aggregate. Un tasso di completamento del 98% può sembrare accettabile finché il 2% mancante non rappresenta gli ordini di maggior valore o i casi che richiedono una revisione normativa.
La definizione di base dovrebbe collegare ogni problema a una conseguenza operativa. "La qualità degli indirizzi dei clienti è scarsa" è un'affermazione vaga. "Il dodici percento degli appuntamenti di assistenza richiede la verifica manuale dell'indirizzo, il che aggiunge sei minuti per ogni intervento e aumenta il rischio di mancate visite" fornisce alla dirigenza una base per stabilire le priorità.
Stabilire la responsabilità laddove vengono prese le decisioni
La governance dei dati aziendali spesso fallisce quando si configura come un comitato centrale che pubblica le politiche ma non può influenzare il lavoro quotidiano. Una governance efficace assegna le responsabilità in prossimità dei processi, mantenendo al contempo gli standard aziendali in materia di sicurezza, architettura e conformità.
Il responsabile di un processo deve essere chiamato a rispondere dei risultati aziendali e dei requisiti di dati necessari per raggiungerli. I responsabili dei dati devono definire le regole di utilizzo e approvare le modifiche sostanziali alle definizioni critiche. I responsabili della gestione dei dati devono monitorare la qualità, risolvere i problemi ricorrenti e coordinare le azioni correttive tra i team. I team IT e di architettura devono fornire modelli di integrazione affidabili, gestione delle identità, osservabilità e controlli del ciclo di vita.
La distinzione è fondamentale. Un responsabile può correggere un record fornitore duplicato, ma il responsabile del processo deve intervenire sul flusso di lavoro o sull'incentivo che ha permesso la creazione del fornitore duplicato. Senza questa disciplina che affronti la causa principale, la correzione si trasforma in una manutenzione manuale permanente.
La governance dovrebbe anche definire chi può modificare un termine aziendale. Si consideri, ad esempio, la "consegna puntuale". Un team potrebbe calcolarla a partire dalla data di spedizione promessa, un altro dalla data di consegna richiesta e un terzo dalla data finale confermata. Ogni calcolo può essere ragionevole per uno scopo specifico, ma non tutti possono supportare la stessa affermazione relativa alle prestazioni aziendali. Una definizione governata non elimina le variazioni legittime, ma le rende esplicite, controllate e visibili.
Progettare un'architettura che privilegi i dati utilizzabili, non la massima centralizzazione
Centralizzare tutti i set di dati in un'unica piattaforma non è automaticamente la soluzione. Può comportare costi aggiuntivi, latenza e rischi di migrazione senza migliorare il processo. La scelta dell'architettura dipende dal volume dei dati, dai requisiti di velocità, dai vincoli normativi, dai sistemi esistenti e dai casi d'uso prioritari.
Ciò che conta è che i dati critici possano essere connessi, compresi e gestiti nell'intero panorama operativo. Questo può includere API, flussi di eventi, una piattaforma dati, la gestione dei dati anagrafici, il process mining o livelli di integrazione mirati. Il mix tecnologico dovrebbe ridurre i passaggi manuali e rendere tracciabile la provenienza delle decisioni importanti.
Nell'ambito dell'automazione, è fondamentale distinguere tra dati che devono essere letti, dati che possono essere modificati e dati che devono essere conservati come prova. Un'automazione che aggiorna lo stato di un pagamento richiede un accesso in scrittura controllato e una gestione affidabile delle eccezioni. Una dashboard direzionale potrebbe invece necessitare solo di accesso in lettura ai dati aggregati. Trattare entrambi i casi allo stesso modo crea rischi inutili o rallenta la consegna.
L'intelligenza artificiale introduce un ulteriore requisito architetturale: il recupero e il contesto. Un assistente IA generativo non può fornire indicazioni operative affidabili a partire da documenti scollegati, procedure obsolete ed estratti di dati non regolamentati. Prima di implementare l'IA, è necessario stabilire quali fonti siano autorevoli, come vengano aggiornati i contenuti, quali informazioni sensibili debbano essere protette e quando sia richiesta l'approvazione umana.
Dare priorità agli interventi di bonifica in base al valore aziendale
La correzione dei dati può trasformarsi in un programma a tempo indeterminato, a meno che i responsabili non la classifichino in base a risultati misurabili. Classifica i problemi in base al loro impatto su tempi di ciclo, costi, protezione dei ricavi, esperienza del cliente, conformità e fattibilità dell'automazione. Quindi crea una sequenza di implementazione che produca vantaggi operativi e al contempo migliori le basi per i casi d'uso futuri.
Le soluzioni rapide possono essere utili. Standardizzare un campo obbligatorio, correggere una regola di convalida o eliminare il passaggio di dati da un foglio di calcolo può generare valore in tempi brevi. Tuttavia, non bisogna confondere una soluzione rapida con una soluzione duratura. Se lo stesso errore di dati si ripresenta ogni mese, è necessario indagare sul flusso di lavoro che lo ha generato, sull'integrazione, sulla mancanza di formazione o su un errore di gestione.
Un utile backlog di trasformazione include il problema di processo, la dipendenza dai dati, la metrica di riferimento, il responsabile, la modifica tecnica e il controllo previsto. Questo mantiene il lavoro sui dati connesso alla consegna. Rende inoltre visibili i compromessi: una complessa riprogettazione dei dati master può essere giustificata per un processo globale, mentre un'integrazione più mirata può essere la scelta migliore per un'automazione locale con tempistiche ristrette.
Dimostra la prontezza prima di espandere
Prima di estendere la soluzione a regioni, unità aziendali o processi aggiuntivi, è opportuno eseguire un progetto pilota di produzione controllato. È importante misurare non solo il tempo di attività tecnico, ma anche i tassi di eccezione, l'elaborazione automatizzata, il tempo di intervento manuale, l'accuratezza delle decisioni, le rilavorazioni, l'adozione da parte degli utenti e la qualità della traccia di controllo.
Il progetto pilota dovrebbe testare le condizioni di errore con la stessa accuratezza con cui si testa il caso normale. Cosa succede quando un campo obbligatorio è vuoto, un sistema di origine non è disponibile, una soglia di approvazione cambia o un suggerimento dell'IA è in conflitto con le policy? Una soluzione che gestisce le transazioni normali ma fallisce in modo imprevedibile in caso di eccezioni non farà altro che spostare il lavoro anziché eliminarlo.
In Ective, questo è il motivo per cui il lavoro di trasformazione inizia con la disciplina dei processi e dei dati prima di estendere l'automazione. L'obiettivo non è una raccolta di progetti pilota di successo, bensì un modello operativo in cui flussi di lavoro, informazioni, controlli e indicatori di performance si rafforzano a vicenda.
La preparazione dei dati non è mai una certificazione una tantum. I modelli di business cambiano, i sistemi si evolvono e i nuovi casi d'uso dell'automazione introducono nuove dipendenze. L'obiettivo pratico è rendere la preparazione misurabile e ripetibile: migliorare il processo, definire i dati necessari al processo, controllarli alla fonte e utilizzare i dati sulle prestazioni per decidere cosa scalare in seguito.
