Come comportarsi nel caso in cui l’IT del cliente non permette di collegarsi al database sottostante il gestionale del cliente o non sia possibile farlo per qualche ragione di politiche IT o perché i dati non sono su un database?
– Situazione 1: database senza accessi diretti
– Situazione 2: database secretato per motivi strategici
– Situazione 3: i dati NON sono su un database.
Luca, il nostro ipotetico consulente, ha elaborato una strategia precisa per la promozione dei nuovi servizi che il suo studio vuole offrire tramite Power BI (che adesso, ha saputo, verrà incluso in Microsoft Fabric ma nulla cambierà per il suo studio).
Luca si sente confidente e non vede l’ora di spedire ai clienti la prima newsletter che includa questa novità dei servizi di BI.
Tuttavia, un punto della strategia deve ancora essere chiarito:
Come comportarsi nel caso in cui l’IT del cliente non permetta, magari perché la casa madre del gestionale non lo permette, di collegarsi al database sottostante il gestionale del cliente o non sia possibile farlo per qualche ragione di politiche IT o perché i dati NON sono su un database?
Luca trova questa una discreta minaccia. Ci pensa su, e decide di parlarne con un informatico di fiducia: il suo.
Durante la conversazione, l’informatico spiega a Luca la situazione che potrà trovare presso i clienti:
Situazione 1: database senza accessi diretti
Il cliente usa un gestionale la cui casa madre non espone di database per accessi diretti, in sostanza la pretende che si passi sempre dal gestionale per interagire col database.
In questo caso, si presenta qualche difficoltà perché Power BI (e in generale i software di self-service BI) mal si connettono ai gestionali, sono fatti per collegarsi al database sottostante.
L’informatico ricorda a Luca che il gestionale non è fatto per fare reportistica ma per inserire, eliminare e modificare record di una tabella.
In questo caso, dunque, che si può fare? L’informatico spiega a Luca che le opzioni sono:
- Power BI può connettersi al gestionale (es. Dynamics), a quel punto le tabelle vengono lette dal gestionale e la cosa si risolve ma, ripete l’informatico, è un caso raro e limitato quasi esclusivamente ai gestionali Microsoft, inoltre lui non lo consiglia;
- Power BI non può connettersi al gestionale, cioè non esiste un connettore per farlo, non è possibile usare il connettore generico ODBC e/o esiste un connettore ma che non permette l’accesso alle strutture di dati idonee alla BI.
In questo caso serve un data warehouse, non essendo possibile per ipotesi accedere al database sottostante.
Luca ha un ricordo di questo termine (data warehouse) ma non ricorda i dettagli precisi (ne abbiamo parlato in questo articolo), così va a rileggersi i suoi appunti
Luca cerca di approfondire, dunque, il punto 1-2
I casi in cui si deve ricorrere al data warehouse, dagli appunti, sono diversi:
- quando la struttura del database sottostante il gestionale (a cui si possa accedere) non ha la struttura adatta all’analisi dei dati;
- quando il database sottostante al gestionale (a cui si possa accedere) non va disturbato (decisione dell’IT);
- quando non è considerato vantaggioso avere dati che cambiano ad ogni refresh ma si preferisca avere un aggiornamento lento (per esempio una volta al giorno, poi i dati restano fissi fino all’indomani)
Nel discutere, dopo la lettura degli appunti, con l’informatico emergono altri casi:
- quando ci sono più database sotto il gestionale o ci sono più gestionali ognuno con uno o più database e si voglia avere un punto unico di accesso ai dati per l’analisi in BI;
- quando un unico gestionale non espone il database sottostante per decisione della casa madre
Luca, quindi, chiede cosa fare se il datawarehouse non è presente e il cliente non vuole o non può crearlo.
L’informatico risponde che esistono case informatiche che fanno questo servizio.
Luca, dunque, capisce che deve avere un rapporto con un’azienda informatica che lo supporti nel creare il data warehouse per i clienti nel caso sia necessario.
Luca chiede quanto tempo sia necessario e la risposta è che non si può stabilire a priori. Dipende da mille fattori ma per clienti piccoli, sicuramente basteranno un paio di settimane.
Per i clienti grossi, dovrebbe già essere presente e/o il cliente stesso ha la risorsa e competenze per farlo o per supportare una casa madre esterna che lo faccia in tempi però più dilatati, magari quattro settimane (poi dipende dalla disponibilità di risorse).
Situazione 2: database secretato per motivi strategici
L’IT del cliente non permette di collegarsi al database sottostante il gestionale del cliente per una ragione di politiche IT
Qui il caso è più sottile: quale sia la reale ragione di questo divieto non è sempre chiaro.
A volte l’IT non comprende la richiesta, la trova sospetta in quanto non chiara e preferisce tenere tutti fuori. Altre volte teme che qualcuno modifichi i dati sul database per sbaglio con gli strumenti di BI.
Altre volte teme per la performance del database sottostante al gestionale che potrebbe essere rallentato dalle interazioni con i software di BI.
In questo caso, bisogna parlare con l’IT e convincerli con degli argomenti:
- spiegare la richiesta: chiarire perché lo si vuole fare. Si vuole soltanto offrire un report ai clienti che non è realizzabile col gestionale che fa un altro mestiere;
- spiegare che Power BI non può scrivere dati né modificare gli esistenti né cancellare dati da alcuna sorgente, nemmeno nel caso in cui fosse data la possibilità da parte dell’IT per errore (cosa praticamente impossibile, ma supponiamolo per assurdo) di scrivere dati, cancellarli o modificarli;
- e spiegare che, in Import, come si lavora sempre in Power BI (ne abbiamo parlato in questo articolo), l’interazione con il database avverrà soltanto una volta al giorno tipicamente (fase di refresh). Spiegare, insomma, che non si usa Directquery
Situazione 3: i dati NON sono su un database
In questo caso bisogna farglieli confluire creando un data warehouse (che è un database)!
Di nuovo, esistono aziende che creano questi meccanismi e Luca deve averli come partner.
Luca chiede: ma non è proprio possibile usare file Excel come sorgente?
La risposta è che è possibile ma la qualità del progetto ne risentirà: i file Excel possono essere facilmente cancellati, danneggiati, spostati, rinominati, modificati nelle colonne e nei fogli di lavoro e questo porterebbe a refresh che non funzionano e darebbe la sensazione di un progetto non ben fatto.
Se proprio non c’è altra scelta, dice l’informatico, troveremo il modo di iniziare così ma deve essere chiaro al cliente che non è il modo giusto di lavorare per analizzare i dati in modo affidabile, tuttavia non si vuole di certo perdere il cliente.
Luca è soddisfatto: almeno ha una risposta per ogni possibile situazione.
L’ultima frase dell’informatico però lo spiazza: attenziona all’orario in cui si chiede a Power BI di fare refresh sul cloud, a quell’ora deve essere finito il refresh del data warehouse.
Due refresh? Ma non era soltanto Power BI Cloud a dovere fare refresh?
Nel prossimo articolo sveleremo questo dettaglio!
A cura di Francesco Bergamaschi
Lunedì 5 giugno 2023
NdR: Potrebbe interessarti anche…Power BI: come approcciare l’offerta ad un cliente dei servizi di Business Intelligence?
A cura di Francesco Bergamaschi
Mercoledì 31 maggio 2023
Potrebbe interessarti: