Me parece interesante comentar y transcribir una discusión reciente en un blog de especialistas en QlikView. El tema era el por qué es necesario modelar y construir un Datawarehouse y no sólo construir toda la aplicación de apoyo a la toma de decisiones utilizando sólo la herramienta QlikView, tal como lo promueve el marketing de dicha compañía.
La verdad es que en la mayoría de las empresas no se encuentran las condiciones ideales para que los datos sean utilizados directamente por las aplicaciones analíticas. Es común apreciar problemas de calidad de datos, codificación y/o clasificación de productos o clientes que no concuerdan entre los distintos sistemas, necesidad de transformaciones de los datos, etc.
Para quienes deseen revisar la discusión original pueden verla en este enlace. A continuación menciono lo más relevante:
1.- La gente de marketing de QlikView al parecer siempre olvida que para lograr esa bella forma de visualización y análisis SE REQUIERE de un datawarehouse con diseño sólido y bien construido. Los datos, la mayoría de las veces, no se encuentran disponibles de la forma ideal que muestran las demos.
2.- Usted podrá construir aplicaciones bien integradas con QlikView pero cuando se trata de metadata, mantenimiento, integración desde múltiples fuentes, data lineage, manejo de la historia, se queda corto. Es una excelente herramienta pero debería ser utilizada como un front-end y no como un reemplazo al datawarehouse.
3.- Los datos deberían ser almacenados en un formato neutral respecto del vendedor y de una forma tan abierta como sea posible.
4.- Los datos deben estar disponibles para que sean trabajados por otras herramientas con funcionalidades que requieran los usuarios.
5.- QV replica el efecto Excel. Datos proliferenado en distintos recipientes
6.- Se generan múltiples fuentes de la verdad, algo que debe evitarse en una buena implementación. También terminan generándose Data Marts no integrados unos con otros favoreciendo las múltiples verdades.
7.- Deben considerarse las regulaciones extremas sobre privacidad en gobiernos que piden a gritos datamanagement y arquitecturas sofisticadas que acompañen sus datos y solución de BI.
8.- Carencias de control y administración de Metadata. Un pilar sobre el cual cualquier arquitectura de administración debe estar construida.
9.- En a realidad muchas y especialmente las grandes empresas NUNCA permiten el acceso directo a los sistemas transaccionales lo cual es correcto por lo que se hace necesario construir un datastore y refrescarlo de forma periódica. En la medida que aumenten los datos llegará a ser un reto a la arquitectura del repositorio.
Lo cierto es que QlikView, independientemente de lo innovador de su tecnología y de que no se trata tan solo de un visualizador sino que además posee un poderoso motor que correlaciona la información “in-memory”, es sólo un arma más del arsenal de herramientas que pueden utilizarse para sacar provecho a los datos contenidos en el datawarehouse corporativo.
Es interesante el hecho de que el mensaje de marketing haya sido tan atractivo para los usuarios finales y muchos gerentes de sistemas. El mensaje es no se complique diseñando y construyendo sus datamarts, datawarehouse ni cubos. No gaste tiempo valioso en estas actividades y dé poder a los usuarios finales y construya sus aplicaciones directamente conectadas a sus fuentes de datos. Obviamente aún existe una deuda con los usuarios finales tanto en facilidades de uso de las herramientas BI y capacidades de autoservicio que obtengan como resultado menores tiempos de implementación y mayor satisfacción.
No concuerdo con que sea más demoroso hacer un cubo que una bd in-memory para QlikView. Un ejemplo es Cognos PowerPlay desde sus antiguas versiones. Bastaba indicar los datos fuentes ya sea en archivos planos o tablas de una BD y el wizard de su módulo Transformer diseñaba las dimensiones, jerarquías y con otro click se cargaba el cubo y se visualizaba . ¡Cubos instantáneos más rápido que con QlikView y sin lenguajes propietarios de extracción!.
Los usuarios desean construir sus propios análisis y tener la facilidad de integrar sus datos externos. No desean esperar meses para que sus análisis estén disponibles. Estas aspiraciones las están tratando de satisfacer también empresas como Microsoft con PowerPivot y MS SQL Server 2008 R2 en donde se mezcla el autoservicio de los usuarios finales con la administración de los profesionales de TI.
Lamentablemente los sistemas de decisión no son solo cubos como los de Cognos PowerPlay o bases de datos in-memory como la de QlikView. Necesitamos datos limpios, estandarizados, accesibles en formatos abiertos por las distintas herramientas de software. Necesitamos además la “fuente única de la verdad” la cual no puede estar toda contenida en un solo cubo de PowerPlay o una base de datos de QlikView.
