L'aggiunta di report Ad Hoc a un'applicazione vale la pena?

Ci sono alcuni pericoli con i report ad hoc.

1. I report tendono a proliferare nell'esplosione combinatoria risultante.

2. qualsiasi rapporto così creato ha una legittimità incorporata perché, beh, è un rapporto stampato, quindi le informazioni devono essere valide.

3. Potresti pensare che fornire report in questo modo riduca il tuo onere per supportare le persone con nuovi report, ma di fatto lo aumenta.

4. Non si tratta solo di offrire alle persone una capacità di segnalazione. Riguarda anche la gestione dei documenti: qual è la politica di conservazione e distruzione di tali documenti? Quali sono i requisiti di archiviazione e archiviazione?

Per tutti questi motivi, ritengo che, se viene fornito uno strumento di reporting personalizzato, tale ambito deve essere limitato; attentamente strutturato in modo da non produrre artefatti eccessivi, non comprovati e non supportati; e supportato da una politica che delinea chiaramente quali tipi di report possono essere generati dinamicamente e quali report devono essere definiti e prodotti formalmente.

In alcuni casi, l'aggiunta di personalizzazioni scelte con cura a report esistenti (un piccolo numero di parametri configurabili dall'utente, ad esempio) può ridurre la necessità di uno strumento di reporting personalizzato. Si noti inoltre che, se si tratta di eseguire ricerche su un database OLAP, è necessaria una maggiore flessibilità di reporting rispetto a se si sta segnalando su un normale sistema transazionale.

Ho visto molti fallimenti costosi. Ho avuto un inclinazione del socio in affari in questo mulino a vento per anni. La loro difficoltà era la loro insistenza sul fatto che le persone "non tecniche" fossero in grado di creare rapporti. Abbiamo creato una serie di soluzioni che le persone sono state in grado di apprendere e utilizzare in vari gradi di successo. Proprio come te, abbiamo iniziato con report in scatola parametrizzati.

Quindi abbiamo creato un modo per salvare i set di parametri e associarli a diversi modelli di "formato", che essenzialmente consentono di mescolare e abbinare i report in scatola e pubblicarli ad altre persone. Questa è stata effettivamente la cosa più efficiente che abbiamo mai fatto considerando che erano circa due settimane di sviluppo (in aggiunta a un sistema di report in scatola parametrizzato di base) e l'hanno usato con successo per anni. Era un'interfaccia utente molto semplice, ma alcuni utenti non potevano davvero creare i propri report, semplicemente non riuscivano a capire quale fosse il loro criterio. Ma dal momento che chiunque potrebbe creare un report e condividerlo con qualcun altro, potrebbe semplicemente fare in modo che un collega faccia un report invece di dover andare in qualche team MIS e stare in coda.

Abbiamo cercato di migliorarlo e abbiamo sprecato centinaia di migliaia di dollari. Crystal Decisions disponeva di un kit di strumenti piuttosto elaborato come componente aggiuntivo del proprio prodotto aziendale di report sui cristalli. Questa era la versione 9 o 10. È stata rinominata da tempo, rinominata da Business Objects ma immagino ci sia ancora una versione di esso. Era piuttosto costoso e ti dava un web designer completo per creare praticamente qualsiasi formato di report. Aveva anche un'applicazione di esempio che era più di una procedura guidata che ti guidava attraverso la modifica di un rapporto esistente. Avevamo avuto successo con l'idea di "salvare e condividere il modello parametrizzato", quindi questo ci ha affascinato non appena ha compiuto un ulteriore passo avanti. Beh, per farla breve, non ci siamo davvero resi conto. Penso che lo strumento fosse ok, ma quello che stavamo cercando di fare era troppo confuso e sbagliato per funzionare. Alla fine ancora meno persone sono state in grado di usarlo efficacemente, e ha avuto dei fastidiosi limiti poiché abbiamo gradualmente rinunciato a far funzionare alcune funzionalità e il nostro budget si è esaurito.

Per tutto questo tempo l'azienda ha dovuto tenere uno staff di sviluppatori di MIS che ha fatto un sacco di report ad hoc. Il meglio che hanno mai avuto dalla nostra roba è stato un po 'più flessibile di segnalazione in scatola che il caso migliore ha reso più veloce lo sviluppo di un nuovo rapporto in scatola, a patto che ci fosse un altro rapporto esistente che fosse in qualche modo simile. Se vuoi in qualche modo integrare una nuova fonte di dati, dimenticala. E soprattutto, quello che MIS ha fatto per loro è stato integrare sempre più fonti di dati in modo scadente, ma molto rapido sul mercato.

