Vale la pena aggiungere l'aggiunta di rapporti ad hoc a un'applicazione?

Abbiamo un'applicazione che raccoglie molti dati e ha rapporti integrati. La prima iterazione è stata l'integrazione di Crystal Reports che ha funzionato bene. Creare il report in Crystal Report Designer e quindi importare il file RPT nell'applicazione. Funzionava bene, ma gli utenti avevano bisogno dell'applicazione per eseguire un report e inoltre gli utenti non potevano creare un report. Abbiamo aggiunto filtri, selezionatori e raggruppamenti in modo che il file RPT fosse personalizzabile, ma non sono stati in grado di crearne uno da zero.

La seconda interazione era una soluzione basata sul web che utilizzava SSRS, SSAS e lo strumento di creazione report di Microsoft. Ciò ha richiesto un po 'di lavoro sul database e un po' di lavoro per rendere i cubi attivi e funzionanti dallo schema OLTP, ma alla fine, è stato molto più semplice creare report di rollup. Tuttavia, dobbiamo ancora creare i report utilizzando lo strumento di creazione dei report, pubblicare e poi pubblicare, ecc. Abbiamo anche aggiunto filtri, sorter e cernie per renderlo "personalizzabile".

In entrambi questi scenari abbiamo circa 30-50 rapporti pronti all'uso creati nel tempo.

Ora c'è qualche discussione sull'aggiunta di report ad hoc in modo che gli utenti possano creare un report da zero al volo. Ora il nostro modello di dati è molto complesso e richiede una buona conoscenza pratica per capirlo. Per fare questo al minimo occorrerebbe una buona quantità di lavoro per ottenere il modello di dati in uno schema "più riferibile" e più facile da capire. Non credo che la nostra applicazione sia adatta per i report ad hoc (non vale la pena).

Qualcuno ha avuto successo nel fornire report ad hoc? Quale set di strumenti hai usato? Ha avuto un impatto sul successo della tua applicazione?

Esistono alcuni pericoli con i rapporti ad hoc.

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

2. qualsiasi rapporto così creato ha una certa 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 in realtà 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, credo che, se viene fornito uno strumento di reporting personalizzato, deve essere limitato nell'ambito; accuratamente strutturato in modo da non produrre artefatti eccessivi, privi di fondamento e non supportati; e supportato da una politica che delinea chiaramente quale tipo di report può essere generato dinamicamente e quali report devono essere definiti e prodotti formalmente.

In alcuni casi, l'aggiunta di personalizzazioni accuratamente scelte ai report esistenti (ad esempio un numero limitato di parametri configurabili dall'utente) 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 quando si esegue il reporting su un normale sistema transazionale.

Ho visto molti fallimenti costosi. Ho avuto un business partner inclinato in questo mulino a vento per anni. La loro difficoltà era l'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 a vari livelli di successo. Proprio come te, abbiamo iniziato con rapporti fissi con parametri.

Quindi abbiamo creato un modo per salvare i set di parametri e associarli a diversi modelli di "formato", che essenzialmente ti consente di mescolare e abbinare i rapporti predefiniti e pubblicarli ad altre persone. Questa è stata in realtà la cosa più efficiente che abbiamo mai fatto considerando che sono state circa due settimane di tempo di sviluppo (oltre a un sistema di report predefinito parametrizzato) e lo hanno usato con un certo successo per anni. Era un'interfaccia utente molto semplice, ma alcuni utenti non erano ancora in grado di creare i propri report, non riuscivano a capire quali fossero i loro criteri. Ma dal momento che chiunque potrebbe creare un rapporto e condividerlo con qualcun altro, potrebbe semplicemente fare in modo che un collega faccia un rapporto invece di dover rivolgersi a un team MIS e mettersi in coda.

