Da quando il mondo è mondo, tutte le attività umane, dalla caccia al bisonte alla gestione di una “dot-com”, si svolgono in base ai dati in possesso o a conoscenza degli attori. Il binomio dati-attività (dati-business, se volete) è inscindibile ed è in relazione bidirezionale: come i dati generano azioni, così queste generano dati. E sommando azioni ad azioni e dati a dati si crea quel ciclo autoalimentato che conosciamo bene e il cui governo è nello stesso tempo il sogno e l’incubo sia dei responsabili del business sia, soprattutto, dei responsabili dell’It.
È da tempo che il miglioramento della qualità dei dati e della qualità dei processi aziendali è tra gli obiettivi prioritari dei Cio, ma la relazione tra dati e processi non sembra ancora essere ben compresa nella sua importanza né tradotta in pratica operativa. Il risultato è che le iniziative poste in atto per migliorare il governo dei processi e dei dati non sono né allineate nei programmi né coordinate nell’esecuzione. Molte aziende lanciano progetti di Master Data Management (Mdm) per riordinare e consolidare il crescente volume di dati in entrata e fornire informazioni corrette e contestualizzate al business. E molte di queste stesse aziende attuano iniziative di Business Process Management (Bpm) per migliorare i processi vitali per il funzionamento e la competitività dell’impresa. Ma questi sforzi restano sovente circoscritti ai rispettivi ambiti di competenza e responsabilità e tra chi pensa al Bpm e chi si occupa di Mdm la collaborazione, quando c’è, è limitata e scarsamente coordinata. Con un intuibile spreco di risorse umane ed economiche, nel migliore dei casi; e il rischio che entrambi i progetti possano fallire in quello peggiore.
In realtà, il fatto che il valore che un qualsiasi sistema informativo può dare al business dipenda strettamente dalla qualità del flusso di dati che lo attraversa è sempre stato chiaro ai responsabili It. E negli ultimi anni questa percezione ha portato al superamento di una visione dell’It focalizzata sui sistemi (e di conseguenza verticalizzata per applicazioni) a favore di una visione data-centrica, focalizzata su un utilizzo trasversale rispetto ai singoli processi di business di dati relativi a dominii critici (tipo: clienti, addetti, finanze, prodotti e così via). Questo approccio è il punto di partenza per attuare un programma di Data governance, ossia, un programma che definisca e formalizzi tutte le attività volte a garantire un costante e corretto trattamento dei dati rilevanti per l’organizzazione; che ne consideri tutti i parametri di qualità e che, cosa importante, copra tutta l’impresa. Ma proprio in quanto basato su una visione globale dell’impresa e dei suoi processi di business, un tale programma va inevitabilmente a interferire con chi di questi processi è responsabile e detentore.
I freni alla Data governance
Le cause che maggiormente frenano lo sviluppo della Data governance in azienda sono, sostanzialmente, tre. La prima è quella di sempre: la scarsa collaborazione tra business e It che deriva dall’avere cultura, visione e linguaggio diversi. Pertanto, succede che gli uomini del business siano portati a credere che la qualità dei dati sia un problema dell’It e che tocchi quindi all’It risolverlo (il che non ha senso perché è proprio il business manager la persona in grado di capire più di chiunque altro l’effetto che i dati scadenti hanno sui processi di cui è responsabile); mentre gli uomini dell’It sono portati a credere che se una certa soluzione viene sviluppata a regola d’arte, prima o poi sarà adottata. Il che non è affatto detto, come dimostra il fallimento di molti progetti di Data warehouse a causa della mancata fiducia da parte di coloro cui sono destinati.
Il secondo elemento frenante sta nel fatto che anche in un’organizzazione dalla visione data-centrica la gestione coerente della massa dei dati aziendali è difficile. Per esempio: ammettiamo che business e It siano perfettamente d’accordo sull’importanza di conoscere i clienti e decidano quindi di sostenere una strategia centrata su tali dati. Ma in un’azienda (specie se multinazionale e di una certa complessità) i sistemi che catturano, aggiornano, forniscono o utilizzano dati sui clienti sono molti e al servizio di processi diversi. Spesso i progetti nascono focalizzandosi sull’uso ‘a valle’ dei dati, ad esempio per analisi di BI, ma così facendo si ignorano i processi che stanno a monte dei dati analizzati (tipo gestione ordini, servizio clienti e così via), con tutti i problemi che possono avere. Se non si considera l’intero ciclo di vita del dato, dalla cattura all’utilizzo, si rischia di cadere nella legge “garbage in, garbage out” [se immetti errori ottieni errori ndr] e il fallimento è sicuro.
Infine c’è la tendenza, da parte dell’It, di sovrastimare l’efficacia degli strumenti per la pulizia dei dati, come quelli compresi nelle soluzioni di Mdm o nelle piattaforme analitiche. Questi strumenti possono avere effettivamente un ruolo critico in un’architettura globale di Data management, ma c’è il rischio di credere che grazie ad essi tutti i dati “sporchi” (incorretti, incompleti, inconsistenti, non aggiornati…) si possano pulire “a posteriori”, cioè a valle degli eventi o dei processi che li hanno resi tali. In altre parole, si vede il dato scadente come il male da curare invece che come il sintomo della malattia, che è la qualità dei processi di business da cui viene estratto. Ciò è noto ai responsabili dei progetti di Data warehousing e BI, che però, non potendo intervenire su processi di cui non sono “proprietari” né responsabili, ricorrono alle soluzioni di cui si è detto come il mezzo di correzione meno intrusivo di cui possono disporre.
Per far decollare un programma di Data governance in modo da avere i risultati e il ritorno d’investimento attesi, bisogna spostare l’obiettivo degli sforzi sulle cause piuttosto che sugli effetti, concentrandosi sui processi operativi e decisionali dal cui funzionamento deriva il maggior valore per l’impresa. Infatti, anche supponendo che si possano per altre vie ottenere dati di qualità e sui quali poter fare affidamento, perché questo capitale si trasformi in fattore di riduzione del rischio e d’incremento di competitività bisogna che venga convenientemente sfruttato nei processi aziendali. Ed ecco che si torna ai processi di business e alla loro gestione e riordinamento.
Governo di processi, governo di dati
Le iniziative di Bpm che nascono attorno a un progetto specifico (per esempio: un sistema di Crm), di solito non si focalizzano troppo sulla qualità dei dati. L’attenzione nasce quando si affrontano processi end-to-end che coinvolgono più funzioni aziendali. A questo punto ci si accorge che trattare dati non consolidati e sincronizzati crea problemi tali di incongruenza, ridondanza, inconsistenza e altro ancora da rendere il Bpm di fatto irrealizzabile. Ciò deriva anche dal fatto che (come emerge da interviste effettuate da Forrester a utenti e fornitori), molti analisti di processo non hanno le competenze necessarie per risolvere i problemi di data quality e non sono adeguatamente supportati dalla tecnologia. Nel senso che, secondo Forrester, gli strumenti per la definizione dei dati forniti dalle suite di Bpm sono rivolti agli sviluppatori e risultano troppo complessi da usare per un analista che deve modellare le relazioni tra i dati di processi diversi nel corso dell’esame preliminare dei processi stessi.
Per allineare il governo dei processi (che, secondo Forrester, “descrive in generale le regole e gli standard per selezionare, prioritizzare e generare i miglioramenti dei processi di tutta l’impresa”) al governo delle informazioni, la prima cosa da fare è cogliere le differenze e le similitudini tra le due attività. Tenendo presente che entrambe richiedono: 1) il sostegno e il coinvolgimento di tutti i dirigenti affinché l’attenzione sia effettivamente focalizzata su tutta l’impresa; 2) uomini di business esperti in tecnologie e uomini It esperti in business, per superare le incomprensioni tra i due mondi; 3) un “promotore” (strategy driver) capace di coordinare tutte le risorse, di spingerle verso un comune obiettivo e di misurare il successo del programma in atto. Questa rete di relazioni è rappresentata nello schema di figura 1, che oltre al già citato strategy driver colloca nelle posizioni cui sono destinate le diverse figure (business steward e It steward) incaricate di elaborare e di gestire secondo le rispettive competenze le istanze tra business e It.
Da quanto abbiamo fino a qui esposto, si capisce come la realizzazione di una strategia di allineamento tra dati e processi di business sia essenzialmente un problema di ruoli e figure professionali, cioè di persone e di modo di lavorare. Non bisogna però affatto credere che si debbano creare nuovi gruppi di lavoro all’interno dell’It e delle business unit, e nemmeno che si debba introdurre un nuovo strato organizzativo con poteri di controllo e decisione. Queste cose, oltre ovviamente ad essere praticamente irrealizzabili per i costi derivanti dal reperimento di nuove risorse e dal loro inserimento nell’impresa, avrebbero l’unico effetto di appesantire e rallentare ogni iniziativa di Bpm e di Master data management, che è il passo fondamentale di un piano di Data governance. Ciò che invece bisogna fare è sincronizzare l’esecuzione dei compiti relativi al governo dei dati e dei processi in modo che siano in grado di sostenersi a vicenda.
Nei progetti di Bpm e Mdm vi sono infatti attività in parte similari e sovrapponibili. Si tratta di sfruttare queste sovrapposizioni per ottenere, senza bisogno né di nuovi ruoli né di compiti addizionali, quel coordinamento che andiamo cercando. È un lavoro delicato e che va svolto in collaborazione tra It e business, ma si può certamente fare. Nell’articolo di pagina 40 vedremo come si debba praticamente procedere e, soprattutto, come i fornitori di tecnologia possano, con le proprie soluzioni di Mdm e Data quality, sostenere questo processo.
Figura 1 – Governo dei processi e gestione dei dati
Leggi anche "Verso una visione unica della realtà"
