Los errores que debes evitar al diseñar un datawarehouse (2 de 2)

Hola de nuevo, esta es la continuación del artículo anterior en donde repasábamos los diez errores que hay que evitar al diseñar un datawarehouse tal y como recoge el libro de diseño dimensional de Ralph Kimball.

Ya repasamos los cinco primeros, y aquí tenéis el resto. Recordad que se han presentado en orden de importancia, lo que significa que estos cinco son aún más peligrosos que los anteriores y les debemos prestar especial atención.

(Tiempo de lectura: 2 minutos)

Error nº 5: “Antes de comenzar la implantación del datawarehouse, realizar un sesudo análisis de todas las áreas clave de la empresa al máximo detalle. Eso del diseño iterativo es sólo una excusa para no hacerlo todo bien a la primera”

Seamos sinceros, si pretendemos dar en el clavo a la primera nos vamos a equivocar. Sencillamente las casuísticas de las organizaciones son demasiado complejas para intentar entenderlas de forma global en una primera aproximación. La experiencia de los que llevan muchos años en esto nos dice que es mejor empezar con algo más humilde, centrándonos en realizar unas buenas dimensiones consolidadas y unas tablas de hechos iniciales que nos permitan ir diseñando el datawarehouse de forma iterativa a partir de una base ligera pero sólida.

Error nº 4: “No involucres  a los directivos de la empresa hasta que tengas el datawarehouse implementado y puedas enseñar algo tangible. Tu astuto plan será convencerlos cuando vean las maravillas que un datawarehouse ya montado puede proporcionarles”

¿Por qué no haría caso al bueno de Kimball?

Este es uno de mis favoritos. Uno de  los objetivo de un datawarehouse es alimentar una herramienta de BI, la cual se supone que permitirá analizar la información de la empresa para una mejor toma de decisiones por parte de unos fulanos que precisamente son los deberían brindar su apoyo incondicional al proyecto. No hay que lanzar un proyecto de datawarehouse únicamente desde el departamento IT.

Por mucho que tú y tu panda de colegas frikis de IT estéis seguros de que es imprescindible organizar un datawarehouse, NO os lancéis sin el apoyo de la dirección, porque fracasaréis. Si tu CIO no es capaz de convencer del valor estratégico de un proyecto así a la dirección de la empresa, mejor dedicaros a otra cosa. Un proyecto de este estilo va a necesitar de la coordinación de muchos departamentos diferentes, y la definición formal de entidades que en la empresa pueden tener diferentes puntos de vista. Es algo complicado, así que hay que estar seguros de que cuando lleguen los gritos haya una voz que los haga callar.

Error nº 3: “Anima a los usuarios de negocio a que estén constantemente dando feedback sobre el desarrollo e informando de nuevas métricas y fuentes de datos que añadir a las inicialmente analizadas”

Bueno, aquí Kimball y su gente se refieren a que el proyecto de implantación de un datawarehouse no es diferente a otros proyectos de desarrollo de software en lo que respecta a las fases de análisis y caputura de requisitos, desarrollo e implantación. Durante la segunda fase se podrían añadir nuevas funcionalidades a costa de retrasar plazos de entrega, y durante la tercera fase no se puede incluir ningún tipo de funcionalidad nueva.
En la fecha en la que se escribió este libro (2002) el concepto de desarrollo  ágil aún no estaba muy de moda, pero en los últimos años hay determinados sectores que afirman que los conceptos que defiende el manifiesto ágil podrían aplicarse al diseño de proyectos BI. Si fuera así, obtendríamos más flexibilidad a la hora de incorporar nuevas funcionalidades, pero estas no podrían ser introducidas en las fases iterativas de desarrollo. La verdad es que es una metodología muy interesante que comentaré en otro post.

Error nº 2: “Aceptar como primer entregable un datamart clave basado en clientes, como el de rentabilidad por ser uno de los más atractivos y deseados por los usuarios”

Este es un clásico. Una de las metodologías más seguidas a la hora de implementar un datawarehouse es la de abordar un área de negocio de la empresa, modelarla e implementarla para luego pasar a otra, etc. En este supuesto, es de suma importancia elegir bien nuestro primer objetivo.
Podemos estar tentados de empezar un datamart complejo pero de gran utilidad, como el de rentabilidad, ya que por si sólo representa una fuente de información poderosísima para la empresa. Sin embargo, este tipo de datamarts son muy complejos, y abordarlos de primeras suele ser garantía de fracaso. Es mucho mejor comenzar a estudiar la organización desde otros puntos de vista más abarcables, como la parte de ventas, compras, o almacenaje, y sobre ellos (y las dimensiones consolidadas que generen) montar el de rentabilidad más adelante.

Y llegamos al top 1 de los errores en el diseño de datawarehouses según Ralph Kimball:

Error nº 1: “En vez de hablar con los usuarios de negocio finales eliges interlocutores de alto nivel, expertos o consultores que te resumen las necesidades de los usuarios.”

Podemos resumirlo con un “que no te lo cuenten”. Una de las habilidades que tienen que tener los que se dedican a diseñar datawarehouses es la de saber escuchar a los usuarios finales, a los que trabajan con la información y toman decisiones, sean directivos o no. Estos siempre tienen razón, ya que son el músculo que hace avanzar a esa parte de la empresa. Nuestro éxito está directamente ligado a que ellos puedan usar de manera eficiente el modelo de información que les estamos desarrollando. No ignores a los usuarios finales, ábrete paso entre supuestos expertos o jefecillos y lábrate una buena relación con los currelas, verás como merece la pena.

Y con esto termina la serie de los diez errores que recoge el libro de Kimball sobre diseño de datawarehouse. La verdad es que hay algunos obvios, pero otros no tanto, que seguro que merecen una reflexión.

Espero que os hayan servido y os animo a aportar vuestra visión del tema dejando un comentario.