Alla fine hanno iniziato a utilizzare pesantemente Business Objects, la versione desktop dello strumento BI. Ciò ti consente di integrare i dati locali con i dati che hai trovato nel catalogo dei metadati online. Quindi potevi fare sia le cose reali di produzione per le masse, sia i manager ei manager potevano continuare a scricchiolare diversi set di dati a cui la ricerca li aveva portati. Il set di abilità è diventato ancora più raro, non era certo qualcosa che chiunque poteva raccogliere e fare. Eppure sono stati in grado di far sì che molte più persone lo usassero in modo efficace di quanto avrebbero potuto permettersi di assumere come specialisti MIS. Lo staff di MIS non è mai stato ridotto molto, il che è significativo.

La mia impressione di questo problema generale è che devi essere disposto a investire in modo significativo nello sviluppo delle competenze per le persone che immagini di utilizzare questo strumento, e devi accettare che non tutto il tuo staff arriverà mai lì . E se non possono trascorrere un paio di settimane imparando una piattaforma BI, non saranno mai in grado di ottenere il massimo dallo qualsiasi strumento che gli dai. Alcune persone, per qualsiasi ragione, non sembrano mai avere idee di base come join esterni. Enormi classi di insiemi di problemi non saranno mai alla loro portata per risolvere con qualsiasi strumento perché non riescono a capirci abbastanza da capire a livello concettuale cosa stanno realmente cercando di chiedere al computer. Ciò non significa che "non possono" apprenderlo, solo che molti non lo faranno mai.

Attualmente siamo di fronte a questa situazione. A questo punto anziché un'interfaccia di reporting ad hoc stiamo eseguendo una versione di prova con Excel e Power Pivot. Lo abbiamo integrato con la barra degli strumenti di Excel e gli utenti possono importare i dati direttamente e creare report usando questo. Abbiamo riscontrato che molti di questi report ad hoc prevedono uno spostamento laddove necessario in un momento specifico per rispondere a una domanda specifica.

A questo punto sta funzionando bene, è stato richiesto un po 'di allenamento e di mano in anticipo, ma è utilizzato dal dipartimento finanziario, quindi sono i più comodi in Excel.

A proposito, se vuoi parlare di alcuni dettagli di implementazione fammelo sapere.

In uno scenario simile su un progetto che sto gestendo, abbiamo offerto al cliente l'aggiunta di un datawarehouse con una soluzione OLAP in cima. Per mantenere bassi i costi, abbiamo scelto PostgreSQL come database DWH e Pentaho Enterprise come strumento di analisi BI / OLAP: abbiamo scelto la versione a pagamento perché lo strumento OLAP è molto più intuitivo.

Esattamente come hai detto, devi fare la tua analisi per progettare un modello di dati che sia adatto alle esigenze degli utenti. Ci sono voluti tre mesi dai requisiti per l'implementazione, e in un primo momento ci sono stati alcuni inconvenienti da risolvere, ma alla fine il cliente è molto soddisfatto dei risultati. Gli utenti ora creano le proprie analisi e talvolta li usano come report (esportandoli in PDF). C'è anche una funzionalità che consente di creare report ad hoc abbastanza semplici, ma almeno per ora lo strumento di analisi è più che sufficiente per le loro esigenze.

Più ampio è il dominio e le dimensioni delle aziende che hai come clienti tendono a privilegiare personalizzazioni, integrazione dei dati e reporting ad hoc. Scenderà a caro prezzo.

La maggior parte delle aziende scoraggia le personalizzazioni, quindi fanno pagare commissioni elevate per questo servizio. I programmatori tendono a vedere queste cose come non necessarie, ma quando puoi risparmiare tempo e renderlo più semplice per poche centinaia di utenti, i risparmi si sommano.

Per i rapporti, questo crea un'opportunità per caricare un ulteriore allenamento. I rapporti ad hoc possono avere un costo aggiuntivo.

Il tuo lavoro come sviluppatore diventerà più duro. La maggior parte dei posti in cui ho lavorato con software di terze parti ha avuto rapporti personalizzati. È stato facile per alcuni perché avevano strutture dati semplici. Le più grandi / più complesse hanno bisogno di report personalizzati perché è così che gestiscono la loro attività. Se volevano fare le cose come tutti, non mi avrebbero assunto. Ho dovuto inserire alcune domande di segnalazione DevExpress su SO.

