El éxito del DW lo marca la elección de la herramienta

Análisis de The Data Warehousing Institute

La industria está de acuerdo en los indudables beneficios que se obtienen tras la instalación de un sistema data warehouse. Sin embargo, muy pocos alcanzan a explicar los problemas reales a los que se enfrentan los usuarios al implantar estos sistemas. A fin de poner un poco más claro todo lo relacionado con este entorno, The Data Warehousing Institute ha realizado un informe para poner sobre aviso a los gestores de data warehouses y DSIs de los errores a evitar en un proyecto de estas características.

Los consultores de The Data Warehousing Institute han recogido las opiniones de analistas de la industria y se han basado en la experiencia de directores de proyecto y DSIs para elaborar un informe bajo el epígrafe "Diez errores a evitar por los gestores de data warehousing". A pesar del titulo en la lista aparecen once puntos ya que el Instituto considera que creer que sólo existen diez errores a evitar sería un error más.

1.- Definir una cadena de mando equivocada

The Data Warehousing Institute advierte en primer lugar de la importancia de situar a los distintos responsables de la implantación del proyecto. De esta forma, distingue dos personas por encima del gestor de data warehouse. En la parte superior está un ejecutivo inversor cuyo compromiso es invertir para obtener un uso efectivo de la información. Los presidentes de la corporación, vicepresidentes de marketing y vicepresidentes de I+D suelen ser estas personas. Un buen inversor, sin embargo, no es la única persona situada sobre el gestor de data warehouse en esta cadena. Cuando un proyecto de data warehouse falla, la causa puede en algunas ocasiones ser la consecuencia de la falta de una pieza clave entre el inversor y el gestor de data warehouse. The Data Warehousing Institute denomina a esta persona el conductor del proyecto ya que su misión será mantener el proyecto en la dirección correcta y asegurar que se cumple en el plazo previsto. Un buen conductor debe ser un ejecutivo que cumpla tres requisitos: tener ya ganado el respeto de los otros ejecutivos, mostrar un sano escepticismo sobre la tecnología y ser decisivo a la vez que flexible.

2.- Crear expectativas demasiado ambiciosas

Los proyectos de datawarehouse pasan al menos por dos fases. La primera es la fase en la que se "vende" el proyecto explicando las razones de por qué se debe invertir en él. Un argumento habitual es que se conseguirá un acceso maravilloso a los datos que se necesiten a través de simples herramientas gráficas. La segunda fase es realizar el esfuerzo para conseguir que las expectativas que se han expuesto en la primera fase se alcancen. Sin embargo, no es raro que los directores de proyecto más optimistas expongan en la primera fase que sus data warehouses darán a la plantilla acceso fácil a toda la información que necesiten, cuando la necesiten y en el formato correcto. Junto a esta promesa (implícita o explícita) viene una factura que puede variar entre uno y siete millones de dólares. Los ejecutivos que oyeron las promesas y ven esos presupuestos se asustan, pero conservan grandes expectativas.

El problema es que los usuarios no consiguen toda la información que necesitan. Todos los data warehouses son, por necesidad, específicos de dominio, lo que significa que se enfocan a un conjunto particular de información de negocio. Peor todavía, muchos data warehouses están cargados con un sumario de información no detallada. Si un ejecutivo realiza una petición y requiere más detalles o más información de fuera de ese dominio, la respuesta es a menudo "no hemos cargado la información, pero podemos hacerlo, simplemente costará más dinero y llevará unas cuantas semanas". Ante esto, los ejecutivos sienten una gran frustración que dirigen hacia la persona que les hizo las promesas.

3.- Comprometerse con una actitud políticamente correcta

Un gran error cometido por muchos directores de warehousing es promocionar sus data warehouses con argumentos como: "esto ayudará a los directores a tomar mejores decisiones". Cuando un ejecutivo orgulloso oye estas palabras, la reacción natural es: "esta persona piensa que no hemos tomado buenas decisiones y que su sistema va a mejorarlas". En este punto, advierte The Data Warehousing, es muy difícil que el ejecutivo dé su visto bueno.

Los CIOs que llevan en la industria más de diez años suelen sonreír cuando escuchan las palabras data warehouse. Ellos saben que el objetivo de un datawarehouse es el mismo que impulso el lenguaje de cuarta generación de finales de los setenta, y el delirio de DSS/EIS de los ochenta, dando a los usuarios finales mejor acceso a la información importante. Los lenguajes de cuarta generación han tenido una larga y útil vida, pero DSS/EIS tuvo un rápido crecimiento y una caída también muy rápida. ¿Por qué? Una posible respuesta es que los 4GLs se vendieron como herramientas para conseguir datos mientras que DSS y EIS fueron promocionados como agentes de cambio que mejorarían los negocios y conllevarían mejores decisiones de gestión. Este posicionamiento aumentó los objetivos políticos innecesariamente e hizo enemigos entre los potenciales clientes.

4.- La disponibilidad de la información como único argumento

Algunos gestores de data warehousing inexpertos mandan una lista de tablas y datos a los usuarios finales para que opinen sobre la información que debería estar en el data warehouse. Algunas veces esperan una clasificación por categorías, situando niveles como esencial, importante o necesaria. De esta forma, marginan grandes listas de información útil que aumentan los requerimientos de almacenaje del data warehouse y más importante, disminuye la responsabilidad. No hay que olvidar que los datos irrelevantes ocultan la información importante.

Hacer frente a la necesidad de profundizar a través de largas guías para encontrar el nombre de campo correcto y tener que enfrentarse con múltiples versiones de la misma información, hace que los usuarios se sientan frustrados rápidamente e incluso que dejen de intentarlo definitivamente.

Los datos irrelevantes también llevan a las bases de datos excesivamente extensas. The Data Warehousing Institute hace referencia en este punto a una firma de Chicago, cuyos recursos de mainframe se destinaron a una gran cantidad de programas SAS de análisis. La información cargada fue creciendo, de forma que la compañía decidió bajar los datos a una nueva máquina donde serían mantenidos para los propósitos de análisis. Los usuarios demandaron que cada dato fuera bajado y querían que fuera actualizado cada cinco minutos, aunque finalmente decidieron que serían suficientes las actualizaciones diarias. Desafortunadamente, la base de datos relacional no cargaba bien en paralelo, causando cargas que consumían más de 22 horas por día. Y peor aún, el rendimiento durante las dos horas restantes era desastroso.

5.- Diseñar bases de datos DW con el esquema tradicional

Partiendo de que las metas de los sistemas de proceso de transacciones difieren de los objetivos del data warehousing, los diseños de las bases de datos deben diferir también. En un proceso de transacciones, el objetivo es la velocidad de acceso y la actualización. El data warehouse es fundamentalmente diferente. La meta aquí es acceder a conjuntos (totales, medias, tendencias...). Otra diferencia entre los dos tipos de sistemas es el usuario. En un proceso de transacciones, un programador desarrolla un requerimiento que puede ser utilizado miles de veces. En el data warehouse, un usuario desarrolla la petición y puede utilizarla sólo una vez. Las bases de datos de data warehousing son a menudo desnormalizadas para hacer que sea más fácil navegar por ellas para los usuarios no habituales. Si a pesar de ello la base de datos de proceso de transacciones (con 250 o más tablas normalizadas) es utiliz

Viñeta publicada el 20 de febrero de 1870 en La Flaca n.º 35 Tendencias

ny2 ACTUALIDAD

ny2 Sociedad de la información

Día de la Movilidad y el BYOD Coffee Break