archivo

Archivo de la etiqueta: Business Intelligence

Para realizar estudios concretos basados en un foto de los datos en un momento dado del tiempo funcionará cualquier tipo de carga de datos en el Datamart, incluso aquellas que requieran una manipulación más o menos pesada de la fuente o fuentes del dato con carácter previo a la realización del proceso ETL.

El problema está cuando se quiere realizar con regularidad cargas de datos en el Datamart procedentes de dichas fuentes. ¿Cuáles son los problemas?:

– El procedimiento de manipulación de la fuente de entrada debe estar perfectamente documentado para que sea reproducible. En función del equipo de personas que lo vaya a realizar deberá estar redactado con menor o mayor nivel de detalle.

– Generalmente este tratamiento artesanal se produce con fuentes de datos inestables, en el sentido de que lo mismo durante un tiempo nos proporcionan la información en un formato y después, sin control por nuestra parte, nos lo ofrecen en otro, lo que obligará a retocar la documentación del procedimiento de carga e incluso el ETL en el caso de que se ofrezcan datos nuevos o varíe el formato de los mismos.

– Se necesitará que las personas que vayan a realizar la carga de manera periódica, tengan esta tarea reflejada en su plan de operación como otra tarea más a realizar.

Salvo que no haya más remedio debido al interés de manejar y explotar la información procedentes de este tipo de fuentes mi recomendación es que se evite trabajar con ellas hasta que se haya encontrado una solución más sencilla que permita un proceso de carga desde la obtención de la información en el origen, esto obligará a realizar una inversión y a esperar algo de más tiempo para poder trabajar con el Datamart ya que será necesario esperar a tener lista la solución, de esta forma se conseguirá ahorrar esfuerzo y se podrá obtener una solución más sostenible en el tiempo.

Cuando se plantée la construcción de un Datamart es muy importante conocer a priori quiénes se van a encargar de explotar los datos, con qué frecuencia y qué tipo de manipulaciones quieren realizar sobre los datos.

Algunos se estaréis preguntando, ¿eso no debería ser algo independiente a la estrategia de construcción del Datamart ya que te estás refiriendo a lo que es la explotación de la información?. Teóricamente sí, pero en la práctica no lo es.

A todo lo anterior hay que situarlo en el contexto de las estrategias utilizadas en la organización para almacenar y explotar este tipo de información, independientemente de que se tengan en consideración las herramientas que usen y las soluciones ya aplicadas a otros proyectos similares, es necesario que se tenga en cuenta que o se le ofrece al usuario una forma sencilla de obtener la información que precisa o probablemente el esfuerzo aplicado haya sido en vano, es decir, el usuario no sabrá obtener la información que necesita y dejará en desuso la solución que se le haya dado.

Como es lógico y como he comentado al principio es necesario por ello evaluar cómo desea el usuario obtener la información, algunos se conformarán con que se le ofrezcan listados manipulables (generalmente hojas de cálculo), otros querrán algo de más flexibilidad y otros absoluta flexibilidad. Hay que tener cuidado en no caer en la trama de que el usuario diga: “yo quiero tener la posibilidad de construirme mis propios listados”, ya que eso requiere unas ciertas habilidades por parte del usuario y una cierta frecuencia en la obtención de este tipo de resultados (de lo contrario podrá olvidar determinadas funcionalidades que le ofrezca la herramienta de explotación), si los deseos del usuario no van acordes con la realidad es necesario que se le informe de cómo será el proceso real para obtener esos informes, incluso si es posible mostrándoselo mediante un ejemplo, ofreciéndole otras alternativas para que también las valore.

Una vez que se conoce como el usuario quiere explotar los datos será cuestión de analizar si la solución de Datamart utilizada en la organización es la más recomendable y si no siéndolo, resulta necesario estratégicamente situarlo allí, además de valorar otras alternativas acordes también a la realidad de la organización (presupuestaria, entornos, etc…).

Los usuarios son distintos y las necesidades de información pueden ser diferentes, encontrar una solución que satisfaga a todos resulta tremendamente complicado, por lo que es necesario estudiar lo que necesitan para ofrecerles una o varias o alternativas que cumplan sus expectativas.

Alrededor de los datamart se ha creado un misticismo que ha provocado en muchos casos, fracasos en los proyectos y/o en otros la adquisición de productos o de una infraestructura que no es acorde con la realidad de lo que se quiere hacer.

Cuando se quiere construir un datamart acude uno muy rápido a la teoría, pero realmente lo primero que hay que hacer es estudiar el problema a fondo antes de buscar una solución, que puede pasar por el desarrollo de un datamart clásico o académico o por una alternativa más acorde a lo que se quiere obtener. No hay receta mágica, lo primero es estudiar la situación y después en función de eso, tomar decisiones.