Spetta alle vendite e al marketing per vedere se ce n'è bisogno. Non "Il reporting ad hoc sarebbe bello", ma "Vorrei acquistare il tuo software perché ha rapporti ad hoc". Hai solo bisogno di rendere tutti consapevoli dell'investimento tecnico richiesto.

La mia soluzione è far sì che la tua applicazione generi alcuni fogli di lavoro di base e permetta agli utenti di giocare con Access finché non vedono ciò che vogliono.

Un approccio più sofisticato sarebbe scrivere un programma access / vbscript per "aggiornare" i dati di base in modo da consentire agli utenti di riutilizzare le personalizzazioni.

Ho fatto un paio di anni. Come hai detto, con i database che si basano su determinate conoscenze di dominio, può diventare molto complicato. In quanto tale io (o il team in cui ero) li ho sviluppati senza utilizzare uno strumento di reporting. Erano francamente troppi problemi con cui lavorare, cercando di ottenere tutta la logica necessaria. Finisci per combattere loro quanto aiutano.

Gli utenti amano davvero essere in grado di creare i propri report, quindi direi che ne valeva sicuramente la pena se si ha il tempo per sviluppare un tale sistema.

La risposta breve è che può essere.

Ho lavorato per un'azienda a metà degli anni '90 che ha creato un software che fa esattamente quello che chiedono. Avevamo un buon mercato nel settore farmaceutico, dove gli studi clinici richiedevano molte ricerche e rapporti, al punto che tagliare gli intermediari della IS era sensato.

Quella compagnia è stata inghiottita da un'altra, che a sua volta è stata inghiottita da un'altra che non sapeva o non si preoccupava di cosa fare con il prodotto.

Tuttavia, il mondo (ossimoro) della Business Intelligence si basa in parte sul permettere agli utenti finali di definire o almeno di raffinare le query sui sistemi di dati. Ci sono strumenti là fuori per rendere questo un po 'più facile per l'utente. Business Objects (ora parte di SAP) era il re in questo regno. Poi hanno comprato Crystal. Quindi SAP li ha comprati. La loro attuale offerta in questo ambito è l'analisi SAP Crystal Interactive.

È un grande sforzo: gli strumenti in genere richiedono molto lavoro per impostare i metadati e tutto il resto. E 'davvero una questione di bisogno VERAMENTE dei tuoi utenti - quale sarà il ROI?

Lavoro per un sistema IT governativo che ha requisiti di reporting ad hoc e predefiniti Inoltre, gli utenti desideravano una soluzione di reportistica ad hoc che si sentisse "incorporata" all'interno delle applicazioni esistenti, fornendo funzionalità drill through per visualizzare le informazioni del record dietro l'output del report, e ha fornito l'accesso completo alla query del database. I prodotti di report mirati erano in genere solo una pagina Web o MS Excel. La sicurezza voleva che i report si integrassero con i controlli di sicurezza JEE esistenti.

Dopo aver fallito nel trovare una soluzione esistente sul mercato, abbiamo finito con il rollare il nostro strumento di segnalazione ad hoc che abbiamo utilizzato per diversi anni. Tuttavia, è costoso da mantenere e potenziare poiché non è stato progettato per estendersi oltre il modesto join, filtrare e ordinare i casi d'uso.

Alcuni problemi abbiamo avuto simili a quelli menzionati da altri:

• Incapacità degli utenti di comprendere la datamodel - in particolare, gli utenti creano regolarmente prodotti cross join tramite lo strumento e sono confusi dall'output.
• Nessuna possibilità di visualizzare i risultati su una mappa anche se gran parte dei dati ha attributi spaziali.
• Impossibilità di contrassegnare e tornare a selezioni di report ad hoc (questo era un difetto nella progettazione dello strumento originale).

Al momento stiamo valutando Pull Reports per determinare se può risolvere questi problemi. Ci piace come l'interfaccia ad hoc offra agli utenti una visualizzazione semplificata del modello di dati insieme a descrizioni testuali di tabelle e colonne. Il fatto che le selezioni dei filtri dell'utente siano incorporate nell'output del report riduce la preoccupazione che i risultati vengano interpretati erroneamente.

Riguardo al fatto se tutto questo è stato "ne vale la pena": nel nostro caso, la segnalazione ad hoc è stata meno costosa e più facile da gestire rispetto al fatto che il personale tecnico gestisca una proliferazione di segnalazioni in scatola. Tuttavia, la questione è un po 'discutibile perché i report predefiniti - sia con il nostro strumento di reporting interno che con i report pull - sono generalmente basati sul motore di query / reporting dello strumento di reporting ad hoc. Significa che i report in scatola sono solo report ad hoc con impostazioni preconfigurate.