A adição de relatórios Ad Hoc a um aplicativo vale o esforço?


16

Temos um aplicativo que coleta muitos dados e possui relatórios incorporados. A primeira iteração foi uma integração do Crystal Reports que funcionou bem. Crie o relatório no designer do Crystal Report e importe o arquivo RPT para o aplicativo. Isso funcionou bem, mas os usuários precisavam do aplicativo para executar um relatório e, além disso, os usuários não podiam criar um relatório. Adicionamos filtros, classificadores e agrupamentos para que o arquivo RPT fosse personalizável, mas eles não podiam criar um do zero.

A segunda interação foi uma solução baseada na Web usando o SSRS, o SSAS e a ferramenta de criação de relatórios da Microsoft. Isso exigiu algum trabalho de banco de dados e algum trabalho para colocar os cubos em funcionamento a partir do esquema OLTP, mas no final, foi muito mais fácil criar relatórios de rollup. No entanto, ainda precisamos criar os relatórios usando a ferramenta de criação de relatórios, publicar e publicar etc. Também adicionamos filtros, classificadores e agrupadores para torná-los "personalizáveis".

Em ambos os cenários, temos cerca de 30 a 50 relatórios prontos criados ao longo do tempo.

Agora, há uma discussão sobre a adição de relatórios ad hoc para que os usuários possam criar um relatório do zero em tempo real. Agora, nosso modelo de dados é muito complexo e requer um bom conhecimento de trabalho para dar sentido a ele. Fazer isso no mínimo exigiria uma boa quantidade de trabalho para colocar o modelo de dados em um esquema que seja "mais reportável" e mais fácil de entender. Não acho que nosso aplicativo seja adequado para relatórios ad hoc (não vale o esforço).

Alguém teve sucesso em fornecer relatórios ad hoc? Que conjunto de ferramentas você usou? Isso teve impacto no sucesso do seu aplicativo?

Respostas:


13

Existem alguns perigos nos relatórios ad-hoc.

  1. Os relatórios tendem a proliferar na explosão combinatória resultante.

  2. qualquer relatório criado tem alguma legitimidade interna porque, bem, é um relatório impresso, portanto as informações devem ser válidas.

  3. Você pode pensar que fornecer relatórios dessa maneira reduz sua carga para apoiar as pessoas com novos relatórios, mas na verdade aumenta.

  4. Não se trata apenas de oferecer às pessoas uma capacidade de geração de relatórios. É também sobre gerenciamento de documentos: qual é a política de retenção e destruição de tais documentos? Quais são os requisitos de arquivamento e armazenamento?

Por todos esses motivos, acredito que, se uma ferramenta de relatório personalizada for fornecida, ela deverá ter um escopo limitado; cuidadosamente estruturado para não produzir artefatos excessivos, sem fundamento e sem suporte; e apoiada por uma política que descreve claramente que tipo de relatório pode ser gerado dinamicamente e quais relatórios devem ser definidos e produzidos formalmente.

Em alguns casos, adicionar uma personalização cuidadosamente escolhida aos relatórios existentes (um pequeno número de parâmetros configuráveis ​​pelo usuário, por exemplo) pode reduzir a necessidade de uma ferramenta de relatório personalizada. Observe também que, se se trata de realizar pesquisas em um banco de dados OLAP, é necessária mais flexibilidade nos relatórios do que nos relatórios em um sistema transacional comum.


2
+1 por limitar cuidadosamente a estrutura e o escopo. É fácil ir ao mar e criar um monstro.
GrandmasterB

Essa discussão está surgindo no meu escritório recentemente e eu tenho muitos dos mesmos sentimentos, mas eles são difíceis de comprovar. Suponho que não conheça nenhum lugar para obter um tratamento aprofundado desse assunto. Por exemplo, como seria uma boa definição de relatório e / ou política de retenção?
Aaronaught

@Aaronaught: Você começa com mandatos legais para manutenção de registros e trabalha de volta a partir daí. Por exemplo, na maioria das organizações (sãs), existe uma política para retenção de e-mails, porque se você os mantiver por muito tempo ou pouco, a empresa poderá ficar exposta a responsabilidade legal. Registros que pertencem a coisas como garantias e impostos são muito claros; outros tipos de registros, nem tanto.
Robert Harvey