Salvo que tengas que trabajar con millones de registros y quieras realizar complejas operaciones con los mismos, no recomiendo que se adquiera una infraestructura propietaria especializada para trabajar con los datos, es totalmente innecesario. Si se quiere, móntese un entorno paralelo al de explotación para no perjudicar su rendimiento (aunque para perjudicarlo y que se note teniendo un entorno de producción medianamente empresarial, habría que darle bastante caña), pero si se tienen ya adquiridas licencias de base de datos lo mejor es aprovecharlas antes de ir a por otro tipo de soluciones. Sé que esto va en contra de la teoría y de lo establecido en el mercado y probablemente muchos de los que leáis esto no estaréis de acuerdo, pero es lo que me dice la experiencia tras haber participado ya en bastantes proyectos de este tipo y haberme tropezado en bastantes piedras.

Dennis MacAlistair Ritchie, es el padre del lenguaje C y creador junto a Ken Thompson del sistema operativo UNIX (casi nada).

Entre sus citas hay una muy interesante relacionada con la calidad del dato (traducción muy libre): “El 20% de los datos que graban los usuarios en los formularios no son buenos” (dado que no he traducido literalmente, pongo la cita en su idioma original: “Twenty percent of all input forms filled out by people contain bad data.”).

No puedo saber si es un 10 un 20 o 50% de la información que se graba, pero la mayoría de los sistemas de información presentan carencias en lo que a la calidad del dato se refiere, lo cual tal vez afecta menos al trabajo del día a día (sacar adelante las tareas que se tienen encomendadas) pero sí que tiene serias repercusiones cuando se quiere explotar o extraer conocimiento de los mismos.

El problema de la calidad del dato no se debe solucionar exclusivamente mediante controles y más controles en los programas, ya que ese exceso de rigidez provocará rechazos en los usuarios, hará más complicada la asistencia que se les ofrezca y además en muchos casos será poner puertas al campo, ya que como todos sabemos hecha la ley hecha la trampa y al final los usuarios terminarán descubriendo cómo se le puede engañar al programa.

Tampoco la solución es dejar plena libertad al usuario, ya que de lo contrario la información sería prácticamente imposible de explotar (una pena, ya que una aplicación con un campo “memo” para que el usuario pueda escribir lo que quiera además de ser tremendamente flexible, barata y fácilmente mantenible, nos ahorraría continuos dolores de cabeza a los que nos dedicamos a esto 🙂 ).

Hay que poner controles, los adecuados, ¿cuánto es adecuado?, la experiencia tiene mucho que decir en este sentido y dependerá de muchas cosas, pero también pasa la mejora de la calidad del dato por la utilidad que el usuario le vea a la aplicación (cuanto más le facilite el trabajo, más interés pondrá y más tiempo tendrá para intentar que los datos que grabe sean los mejores posibles) y por el fondo que vean los jefes al mismo, ya sea por la mejora de la eficiencia de los procesos involucrados o por la posibilidad que se les ofrece de extraer información y/o conocimiento para su gestión a corto, medio y largo plazo.

Uno de los aspectos más importantes a la hora de afrontar el diseño de un datawarehouse consiste en intentar (siempre que las fuentes de datos lo permitan) que determinadas dimensiones sean comunes a los distintos hechos que se definan. De esta manera se podrán confrontar temáticas distintas utilizando como nexo en común esas dimensiones comunes.

Cuantas más dimensiones se compartan más posibilidades de análisis existirá de la información. Si los datos en origen (que es lo más probable) no comparten esas dimensiones, habrá que hacer un esfuerzo en los ETL para intentar ajustarlos a un mismo dominio para aquellas dimensiones que se consideren de utilidad que puedan ser compartidas.

Como mínimo las dimensiones de carácter espacial y de carácter temporal tienen que ser comunes, independientemente de que para algunos hechos el nivel de agregación sea mayor o menor.

De no aplicar una filosofía de relacionar hechos a través de dimensiones comunes, tendremos información organizada en departamentos estanco que si bien pueden analizarse individualmente e incluso obtenerse muy buenos resultados de ella, no permitirá comparar temáticas (o resultará más complicado al no haberse cuidado la coherencia y/o unificación de las dimensiones por las que se quiera realizar la comparación) lo que impedirá en muchos casos extraer un conocimiento que supone un valor añadido al análisis de los hechos de manera individual.

Lo de unificar dimensiones, puede parecer lógico, sin embargo cuando los proyectos de almacenes de datos se complican, se tira en demasiadas ocasiones por el camino del medio y no se tienen en cuenta estrategias tan interesantes como ésta.

Realmente lo complicado de un proyecto de estas características se encuentra en el proceso que da lugar a la construcción del almacén de datos, ya que en ese proceso, como hemos visto intervienen las siguientes tareas:

