Director Unidad Business Intelligence ALTRAN SDB.
Profesor del Master “Sistemas de Información e Investigación de Mercados” (ESIC)
jmarce@altransdb.com
(continuación...)
Algunos de los clientes con los cuales he trabajado muy estrechamente disponían de las “maravillosas estrellas”, pero en ocasiones tenían tantas y tantas estrellas que volvía a tener un caos, eso sí, todo era una supuesta solución Data Warehouse, eso sin entrar a valorar la cantidad de proveedores implicados y los correspondientes problemas de integración, los cuales jamás se reconocen en público.
No cabe duda que es mucho más sencillo, y no requiere grandes conocimiento de técnicas de modelización, analizar una posible problemática e implementar una estrella, a otro problema otra estrella y así sucesivamente. Creo que el resultado lo podemos imaginar todos. Pero en algún momento, nuestro cliente, necesitara información cruzando algunas de las estrellas ya diseñadas. Bueno, muy sencillo, creamos una nueva estrella con dicha necesidad. ¿Hemos analizado bien las necesidades? ¿Cuántas estrellas necesitarán? ¿Estamos construyendo de la forma más adecuada? ¿Cuándo terminamos con este ciclo?.
Ante esta última pregunta y para justificar nuestro desarrollo tiramos de las definiciones de libro, y hablamos sobre la evolución del Data Warehouse, de la evolución por iteraciones u oleadas... pongan ustedes el termino deseado. Todo esto es cierto, pero posiblemente con un buen diseño de datos dichas iteraciones no serian tan agresivas y los modelos cambiarían, normalmente, por nuevas necesidades del negocio y no por necesidades de informes. No siempre es necesario solucionar algunas problemáticas a base de “parches” de estrellas.
También es conveniente mencionar que siempre existirán cambios, con independencia del modelo , y que un Data Warehouse no es la panacea de las soluciones, jamás conseguiremos tener controladas todas nuestras necesidades y cubrir todas las necesidades de nuestros usuarios finales. El “vender” un Data Warehouse bajo ese argumento es una de las mejores maneras de convertir el sistema en un fracaso.
No vamos a abordar el motivo de los grandes fracasos del Data Warehouse, llevamos años escuchándolo, pero puedo asegurar que siguiendo una metodología de desarrollo, pensada exclusivamente para este tipo de proyectos, la mayoría de los proyectos habrían salido bastante bien o muy próximo a los resultados esperados
Ya hemos entrado un poco en las profundidades de los modelos de datos. La importancia de un buen modelo de datos es, para mí, imprescindible. Para realizar un buen modelo de datos no existen herramientas que hagan magia y que piensen por nosotros, debemos contar con un autentico experto, capaz de comprender, analizar y adelantarse a las necesidades futuras y que lógicamente sepa plasmar dicha solución en una estructura de datos con capacidades de análisis (OLAP). Creo que a estas alturas no hace falta comentar que es obligatorio e imprescindible la implicación clara y directa de los usuarios finales, los cuales serán los beneficiarios de la solución. Y que las estructuras de datos irán claramente marcadas por los requerimientos y formas de acceder a la información de estos usuarios. Para lograr una comunicación fluida con los usuarios del sistema, existen unas técnicas que nos pueden facilitar la comunicación con ellos, sobre estas técnicas hablaremos en otro articulo.
Volviendo al tema, de nada sirve adquirir el mejor software del mundo cuando no somos capaces de hacer un buen diseño. Podremos tener a los mejores consultores, que sin lugar a dudas, sabrán manejar muy bien las herramientas, pero no ofrecerán un buen resultado si no son capaces de profundizar en las estructuras de datos, es decir, podremos tener el mejor martillo y el mejor clavo que, si no somos capaces de sincronizar los movimientos y colocar bien ambos elementos, romperemos la pared o en el peor de los casos nos golpearemos los dedos con el martillo. (Continúa...)