E a parte de aumentar o fardo em vez de reduzi-lo - como você explicaria / justificaria isso para, digamos, um CTO ou CEO?
Aaronaught 7/08/11

@Aaronaught: Como você provavelmente já descobriu, as ferramentas de relatório ad-hoc não são uma bala de prata; eles fornecem algum grau de simplificação ao longo do processo, mas as pessoas que não conseguem pensar em termos de conjuntos e uniões (ou seja, SQL) também parecem ter dificuldade em usar seus computadores para coisas mais mundanas. Portanto, seu esforço de suporte simplesmente passa da criação de relatórios personalizados (que produzem ativos corporativos que podem ser aproveitados repetidamente) para ajudar os neófitos a escrever seus próprios relatórios de clientes (que são todos esforços de uma só vez).
9788 Robert Harvey

7

Eu já vi muitas falhas caras. Eu tive um parceiro de negócios inclinado neste moinho de vento por anos. A dificuldade deles era a insistência em que pessoas "não técnicas" pudessem criar relatórios. Construímos uma série de soluções que as pessoas foram capazes de aprender e usar com vários graus de sucesso. Assim como você, começamos com relatórios fixos parametrizados.

Em seguida, criamos uma maneira de salvar conjuntos de parâmetros e associá-los a diferentes modelos de "formato", o que essencialmente permite que você misture e combine seus relatórios em lata e os publique para outras pessoas. Essa foi realmente a coisa mais eficiente que já fizemos, considerando que foram cerca de duas semanas de tempo de desenvolvimento (em cima de um sistema básico de relatórios parametrizados básicos) e eles a usaram com algum sucesso por anos. Era uma interface de usuário muito simples, mas ainda assim alguns usuários não conseguiam criar seus próprios relatórios, eles simplesmente não conseguiam descobrir quais deveriam ser seus critérios. Mas como alguém poderia criar um relatório e compartilhá-lo com outra pessoa, ele poderia apenas pedir a um colega para fazer um relatório, em vez de precisar ir a alguma equipe do MIS e ficar na fila.

Continuamos tentando melhorá-lo e desperdiçamos centenas de milhares de dólares. A Crystal Decisions tinha um kit de ferramentas bastante sofisticado como um complemento ao produto corporativo da Crystal Reports. Esta foi a versão 9 ou 10. Há muito que foi renomeada, renomeada pela Business Objects, mas imagino que ainda haja uma versão dela. Era muito caro e fornecia a você um web designer completo para criar praticamente qualquer formato de relatório. Ele também tinha um aplicativo de amostra que era mais um assistente que orientava você na modificação de um relatório existente. Tivemos sucesso com a idéia "salvar e compartilhar modelo parametrizado", e isso nos atraiu, pois foi um passo adiante. Bem, para encurtar a história, realmente não cumprimos. Acho que a ferramenta estava ok, mas o que estávamos tentando fazer era muito confuso e errado para o trabalho.

Todo esse tempo, a empresa teve que manter uma equipe de desenvolvedores de MIS que fazia muitos relatórios ad-hoc. O melhor que eles obtiveram de nossas coisas foi um relatório enlatado um pouco mais flexível que, na melhor das hipóteses, tornou mais rápido o desenvolvimento de um novo relatório enlatado, desde que houvesse outro relatório que fosse algo semelhante. Se você deseja integrar de alguma forma uma nova fonte de dados, esqueça. E, principalmente, o que a MIS fez por eles foi integrar cada vez mais fontes de dados de maneira desleixada, mas muito rápida no mercado.

Eventualmente, eles começaram a usar fortemente o Business Objects - a versão desktop da ferramenta de BI. Isso permite integrar dados locais aos dados que você descobriu no catálogo de metadados online. Assim, você poderia fazer tanto material de produção real para as massas quanto os quantos e gerentes poderiam continuar analisando diferentes conjuntos de dados que suas pesquisas os levaram. O conjunto de habilidades ficou ainda mais raro, certamente não era algo que qualquer um pudesse entender e fazer. Ainda assim, eles conseguiram atrair muito mais pessoas para usá-lo com eficiência do que jamais poderiam contratar como pessoas dedicadas ao MIS. A equipe do MIS nunca foi reduzida muito, o que é revelador.