Abbiamo continuato a cercare di migliorarlo e abbiamo sprecato centinaia di migliaia di dollari. Crystal Decisions disponeva di un kit di strumenti piuttosto sofisticato come componente aggiuntivo del prodotto aziendale Crystal Reports. Questa era la versione 9 o 10. È stata da tempo ribattezzata, rinominata da Business Objects ma immagino che ce ne sia ancora una versione. Era piuttosto costoso e ti ha fornito 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 ha guidato a modificare un rapporto esistente. Avevamo avuto successo con l'idea "salva e condividi modello parametrizzato", quindi questo ci ha attratto perché è andato oltre. Per farla breve, in realtà non ce la siamo fatta. Penso che lo strumento fosse ok, ma quello che stavamo cercando di fare era troppo confuso e sbagliato per funzionare.

Per tutto questo tempo l'azienda ha dovuto mantenere uno staff di sviluppatori MIS che ha svolto gran parte dei propri report ad hoc. Il meglio che abbiano mai ottenuto dalle nostre cose è stato un rapporto in scatola un po 'più flessibile che nel migliore dei casi ha reso più veloce lo sviluppo di un nuovo rapporto fisso a condizione che esistesse un altro rapporto esistente che fosse in qualche modo simile. Se desideri in qualche modo integrare una nuova fonte di dati, dimenticala. E soprattutto, questo è quello che MIS ha fatto per loro era integrare sempre più fonti di dati in modo sciatto 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 scoperto nel catalogo dei metadati online. Quindi potresti fare sia materiale di produzione reale per le masse, sia i dirigenti e i manager potrebbero continuare a sgranocchiare diverse serie di dati verso cui la loro ricerca li ha condotti. Il set di abilità è diventato ancora più raro, certamente non era qualcosa che chiunque poteva imparare a fare. Tuttavia sono stati in grado di convincere molte più persone a usarlo in modo efficace di quanto avrebbero mai potuto permettersi di assumere come persone MIS dedicate. Tuttavia, il personale del MIS non è mai stato ridotto molto, il che è indicativo.

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 usando questo strumento, e devi accettare che non tutto il tuo personale ci arriverà mai. E se non riescono a passare un paio di settimane ad imparare una piattaforma BI, non saranno mai in grado di ottenere il massimo da qualsiasi strumento che gli dai. Alcune persone, per qualsiasi motivo, non sembrano mai avere idee di base come i join esterni. Enormi classi di insiemi di problemi non saranno mai alla loro portata per essere risolti con nessuno strumento perché non riescono a comprendere abbastanza a fondo a livello concettuale ciò che stanno realmente cercando di chiedere al computer di fare. Questo non vuol dire che "non possono" impararlo, solo che molti di loro non lo faranno mai.

Attualmente stiamo affrontando 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 consentiamo agli utenti di importare i dati direttamente e creare report utilizzando questo. Abbiamo scoperto che molti di questi rapporti ad hoc sono stati esclusi da quelli necessari in un momento specifico per rispondere a una domanda specifica.

A questo punto sta funzionando bene, è stato necessario un po 'di addestramento e tenuta della mano in anticipo, ma viene utilizzato dal dipartimento finanziario, quindi ovviamente sono più a loro agio 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 di aggiungere un datawarehouse con una soluzione OLAP in cima. Per contenere 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 le tue analisi per progettare un modello di dati adatto alle esigenze degli utenti. Ci sono voluti tre mesi dai requisiti alla distribuzione, e all'inizio c'erano alcuni problemi da risolvere, ma alla fine il cliente è molto soddisfatto dei risultati. Gli utenti ora creano la propria analisi e talvolta li usano come report (esportandoli in PDF). C'è anche una funzione che consente di creare report ad hoc abbastanza semplici, ma almeno per ora lo strumento di analisi è più che sufficiente per le loro esigenze.

Quanto più ampio è il dominio e la dimensione delle aziende che hai come clienti, tende a inclinarsi verso personalizzazioni, integrazione dei dati e rapporti ad hoc. Sta per scendere ai costi.

La maggior parte delle aziende scoraggia le personalizzazioni in modo da addebitare commissioni elevate per questo servizio. I programmatori tendono a vedere queste cose come inutili, ma quando puoi risparmiare tempo e renderlo più semplice per alcune centinaia di utenti, i risparmi si sommano.

