Power BI, Tableau e CdG: il problema non è lo strumento, ma la mancanza di un'analisi SQL a monte della B.I.

La Business Intelligence "out-of-the-box" non fa Controllo di Gestione. Ecco perché è necessario un intervento di analisi e preparazione del dato (SQL) a monte delle dashboard.

Oggi il mercato propone un binomio quasi inscindibile: Controllo di Gestione = Business Intelligence (BI) entry level. Strumenti anche potenti come Power BI (o Tableau) sono spesso venduti come la soluzione definitiva per l'analisi aziendale. Ma siete sicuri che basti acquistare la licenza e collegare il vostro gestionale per ottenere report affidabili e predittivi?

La realtà è che la Business Intelligence senza un'adeguata preparazione dei dati a monte è purtroppo inefficace. Spesso si vanno ad utilizzare strumenti pensati principalmente per la fase finale del processo (la graficizzazione) per un lavoro di analisi incrociata che richiede invece strumenti differenti. Se il dato sorgente è disorganizzato, incompleto o non elaborato in maniera incrociata in base al progetto personalizzato del controllo di gestione (CdG), la dashboard finale sarà solo un bel grafico con informazioni parziali ed incomplete, se non addirittura errate (un vero e proprio CdG "finto", come discusso in Margine di ricarico e di contribuzione inaffidabile ).

Occorre quindi ribaltare la prospettiva: la vera sfida è il Data Modeling che alimenta (o dovrebbe alimentare) software come Power BI ed altri (Tableau, Metabase, ma anche altri sistemi di reportistica avanzata). Il CdG si compone infatti di una pluralità di processi ed il focus deve sempre essere sul dato, prima che sulla sua mera rappresentazione grafica. E per dirla tutta il CdG non è una novità di questi ultimi anni, tanto che le grandi aziende l'hanno sempre implementato, anche ai tempi delle schede perforate e poi dell'AS/400, semplicemente lavorando su tabulati di dati.

   

Oggi da un lato il mercato è molto più dinamico e complesso, e questo richiede che anche le PMI impostino un sistema di controllo di gestione, se vogliono sopravvivere in un contesto in cui anche il minimo errore può essere fatale; dall'altro la disponibilità quasi infinita di software di Business Intelligence "out-of-the-box" (pronti all'uso) consente di impostare il CdG in modo più flessibile, curato e comprensibile anche per "non addetti ai lavori".

Tuttavia bisogna fare molta attenzione a non farsi prendere dall'eccessiva semplificazione, dimenticando che i dati vanno verificati, elaborati, incrociati ed analizzati prima via SQL e poi se necessario con strumenti avanzati di Machine Learning, prima di pensare alla visualizzazione e quindi alle dashboard, che rappresentano l'ultimo step di un lavoro che si articola su più livelli.

---

Perché la Business Intelligence "out-of-the-box" non funziona per il CdG

Dati non verificati, informazioni non incrociate, report sbagliati: il controsenso dell'approccio standard

Gli strumenti come Power BI e Tableau sono eccellenti nella visualizzazione dei dati, ma non nella loro meticolosa preparazione e riclassificazione. Il processo standard si scontra con la realtà delle PMI, dove i dati nel gestionale sono aihmé spesso incompleti o non sufficientemente strutturati per l'analisi finanziaria e operativa.

Sebbene Power BI e Tableau possano connettersi direttamente ad alcuni database, l'utilizzo comune nelle PMI basato su esportazioni intermedie (CSV/Excel) limita drasticamente questa possibilità, oltre al fatto che per lavorare correttamente lato server sarebbe fondamentale creare viste o stored procedure SQL direttamente sul database da utilizzare per le elaborazioni.

È vero che questi software presentano anche funzionalità avanzate (ad esempio Power BI supporta il linguaggio M per la gestione dei dati ed il linguaggio DAX per la graficizzazione), ma purtroppo non sono in grado di sostituire nella stessa maniera un lavoro di elaborazione effettuato prima sul server via SQL e poi eventualmente a valle con strumenti potentissimi come Python, Pandas, KMeans/Sklearn solo per citarne alcuni.

E poi, obiettivamente, che senso ha investire tempo per imparere linguaggi specifici di singoli sistemi invece che linguaggi universali che hanno una potenzialità enormemente superiore?

Ecco alcuni dei limiti che si incontrano utilizzando solo soluzioni di B.I. "out-of-the-box" senza prima intervenire sull'analisi dati via SQL.