Minha impressão pessoal sobre esse problema geral é que você deve estar disposto a investir significativamente no desenvolvimento de habilidades para as pessoas que imagina usar essa ferramenta, e precisa aceitar que nem todos os seus funcionários chegarão lá. E se eles não puderem passar algumas semanas aprendendo uma plataforma de BI, nunca conseguirão tirar o máximo proveito de qualquer ferramenta que você fornecer. Algumas pessoas, por qualquer motivo, parecem nunca ter idéias básicas, como uniões externas. Classes enormes de conjuntos de problemas nunca estarão ao seu alcance para resolver com qualquer ferramenta, porque elas não se aprofundam o suficiente para entender em nível conceitual o que realmente estão tentando pedir ao computador. Isso não quer dizer que eles "não possam" aprender isso, mas muitos deles nunca aprenderão.


5

Estamos enfrentando essa situação atualmente. Neste ponto, em vez de uma interface de relatório ad-hoc, estamos executando uma avaliação usando o Excel e o Power Pivot. Nós o integramos à barra de ferramentas do Excel e permitimos que os usuários importem os dados diretamente e construam relatórios usando isso. Descobrimos que muitos desses relatórios ad-hoc são distribuídos em um momento específico para responder a uma pergunta específica.

Neste ponto, está funcionando bem, foi necessário um pouco de treinamento e manutenção das mãos, mas está sendo usado pelo departamento financeiro, portanto é claro que eles são mais confortáveis ​​no Excel.

A propósito, se você quiser falar sobre alguns detalhes da implementação, entre em contato.


+1, escritório, em muitos aspectos é a plataforma de relatórios final
Wyatt Barnett

2

Em um cenário semelhante em um projeto que estou gerenciando, oferecemos ao cliente a adição de um datawarehouse com uma solução OLAP na parte superior. Para manter os custos baixos, escolhemos o PostgreSQL como banco de dados DWH e o Pentaho Enterprise como ferramenta de análise BI / OLAP - escolhemos a versão paga porque a ferramenta OLAP é muito mais amigável.

Exatamente como você disse, você precisa fazer sua análise para projetar um modelo de dados adequado às necessidades dos usuários. Demoramos três meses desde os requisitos até a implantação e, no início, havia algumas falhas a serem corrigidas, mas no final o cliente está muito satisfeito com os resultados. Os usuários agora criam suas próprias análises e às vezes as usam como relatórios (exportando-os para PDF). Há também um recurso que permite criar relatórios ad-hoc simples o suficiente, mas pelo menos por enquanto a ferramenta de análise é mais do que suficiente para suas necessidades.


2

Quanto mais amplo o domínio e o tamanho das empresas que você tem como clientes, mais inclinado a personalizações, integração de dados e relatórios ad hoc. Vai custar caro.

A maioria das empresas desencoraja personalizações para cobrar taxas altas por esse serviço. Os programadores tendem a ver isso como desnecessário, mas quando você pode economizar tempo e facilitar para algumas centenas de usuários, a economia aumenta.

Para relatórios, isso cria uma oportunidade de cobrar por treinamento adicional. Os relatórios ad hoc podem ter uma taxa adicional.

Seu trabalho como desenvolvedor ficará mais difícil. A maioria dos lugares em que trabalhei com software de terceiros tinha relatórios personalizados. Para alguns, foi fácil porque eles tinham estruturas de dados simples. Os maiores / mais complexos precisavam de relatórios personalizados, porque é assim que administram seus negócios. Se eles quisessem fazer as mesmas coisas que todos os outros, não teriam me contratado. Eu tive que colocar algumas perguntas sobre relatórios do DevExpress no SO.

Cabe a vendas e marketing verificar se há uma necessidade. Não "Relatórios ad hoc seriam legais", mas "Eu compraria seu software porque ele possui relatórios ad hoc". Você só precisa conscientizar todos sobre o investimento técnico necessário.


2

Minha solução é fazer com que seu aplicativo gere algumas planilhas básicas e permita que os usuários joguem com o Access até verem o que desejam.

