Tenemos una aplicación que recopila una gran cantidad de datos y tiene informes incorporados. La primera iteración fue una integración de Crystal Reports que funcionó muy bien. Cree el informe en el diseñador de Crystal Report y luego importe el archivo RPT a la aplicación. Esto funcionó bien, pero los usuarios necesitaban la aplicación para ejecutar un informe y, además, los usuarios no podían crear un informe. Agregamos filtros, clasificadores y agrupaciones para que el archivo RPT fuera personalizable, pero no pudieron crear uno desde cero.
La segunda interacción fue una solución basada en la web que utiliza SSRS, SSAS y la herramienta de creación de informes de Microsoft. Esto requirió un poco de trabajo en la base de datos y algo de trabajo para poner en funcionamiento los cubos desde el esquema OLTP, pero al final, fue mucho más fácil crear informes de resumen. Sin embargo, todavía tenemos que crear los informes utilizando la herramienta de creación de informes, publicarlos, etc. También agregamos filtros, clasificadores y agrupadores para que sean "personalizables".
En ambos sceanarios, tenemos entre 30 y 50 informes listos para usar creados con el tiempo.
Ahora hay una discusión sobre cómo agregar informes ad hoc para que los usuarios puedan crear un informe desde cero sobre la marcha. Ahora, nuestro modelo de datos es muy complejo y requiere un buen conocimiento práctico para tener sentido. Hacer esto como mínimo requeriría una buena cantidad de trabajo para llevar el modelo de datos a un esquema que sea "más informable" y más fácil de entender. No creo que nuestra aplicación sea adecuada para informes ad hoc (no vale la pena).
¿Alguien ha tenido éxito al proporcionar informes ad hoc? ¿Qué conjunto de herramientas usaste? ¿Tuvo un impacto en el éxito de su aplicación?
He visto muchas fallas costosas. Tuve un socio comercial inclinado en este molino de viento durante años. Su dificultad fue su insistencia en que las personas "no técnicas" puedan crear informes. Creamos una serie de soluciones que las personas pudieron aprender y utilizar con diversos grados de éxito. Al igual que usted, comenzamos con informes enlatados parametrizados.
Luego, hicimos una manera de guardar conjuntos de parámetros y asociarlos con diferentes plantillas de "formato", lo que esencialmente le permite mezclar y combinar sus informes enlatados y publicarlos en otras personas. En realidad, eso fue lo más eficiente que hicimos teniendo en cuenta que se trataba de dos semanas de tiempo de desarrollo (además de un sistema básico de informes enlatados parametrizados) y lo utilizaron con cierto éxito durante años. Era una interfaz de usuario muy simple, pero aún así algunos usuarios realmente no podían construir sus propios informes, simplemente no podían determinar cuáles deberían ser sus criterios. Pero dado que cualquiera podría crear un informe y compartirlo con otra persona, podría simplemente hacer que un compañero de trabajo haga un informe en lugar de tener que ir a algún equipo de MIS y hacer cola.
Sin embargo, seguimos intentando mejorarlo y desperdiciamos cientos de miles de dólares. Crystal Decisions tenía un kit de herramientas bastante elegante como complemento de su producto empresarial Crystal Reports. Esta era la versión 9 o 10. Hace mucho tiempo que fue renombrada, renombrada por Business Objects, pero imagino que todavía hay una versión de la misma. Era bastante costoso y le proporcionó un diseñador web completo para crear prácticamente cualquier formato de informe. También tenía una aplicación de muestra que era más un asistente que lo guió a través de la modificación de un informe existente. Tuvimos éxito con la idea de "guardar y compartir plantilla parametrizada", por lo que esto nos atrajo, ya que fue un paso más allá. Bien, en pocas palabras, realmente no cumplimos. Creo que la herramienta estaba bien, pero lo que estábamos tratando de hacer era demasiado confuso e incorrecto para funcionar.
Durante todo este tiempo, la empresa tuvo que mantener un equipo de desarrolladores de MIS que hicieron muchos de sus informes ad-hoc. Lo mejor que obtuvieron de nuestras cosas fue un informe enlatado un poco más flexible que el mejor de los casos hizo que fuera más rápido desarrollar un nuevo informe enlatado siempre que hubiera otro informe existente que fuera algo similar. Si desea integrar de alguna manera una nueva fuente de datos, olvídalo. Y sobre todo, eso es lo que MIS hizo por ellos fue integrar cada vez más fuentes de datos de una manera descuidada pero muy rápida de comercializar.
Finalmente, comenzaron a utilizar Business Objects, la versión de escritorio de la herramienta de BI. Esto le permite integrar datos locales con datos que descubrió en el catálogo de metadatos en línea. Por lo tanto, podría hacer cosas de producción real para las masas y los quants y los gerentes podrían seguir analizando diferentes conjuntos de datos hacia los que los llevó su investigación. El conjunto de habilidades se volvió aún más raro, ciertamente no era algo que cualquiera pudiera aprender y hacer. Sin embargo, pudieron lograr que mucha más gente lo usara de manera efectiva de lo que podrían permitirse contratar como personas dedicadas de MIS. Sin embargo, el personal de MIS nunca se redujo mucho, lo cual es revelador.
Mi propia impresión de este problema general es que tienes que estar dispuesto a invertir significativamente en el desarrollo de habilidades para las personas que imaginas usando esta herramienta, y tienes que aceptar que no todo tu personal llegará allí. Y si no pueden pasar un par de semanas aprendiendo una plataforma de BI, nunca podrán aprovechar al máximo ninguna herramienta que les brinde. Algunas personas, por el motivo que sea, simplemente nunca parecen tener ideas básicas como las uniones externas. Enormes clases de conjuntos de problemas nunca estarán a su alcance para resolverlos con ninguna herramienta porque no llegan lo suficientemente lejos como para comprender a nivel conceptual lo que realmente están tratando de pedirle a la computadora que haga. Eso no quiere decir que "no puedan" aprender eso, solo que muchos de ellos nunca lo harán.
fuente
Estamos enfrentando esta situación actualmente. En este punto, en lugar de una interfaz de informes ad-hoc, estamos ejecutando una prueba con Excel y Power Pivot. Lo integramos con la barra de herramientas de Excel y permitimos a los usuarios importar los datos directamente y generar informes utilizando esto. Descubrimos que muchos de estos informes ad-hoc eran diferentes de los necesarios en un momento específico para responder una pregunta específica.
En este punto, está funcionando bien, se requirió un poco de capacitación y toma de manos por adelantado, pero el departamento de finanzas lo está utilizando para que, por supuesto, se sientan más cómodos en sobresalir.
Por cierto, si quieres hablar sobre algunos de los detalles de implementación, házmelo saber.
fuente
En un escenario similar en un proyecto que estoy administrando, le ofrecimos al cliente agregar un datawarehouse con una solución OLAP en la parte superior. Para mantener bajos los costos, elegimos PostgreSQL como la base de datos DWH y Pentaho Enterprise como la herramienta de análisis BI / OLAP; elegimos la versión paga porque la herramienta OLAP es mucho más fácil de usar.
Exactamente como dijiste, debes hacer tu análisis para diseñar un modelo de datos que sea adecuado para las necesidades de los usuarios. Nos llevó tres meses desde los requisitos hasta la implementación, y al principio hubo algunos problemas técnicos que solucionar, pero al final el cliente está muy satisfecho con los resultados. Los usuarios ahora crean su propio análisis y, a veces, los usan como informes (exportándolos a PDF). También hay una característica que permite crear informes ad-hoc lo suficientemente simples, pero al menos por ahora la herramienta de análisis es más que suficiente para sus necesidades.
fuente
Cuanto más amplio es el dominio y el tamaño de las empresas que tiene como clientes, tiende a inclinarse hacia personalizaciones, integración de datos e informes ad hoc. Todo se reducirá al costo.
La mayoría de las empresas desalientan las personalizaciones, por lo que cobran tarifas altas por este servicio. Los programadores tienden a ver estas cosas como innecesarias, pero cuando puede ahorrar tiempo y facilitarlo para unos pocos cientos de usuarios, los ahorros se suman.
Para informar, esto crea una oportunidad de cobrar por capacitación adicional. Los informes ad hoc pueden tener una tarifa adicional.
Su trabajo como desarrollador será más difícil. La mayoría de los lugares en los que he trabajado que tenían software de terceros tenían informes personalizados. Para algunos fue fácil porque tenían estructuras de datos simples. Los más grandes / complejos necesitaban informes personalizados porque esa es la forma en que manejan su negocio. Si quisieran hacer las cosas igual que los demás, no me habrían contratado. He tenido que poner algunas preguntas de informes DevExpress en SO.
Depende de las ventas y el marketing para ver si hay una necesidad. No "los informes ad hoc serían geniales", sino "compraría su software porque tiene informes ad hoc". Solo necesita informar a todos sobre la inversión técnica requerida.
fuente
Mi solución es hacer que su aplicación genere algunas hojas de cálculo básicas y permita que los usuarios jueguen con Access hasta que vean lo que quieren.
Un enfoque más sofisticado sería escribir un programa de acceso / vbscript para "actualizar" los datos base, de modo que los usuarios puedan reutilizar sus personalizaciones.
fuente
He hecho un par a lo largo de los años. Como dijiste, con las bases de datos que dependen de ciertos conocimientos de dominio, puede ser muy complicado. Como tal, yo (o el equipo en el que estaba) los desarrollé sin usar una herramienta de informes. Francamente, eran demasiados problemas para trabajar, tratando de introducir toda la lógica necesaria en ellos. Terminas luchando contra ellos tanto como ayudan.
A los usuarios realmente les gusta poder hacer sus propios informes, por lo que diría que definitivamente valió la pena si tienes tiempo para desarrollar dicho sistema.
fuente
La respuesta corta es que puede ser.
Trabajé para una empresa a mediados de los 90 que creó un software que hace exactamente lo que están pidiendo. Tuvimos un buen mercado en la industria farmacéutica, donde los ensayos clínicos significaron muchas consultas e informes, tanto que eliminar a los intermediarios del SI tenía sentido.
Esa empresa fue tragada por otra, que a su vez fue tragada por otra que no sabía ni le importaba qué hacer con el producto.
Aún así, el mundo (oximorónico) de Business Intelligence se basa en parte en permitir a los usuarios finales la capacidad de definir o al menos refinar consultas a los sistemas de datos. Existen herramientas para facilitar esto al usuario. Business Objects (ahora parte de SAP) fue el rey en este ámbito. Luego compraron Crystal. Entonces SAP los compró. Su oferta actual en este ámbito es SAP Crystal Interactive Analysis.
Es un gran esfuerzo: las herramientas generalmente requieren mucho trabajo para configurar sus metadatos y todo eso. Realmente se trata de si sus usuarios REALMENTE necesitan esto: ¿cuál será el ROI?
fuente
Trabajo para un sistema de TI del gobierno que tiene requisitos de informes ad hoc y enlatados. Además, los usuarios querían una solución de informes ad hoc que se sintiera "incrustada" en las aplicaciones existentes, proporcionara capacidades de acceso para ver la información de registro detrás de la salida del informe y proporcionara información completa acceso a la consulta a la base de datos. Los productos de informes específicos generalmente eran solo una página web o MS Excel. Security quería que los informes se integraran con los controles de seguridad JEE existentes.
Después de no encontrar una solución existente en el mercado, terminamos lanzando nuestra propia herramienta de informes ad hoc que hemos utilizado durante varios años. Sin embargo, es costoso de mantener y un esfuerzo para mejorar, ya que no fue diseñado para extenderse más allá de los casos de uso de unión, filtro y clasificación modestos.
Algunos problemas que hemos tenido son similares a los mencionados por otros:
Actualmente estamos evaluando Pull Reports para determinar si puede resolver estos problemas. Nos gusta cómo la interfaz ad hoc brinda a los usuarios una representación visual simplificada del modelo de datos junto con descripciones textuales de tablas y columnas. El hecho de que las selecciones de filtro del usuario estén incrustadas con la salida del informe reduce la preocupación de que los resultados se interpreten incorrectamente.
En cuanto a si todo esto ha "valido la pena" o no: en nuestro caso, la presentación de informes ad hoc ha sido más barata y más fácil de gestionar que el hecho de que el personal técnico gestione la proliferación de informes enlatados. Sin embargo, la pregunta es un poco discutible porque los informes enlatados, tanto con nuestra herramienta de informes interna como con los informes de extracción, generalmente se crean sobre el motor de consultas / informes de la herramienta de informes ad hoc. Es decir, los informes enlatados son solo informes ad hoc con configuraciones preconfiguradas.
fuente