Business Intelligence: cinque best practice per un data model

Una delle esigenze maggiormente sentite dalle aziende in crescita è identificare degli indicatori che aiutino il management a individuare pratiche poco performanti e ad ottimizzare i processi aziendali. Nell’intraprendere un progetto di Business Intelligence, sia che si operi internamente con il proprio IT o con l’aiuto di consulenti esterni, è necessario avere ben chiare delle linee guida che impediscano al progetto di diventare dispersivo o di adottare strategie inefficaci.
Ci possono essere diverse cause che conducono al degradarsi di un progetto BI. Queste possono essere di natura tecnologica, ossia legate più agli aspetti IT del progetto, ma anche di natura umana, analitica e funzionale. Le più comuni possono essere indicate nei punti seguenti:

1. Scelta errata del software
2. Errata stima del carico dei batch computazionali
3. Mancata individuazione dei KPI salienti per il proprio business
4. Errata analisi dei Dataset
5. Conflitti con l’ambiente software

Scelta del software

Parlando del criterio di scelta di un software BI, non intendiamo concentrarci su una valutazione tecnologica dei software potenzialmente candidati, ma sulle attitudini delle persone che, in azienda, impiegheranno questo software. Si tratta di power user tecnologici oppure di utenti tradizionali? La BI, in azienda, sarà una responsabilità prevalentemente del reparto IT, della contabilità, oppure sarà trasversale a più reparti? La best practice in questo caso è di partire non dal software, ma dai propri utenti, e scegliere una soluzione che permetta alle persone di esprimere al meglio le proprie skill, invece di una piattaforma che obblighi l’utente a snaturare la propria identità.
La scelta dovrebbe cadere su un software flessibile, con una chiara distinzione tra la parte di progettazione dei Dataset (quella più tecnica, che richiede maggiori competenze informatiche e di database), e la parte di fruizione tramite Viste e Report (l’aspetto solitamente più orientato verso l’utilizzatore finale).

Stima dei carichi computazionali

Un aspetto da non sottovalutare in fase di analisi, è la corretta stima dei carichi di lavoro a cui i server saranno sottoposti dal nuovo software BI, che aumenterà in modo non banale lo stress sulla CPU e la saturazione della RAM. Occorre, per prima cosa, stimare se sia più appropriato un accesso in tempo reale alle sorgenti dati, oppure se sia da configurare un workflow schedulato di popolamento e aggiornamento del Data Model.

Bisogna anche chiedersi se il nostro Data Model andrà a interrogare solo un database SQL, il tipico “silos” dei gestionali italiani, oppure se sarà più articolato e dovrà accedere a più tipi di sorgenti dati contemporaneamente, come file Excel, o database di diverso tipo. In questo secondo caso si potrebbe valutare l’impiego dei cubi OLAP, ossia un oggetto ottimizzato per aggregare informazioni da origini dati diverse. Occorre tenere presente che il cubo OLAP offre un’ottima flessibilità di manipolazione, ma, come controparte, non permette un’interrogazione in tempo reale dei dati, ma solo tramite snapshot pianificate. Superfluo specificare che queste snapshot sono processi il cui carico di elaborazione può saturare facilmente CPU e RAM di server non equipaggiati a dovere, rischiando di fare sforare il budget inizialmente stimato con impegnativi upgrade hardware.

Individuazione dei KPI salienti

Altra best practice è che l’analisi dei KPI sia un processo trasversale, ossia un tavolo attorno a cui si riuniscano per discutere tutti i key user interessati, indipendentemente dal reparto di appartenenza. Infatti, per individuare i KPI, è necessaria una corposa fase di esame dei processi aziendali e di raccolta informazioni, ossia di dialogo tra le diverse controparti aziendali.

La definizione di un KPI non deve essere intesa come un’operazione esclusivamente tecnologica, da delegare al data scientist, magari un consulente esterno, guru del software BI che ci aiuta a mettere in pista, ma non informato a sufficienza sulle specificità delle nostre dinamiche aziendali. Un KPI è lo specchio di una parte della nostra azienda, per cui nessuno meglio delle persone che ci lavorano ogni giorno può contribuire alla sua definizione.

Analisi del Dataset

I Dataset costituiscono gli insiemi di dati, specializzati per ambito gestionale (ciclo attivo, contabilità, ecc.) su cui verranno costruite le viste impiegate dagli utenti per le analisi quotidiane. I Dataset devono essere organizzati in modo da offrire tutte le informazioni necessarie ad analizzare un processo, ma senza cadere nella ridondanza.

Dataset troppo complessi diventano difficili da navigare per l’utente, e l’inclusione di informazioni superflue non solo crea confusione durante la progettazione delle viste, ma rallenta le prestazioni del software, sia durante gli aggiornamenti schedulati, sia durante l’operatività di routine.

Ambiente software

Un software BI, solitamente, è un programma che vive per lo più in una sua sandbox, su cloud o su un server dedicato della LAN aziendale. Questo non significa che non possa presentare punti di contatto con l’infrastruttura informatica, anche con delle criticità.
Uno di questi punti di contatto da verificare con una certa scrupolosità è se il software di BI vada a creare dei trigger sulle tabelle SQL già esistenti. Certi software BI, infatti, configurano dei trigger sulle tabelle incluse nei Dataset per poter pilotare aggiornamenti di tipo differenziale. Questa è una pratica diffusa soprattutto nel caso vengano impiegati i cubi OLAP. Bisogna perciò verificare che eventuali aggiornamenti del gestionale o dei software proprietari di quelle base dati non cancellino o corrompano questi trigger, senza i quali gli aggiornamenti dei Dataset della BI potrebbero fallire.