Uma abordagem mais sofisticada seria escrever um programa de acesso / vbscript para "atualizar" os dados da base, permitindo que os usuários reutilizassem as personalizações.


1

Eu fiz algumas ao longo dos anos. Como você disse, com bancos de dados que dependem de certos conhecimentos de domínio, pode ficar muito complicado. Como tal, eu (ou a equipe em que estava) os desenvolvi sem usar uma ferramenta de relatório. Eles eram francamente demais para trabalhar, tentando obter toda a lógica necessária para eles. Você acaba lutando com eles tanto quanto eles ajudam.

Os usuários realmente gostam de poder fazer seus próprios relatórios, então eu diria que definitivamente valeu a pena se você tiver tempo para desenvolver esse sistema.


1

A resposta curta é que pode ser.

Eu trabalhei para uma empresa em meados dos anos 90 que construiu software que faz exatamente o que eles estão pedindo. Tínhamos um bom mercado na indústria farmacêutica, onde os ensaios clínicos significavam muitas consultas e relatórios - tanto que eliminar os intermediários do SI fazia sentido.

Essa empresa foi engolida por outra, que por sua vez foi engolida por outra que não sabia ou se importava com o que fazer com o produto.

Ainda assim, o mundo (oximorônico) do Business Intelligence depende, em parte, de permitir aos usuários finais a capacidade de definir ou pelo menos refinar as consultas aos sistemas de dados. Existem ferramentas para tornar isso mais fácil para o usuário. A Business Objects (agora parte da SAP) era o rei neste domínio. Então eles compraram Crystal. Então a SAP os comprou. Sua oferta atual neste domínio é o SAP Crystal Interactive Analysis.

É um grande esforço - as ferramentas geralmente exigem muito trabalho para configurar seus metadados e tudo mais. É realmente uma questão de seus usuários REALMENTE precisarem disso - qual será o ROI?


1

Trabalho para um sistema de TI governamental que possui requisitos de relatórios ad hoc e enlatados. Além disso, os usuários queriam uma solução de relatório ad hoc que fosse "incorporada" nos aplicativos existentes, fornecendo recursos de detalhamento para exibir as informações de registro por trás da saída do relatório e fornecendo informações completas. acesso à consulta no banco de dados. Os produtos de relatório direcionados eram geralmente apenas uma página da web ou o MS Excel. A segurança queria que os relatórios fossem integrados aos controles de segurança JEE existentes.

Depois de não encontrar uma solução existente no mercado, acabamos lançando nossa própria ferramenta de relatório ad hoc que usamos há vários anos. No entanto, é caro manter e valer a pena aprimorar, uma vez que não foi projetado para ir além dos casos de uso modesto de associação, filtro e classificação.

Alguns problemas que tivemos foram semelhantes aos mencionados por outros:

  • Incapacidade de os usuários entenderem o modelo de dados - em particular, os usuários criam regularmente produtos de junção cruzada por meio da ferramenta e ficam confusos com a saída.
  • Não é possível exibir os resultados em um mapa, embora muitos dos dados tenham atributos espaciais.
  • Incapacidade de marcar e retornar às seleções ad hoc de relatório (essa era uma falha no design da ferramenta original).

No momento, estamos avaliando os relatórios pull para determinar se ele pode resolver esses problemas. Gostamos de como a interface ad hoc fornece aos usuários um visual simplificado do modelo de dados, além de descrições textuais de tabelas e colunas. O fato de as seleções de filtro do usuário serem incorporadas à saída do relatório reduz a preocupação de que os resultados sejam interpretados incorretamente.

Quanto a se tudo isso "valeu a pena" ou não: no nosso caso, os relatórios ad hoc foram mais baratos e fáceis de gerenciar do que a equipe técnica gerenciar uma proliferação de relatórios em lata. No entanto, a pergunta é um pouco discutível, porque os relatórios em lata - tanto com a nossa ferramenta de relatório interna quanto com o Pull Reports - geralmente são construídos sobre o mecanismo de consulta / relatório da ferramenta de relatório ad hoc. Ou seja, os relatórios em lata são apenas relatórios ad hoc com configurações pré-configuradas.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.