Per la segnalazione, ciò crea l'opportunità di addebitare l'addestramento aggiuntivo. I rapporti ad hoc possono avere un costo aggiuntivo.

Il tuo lavoro come sviluppatore diventerà più duro. La maggior parte dei posti in cui abbia mai lavorato con software di terze parti presentava report personalizzati. Per alcuni è stato facile perché avevano strutture dati semplici. Quelle più grandi / complesse necessitavano di rapporti personalizzati perché è così che gestiscono la loro attività. Se avessero voluto fare le stesse cose di tutti gli altri, non mi avrebbero assunto. Ho dovuto porre alcune domande su DevExpress Reporting su SO.

Spetta alle vendite e al marketing verificare se è necessario. Non "I rapporti ad hoc sarebbero fantastici", ma "Comprerei il tuo software perché ha rapporti ad hoc". Devi solo rendere tutti consapevoli dell'investimento tecnico richiesto.

La mia soluzione è far sì che la tua applicazione generi alcuni fogli di calcolo di base e consenta agli utenti di giocare con Access fino a quando non vedono quello che vogliono.

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

Ne ho fatti un paio nel corso degli anni. Come hai detto, con i database che si basano su una certa conoscenza del dominio, può diventare molto complicato. Come 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 combatterli tanto quanto aiutano.

Agli utenti piace davvero poter creare i propri report, quindi direi che ne è valsa la pena se si ha il tempo di sviluppare un tale sistema.

La risposta breve è che può essere.

Ho lavorato per un'azienda a metà degli anni '90 che ha creato software che fa esattamente quello che sta chiedendo. Avevamo un buon mercato nel settore farmaceutico, dove le sperimentazioni cliniche comportavano un sacco di domande e rapporti, al punto che era logico eliminare gli intermediari dell'IS.

Quell'azienda è stata inghiottita da un'altra, che a sua volta è stata inghiottita da un'altra che non sapeva né importava cosa fare del prodotto.

Tuttavia, il mondo (ossimoro) della Business Intelligence si basa in parte sul consentire agli utenti finali la possibilità di definire o almeno affinare le query ai 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. Quindi hanno comprato Crystal. Quindi SAP li ha acquistati. La loro attuale offerta in questo ambito è SAP Crystal Interactive Analysis.

È un grande sforzo: gli strumenti richiedono generalmente molto lavoro per impostare i metadati e tutto il resto. È davvero una domanda: i tuoi utenti hanno davvero bisogno di questo: 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 reporting ad hoc che si sentisse "incorporata" nelle applicazioni esistenti, fornito funzionalità di drill-through per visualizzare le informazioni sui record dietro l'output del report e fornito pieno accedere alla query del database. I prodotti con 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 per lanciare il nostro strumento di reporting ad hoc che abbiamo usato per diversi anni. Tuttavia, è costoso da mantenere e un orso da migliorare poiché non è stato progettato per estendersi oltre i casi d'uso di join, filtro e ordinamento modesti.

Alcuni problemi abbiamo avuto simili a quelli menzionati da altri:

• Incapacità degli utenti di comprendere il modello di dati - 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 molti dei dati hanno attributi spaziali.
• Impossibilità di aggiungere segnalibri e tornare a selezioni di report ad hoc (questo era un difetto nella progettazione dello strumento originale).

Stiamo attualmente valutando Pull Reports per determinare se è in grado di risolvere questi problemi. Ci piace il modo in cui l'interfaccia ad hoc offre agli utenti una visione 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 in modo errato.

Sul fatto che tutto ciò sia stato "utile": nel nostro caso, il reporting ad hoc è stato più economico e più facile da gestire rispetto al fatto che il personale tecnico gestisca una proliferazione di report predefiniti. Tuttavia, la domanda è un po 'controversa perché i report predefiniti, sia con il nostro strumento di reporting interno che con Pull Reports, sono generalmente basati sul motore di query / reporting dello strumento di reporting ad hoc. Significato, i rapporti predefiniti sono solo rapporti ad hoc con impostazioni preconfigurate.