– Definición (si no existe) de la metodología de modelado de Datamarts y de la estrategia de documentación de los mismos (sobre el aspecto de la documentación, es importante que permita realizar una trazabilidad de un indicador desde la fuente del dato hasta el almacén de datos, e incluso si se explota con listados, cuadros de mando, etc…, extender la trazabilidad hasta los mismos).
– Identificación y priorización de los indicadores.
– Identificación y estudio de las fuentes de información.
– Definición de políticas en la organización que responsabilicen a aquellas personas que tienen que cargar los datos en las fuentes y entregarlas (en el caso de fuentes ofimáticas) a que lo hagan con la mayor calidad y rigurosidad posible (esto será difícil de conseguir para todos los tipos de fuentes, pero incluso conociendo eso es necesario que existan unas instrucciones, ya que de esta forma se conseguirán mejores resultados (aún siendo incompletos) que sin la existencia de las mismas)., que informen de modificaciones en las fuentes del dato, etc…
– Modelado de los datos en el almacén, teniendo en cuenta criterios como por ejemplo: la integración de datos, la facilidad de explotación tanto por herramientas de exploración de datos, como por parte de otras estrategias, como por ejemplo, cuadros de mando, listados, etc…
– Construcción de los ETLs e incluso y en ocasiones de herramientas de preprocesado de las fuentes antes de ser procesadas por los ETL.

Dado que todas y cada una de esas tareas tiene su complejidad, resulta lógico pensar que realmente la dificultad se centra en la concepción y construcción del datawarehouse (o del datamart) y que la explotación, aún siendo importante, no resulta significativa en términos de dificultad teniendo en cuenta todos los obstáculos que hay que sortear hasta tener disponible el almacén de datos.

Como sucede en el caso de los indicadores, el establecimiento de los mecanismos de explotación, también requiere un trabajo importante con el usuario, ya que la estrategia a aplicar en cada caso debe ser aquella que simplifique al mismo la obtención de la información que precisa. Si el usuario no puede obtener los datos que requiere con relativa facilidad, terminará prescindiendo de intentar conseguir de esta manera la información que necesita. De igual manera, resulta muy importante, la realización de actividades de formación, como el establecimiento de mecanismos de soporte.

Construir un Datamart de pequeñas dimensiones es tarea relativamente sencilla, al final, independientemente de la procedencia del dato se consigue construir un ETL y se cargan los datos de la forma más ordenada que se pueda dentro del repositorio de datos.

En muchas ocasiones estos procesos ETL son cocteleras, donde se cogen unas hojas de cálculo por allí, unas bases de datos ofimáticas por allá y también obtendrán datos de sistemas operacionales. Estas cocteleras, si el trabajo se hace bien, funcionarán correctamente, pero el problema está cuando se modifica alguna de las fuentes del dato y sobre todo si no se tiene controlado cuando se produce esa modificación, cuando esto se produce, una o varias entidades de los Datamarts dejarán de actualizarse hasta que se corrija.

Muchos pensaréis, “Bueno, vale, adáptese el ETL a las nuevas características de la fuente del dato y ya está.”, y estaréis en lo cierto, sin embargo, la frecuencia de incidencias de este tipo que se suelen producir sobre un Datamart que tiene un buen número de fuentes de datos de naturaleza ofimática o procedentes de listados ofimáticos generados por un sistema de información, es bastante alta.

Más que soluciones, lo que hay son buenas prácticas, porque si existe la necesidad de una explotación de datos de estas características y existe la posibilidad de hacerlo (es muy importante eso, ya que muchas veces se creen que se poseen los datos que permiten medir indicadores y después no es así o no existe suficiente calidad del dato). Algunas de esas buenas prácticas, en entornos como el descrito (muchas fuentes de datos basadas en soluciones ofimáticas), podrían ser las siguientes:

– Informar a los usuarios que graban datos en herramientas ofimáticas de las consecuencias de variar los formatos en las mismas. También es posible indicarle al responsable de la información que se graba que la información se espera en un determinado formato y que por detrás puede tener la herramienta que quiera y hacerle los cambios que considere convenientes, pero que al final los datos se tienen que entregar en un determinado formato y con la periodicidad que se establezca para las cargas.

– Tener bien documentado todo el proceso que permite la explotación de los datos de un indicador, desde la especificación de la fuente del dato, el departamento que la utiliza, las personas de contacto, un posible cocinado de los datos para adaptarlo al ETL, pasando por las transformaciones que se realizan en el ETL, las secciones del modelo de datos del Datamart que almacenarán los datos del indicador, etc… Y tan importante como documentar, es mantener actualizada dicha documentación (sin documentación o con documentación desactualizada, realizar un mantenimiento de este tipo de soluciones, puede complicarse muchísimo).

– Ser consciente de que problemas como los descritos en este artículo pueden pasar (y van a pasar), por lo que dentro de los servicios de mantenimiento de sistemas, hay que tener en cuenta este tipo de circunstancias.