archivo

Archivo de la etiqueta: BI

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.

Partiendo de la hipótesis de que finalmente vamos a disponer de un listado de indicadores bastante amplio y que será necesario priorizar el conjunto de los mismos con los que vamos a trabajar, ya sea porque se quiera abordar el proyecto con una metodología en espiral o porque el presupuesto para realizarlo es limitado (o ambas cosas), tendremos que aplicar una estrategia que nos permita seleccionar aquellos indicadores que sean más significativos.

Se pueden plantear muchísimas estrategias y ser muchas de ellas válidas para un mismo conjunto de indicadores. No obstante, la que voy a comentar a continuación resulta bastante simple y entiendo que puede ser válida en un gran número de casos.

Consiste básicamente en asignar a cada indicador un valor para la variable importancia y otro valor para la variable complejidad (esta técnica, orientada a la obtención de quick wins, es muy antigua) y establecer unos umbrales para ambas variables, de manera que lo que quede dentro de los mismos es lo que se abordaría en la primera iteración del proyecto.

¿Cómo medir la importancia? Puede haber varias variables que le proporcionen a ésta su valor, como por ejemplo, el hecho de que el indicador permita dar respuesta a más de un departamento de la organización (a más departamentos, más importante) o que mida algún aspecto de negocio crítico o que tiene especial relevancia (lo indicarán los propios gestores). Por este motivo es importante que cuando se hable con los gestores se les pida, que si les resulta posible prioricen unos indicadores sobre otros. Como no siempre se va a poder obtener una priorización, será muy importante la experiencia de las personas que participan en el proyecto, para identificar qué indicadores pueden resultar más relevantes que otros. Otro aspecto importante para asignarle un nivel de importancia a un indicador, se obtiene a partir del estudio de la calidad del dato (no es necesario un análisis en profundidad, ya que los mismos usuarios de las fuentes de información o los responsables de las mismas, conocen aproximadamente la calidad de la información que se graba), debiéndose priorizar aquellos indicadores que tengan más calidad que otros.

¿Cómo medir la complejidad? Pues está relacionado principalmente con la fuente. Si no existe fuente para un indicador, directamente se debe descartar. Si el tratamiento de la fuente del dato es complejo (o la fuente del dato es susceptible de cambiar mucho) o no existe certeza en que siempre ésta esté disponible se le debe asignar una complejidad alta y así sucesivamente. Otro factor que hay que tener en cuenta para la medición de la complejidad lo tenemos en lo complicada que sea la explotación de la información almacenada en el almacén tanto con herramientas de exploración, como con cuadros de mando, listados, etc… (en esto se último también se puede considerar la naturaleza y características de los usuarios que van a realizar dichas actividades de explotación).

¿Cómo definir los umbrales? Antes de definir los umbrales definitivos es conveniente tener realizado el análisis de importancia/complejidad de cada indicador, ya que si se realiza a priori, lo mismo nos quedamos cortos con el número de indicadores que entran dentro de los mismos o lo mismo nos pasamos. Lo mejor es partir de unos umbrales provisionales y ver qué queda dentro de esos umbrales, cuando se realice el análisis y tomar a continuación la decisión de si moverlos o no, adaptando el trabajo a realizar a las necesidades estratégicas, temporales y presupuestarias del proyecto.

En el siguiente artículo comentaré la importancia que tiene la construcción del almacén de datos, por encima de la estrategia de explotación de la información almacenada en el mismo.