• Fonti di input: Le connessioni standard supportate spesso non permettono di gestire dati provenienti da fonti diverse (poche tipologie di databases supportati, spesso vengono utilizzati con elaborazioni già pronte del software gestionale in formato CSV per la mera graficizzazione).
• Rigidità: Diventa complesso o impossibile gestire analisi ed elaborazioni complesse ed incrociate di dati.
• Limiti dimensionali: Quando si lavora su fonti dati in formato CSV le elaborazioni avvengono in locale su database, per qualche decina di migliaia di records non ci sono problemi, ma all'aumentare della mole di dati diventa complesso o addirittura non possibile quanto occorre lavorare su milioni o decine di milioni di records.
• Integrità referenziale: I dati vengono letti ed elaborati per quanto possibile, senza una verifica dell'integrità referenziale e di eventuali "buchi" nelle codifiche.
• Linguaggio di nicchia: Per elaborazioni sofisticate all'interno di Power BI, è necessario imparare linguaggi proprietari (DAX o M-Code) che hanno un'utilità assai limitata per altri compiti (al di fuori dell'ecosistema Microsoft).

Per questo motivo, la maggior parte dei progetti di BI si ferma alla visualizzazione di semplici dati di gestione, partendo da elaborazioni aggragate e già disponibili sul software gestionale, in pratica fornendo solo la graficizzazione del dato, e risultando quindi insufficiente per un CdG serio e strategico.

   

Data Modeling e SQL: la base solida per report attendibili

La necessità di pulizia e riclassificazione a monte

Il vero valore aggiunto nel CdG è dato dalla verifica, dalla riclassificazione e dall'aggregazione anche incrociata del dato sorgente, un processo che va implementato a monte via SQL (anche creando viste e stored procedures personalizzate), e quindi prima che il dato arrivi a Power BI o Tableau o ad altri strumenti di graficizzazione. Questo processo, chiamato Data Modeling , richiede naturalmente delle ottime competenze in informatica gestionale, ma è l'unico che consente di modellare un sistema di CdG in maniera efficiente:

1. Definizione delle logiche CdG: Si stabiliscono gli obiettivi del CdG e di conseguenza le elaborazioni necessarie, ad esempio per supportare il calcolo avanzato del Margine di Contribuzione reale o del costing per commessa , oppure per monitorare la liquidità e la tesoreria, solo per fare un esempio.
2. Linguaggio universale SQL: Utilizzo di SQL (Structured Query Language) per estrarre, trasformare ed incrociare i dati (ETL) su un Data Warehouse separato. L'SQL è un linguaggio standard, potentissimo ed utilizzato da quasi tutti i database esistenti.
3. Python per analisi avanzate: Con i dati correttamente elaborati ed aggregati lato server via SQL, è possibile aggiungere un ulteriore livello di analisi avanzata con strumenti potentissimi basati su Python / Pandas / KMeans che consentono di gestire operazioni anche molto complesse e di Machine Learning (ML).
4. Qualità e tempestività: Si verifica che il dato sia affidabile ed aggiornato , due requisiti che la sola Business Intelligence "out-of-the-box" non può garantire.
5. Storico: La gestione su un potente database SQL consente di memorizzare tutto lo storico aziendale, per effettuare elaborazioni illimitate e non solo riferite al dataset importato al momento.
6. Esportazione: Oltre che per la graficizzazione, tutti i dati sono esportabili per ulteriori elaborazioni, analisi e finiture all'interno dell'azienda.

Solo un dato meticolosamente preparato attraverso il Data Modeling può quindi generare report di BI che siano veri strumenti di CdG strategico, e non solo una riorganizzazione estetica di dati già disponibili.

   

Flessibilità: la scelta di strumenti e linguaggi avanzati (SQL/Python)

Investire in strumenti (SQL/Python) universali, non in software vincolanti

Ogni azienda dovrebbe investire in soluzioni che offrano flessibilità e universalità. Per questo l'approccio che normalmente propongo si basa su strumenti e linguaggi universali:

• SQL: Linguaggio universale (con possibilità di gestire queries, viste e stored procedures) per l'elaborazione ed aggregazione dei dati lato server.
• Python: Ideale per elaborazioni statistiche, Machine Learning o manipolazioni di dati molto complesse, operazioni che non hanno senso essere delegate ai micro-linguaggi dei software di B.I.. Python è inoltre utilizzabile in mille altri contesti (Web, Automazione, Data Science), offrendo un'enorme scalabilità sull'investimento, rispetto a linguaggi proprietari di nicchia.
• Reportistica: L'uso degli strumenti "tradizionali" di B.I. come Power BI o Tableau è una mera eventualità, che può essere sostituita da altre soluzioni anche open source di graficizzazione, per costruire dashboard e KPI personalizzati, che in ogni caso rappresentano solo l'ultimo miglio di un lavoro complesso ed articolato, ossia la visualizzazione del dato finale.

Un aspetto molto interessante è che questi lavori estremamente avanzati di analisi si possono effettuare anche integrandosi con software gestionali datati di vecchia concezione, importando i dati su potenti RDBMS e da lì gestendo il flusso di lavoro completo (SQL / Python / SQLite) fino alla visualizzazione finale dei dati finiti.

In questo modo il vostro controllo di gestione è robusto, scalabile ed indipendente dalle mode software. La vostra strategia è finalmente indipendente da uno specifico strumento, poiché la base dati è stata impostata correttamente a monte.

Inizio pagina