Cómo asegurarse el éxito del proyecto data warehouse

Probablemente habrá oído que una gran parte de los proyectos data warehouse no cumplen las expectativas con las que nacieron, o sufren de retrasos tales que ponen seriamente en entredicho la viabilidad del proyecto. Probablemente habrá oído también mencionar los espectaculares ROI (o beneficio obtenido de la inversión efectuada) de otros proyectos DW. Y, muy probablemente, estará preguntándose cómo conseguir no acabar su proyecto DW clasificado en la primera de las categorías mencionadas. La intención de este artículo es la de proveer de algunas líneas maestras que le ayuden a conseguir un beneficio tangible para su organización, a través de la utilización efectiva de una arquitectura DW.

Vamos a estructurar esta Guía en cinco grandes apartados, los cuales nos servirán para clasificar e identificar mejor los riesgos y las oportunidades del proyecto DW. Estas cinco áreas son: Negocio (o usuarios), Gestión del Proyecto, Datos, Tecnología y Directorio de Información.

Negocio

El aspecto, sin duda, más importante de un proyecto DW es su orientación al negocio. El DW será útil en la medida en que contribuya al cumplimiento de objetivos de negocio. Si no se efectúa esta contribución, lo único que habremos construido será un nuevo sistema de información, probablemente basado en la tecnología más moderna y costosa del momento. Tan importante es este Foco en el Negocio, que la primera regla del data warehousing es:

No comience un proyecto DW sin tener identificada y aceptada la razón de negocio

Identificada quiere decir enunciada de manera clara y mensurable. La razón de negocio debe partir de las áreas de negocio, no de informática. A veces, la razón de negocio se enuncia algo así como: "Obtener información para la gestión de manera más ágil y fiable". Sin embargo, la razón de negocio debe parecerse más a: "Reducir en una tercera parte las inversiones en las campañas de marketing, manteniendo la efectividad", o "Identificar y retener los clientes más rentables y aumentar en un 25% el consumo del segmento de clientes buenos pagadores y con actividad baja", o "Disminuir el fraude en un 40% en los próximos seis meses", etc. Además, esta razón de negocio debe estar validada y aceptada por la dirección y por el área de negocio afectada.

El cumplimiento de esta primera regla tiene varios efectos beneficiosos:

Mantiene el foco en un área de negocio concreta,

Posibilita una mejor defensa del presupuesto del DW,

Permite identificar al campeón del proyecto DW,

Establece una vía firme para la colaboración de los usuarios,

Facilitará la medición de resultados...

...y nos evitará unas cuantas molestias:

El peregrinaje a la búsqueda de un patrocinador del proyecto,

El que el DW no sea utilizado,

Las penalidades de la obtención de presupuesto, etc.

No olvide que el DW orientado a una razón de negocio tendrá impacto en cómo opera su organización y puede incluso cambiar la propia cultura de la misma.

Sugerencia: Escriba este objetivo de negocio y manténgalo en lugar visible para todo el equipo del proyecto. Le será tan valioso como una brújula a un explorador.

Gestión del Proyecto

Otra de las características más diferenciadas del proyecto DW es su naturaleza iterativa. Dado que el DW está orientado a la toma de decisiones con un impacto directo en el negocio, cabe esperar que las necesidades de información cambien en la misma medida y frecuencia en que cambian los escenarios de negocio. Y éstos cambian con las presiones competitivas, las necesidades de los clientes, la situación económica y social, la legislación vigente, etc.

Por ello, el DW está orientado a los datos, no a los procesos. La orientación a los datos permite enfocarse en resolver las necesidades cambiante de información de las personas que utilizan el conocimiento en su trabajo. Así, el proceso de desarrollo de un DW es circular, en lugar de lineal como el clásico ciclo de vida del desarrollo de sistemas (ciclo en cascada), con una implicación de las áreas de negocio es muy superior a lo común en los sistemas transaccionales. Añadamos los retos tecnológicos, la utilización de herramientas de análisis sofisticadas, al necesidad de crear y gestionar un Directorio de Información y las técnicas de modelización de datos totalmente diferentes del clásico modelo ER, y tendremos la segunda regla:

No gestione el proyecto DW como un proyecto clásico de desarrollo de sistemas operaconales. Contrúyalo poco a poco, en iteraciones sucesivas.

La utilización de esta regla permite:

Desarrollar iterativamente el DW, entregando resultados rápidamente y manteniendo/evolucionando las iteraciones anteriores,

Orientar razonablemente las expectativas de los usarios y de la dirección,

Especificar y asignar los papeles y responsabilidades en el entorno DW.

Construir adecuadamente la arquitectura DW, a partir de los sistemas operacionales, mediante un nivel de datos atómicos (la base del DW corporativo), los nivels departamentales (o data marts) y, en su caso, los niveles individuales del DW,

Ser capaces de repetir el proceso, tantas veces como sea necesario..

...y nos evitará los peligros de:

Sobrepasar los plazos de entrega y/o los costes, frustrando las expectativas de usuarios y Dirección.

No ser capaces de gestionar el continuo mantenimiento del DW y la entrega de nueva funcionalidad, etc.

No olvide que, si tiene éxito, el proyecto DW no tiene un final definido. El DW es un camino, no un destino.

Sugerencia: Utilice una metodología única y específicamente diseñada para la gestión de proyectos DW y que esté suficientemente contrastada. Un excelente ejemplo es la metodología IterationsTM. Una metodología será como el mapa que le permita situarse en el terreno y planificar su avance.

Datos

Como se ha mencionado, el DW está orientado a los datos, no a los procesos. Por ello, no es sorprendente (aunque muy a menudo sorprenda desagradablemente a quienes acometen por primera vez un proyecto DW) que el 80% del esfuerzo total se consuma en las tareas de extracción, limpieza, transformación y carga de los datos. Las razones de este porcentaje tan elevado hay que buscarlas en primer lugar en que construir u DW no es copiar simplemente los datos de una a otra plataforma, sino que hay un importantes esfuerzo de modelización de datos y de integración, homogeneización, consolidación y transformación; la segunda razón es la calidad de los datos, que no suele ser la que se espera, sobre todo cuando se utilizan datos históricos o externos. La necesidad de ayudarse de herramientas específicas en la fase de construcción del DW no sería tal si el DW se construyera y .. voilá! Pero, como hemos visto, el DW es de naturaleza iterativa y, para su utilización efectiva, necesita de un Directorio de Información (del que más adelante nos ocuparemos), que hay que construir y mantener. Si no fuera por estas dos características, podría recomendarse el construir un DW mediante programación convencional o con ayuda de algún 4GL. Pero, si la primera implantación del DW tiene éxito, las modificaciones y la solicitud de nuevas áreas de negocio de sumarse al DW aparecen de inmediato. Y cuando los usuarios empiezan a utilizar el DW, necesitan de algún lugar en el que buscar y encontrar lo que necesitan del DW.Y es entonces cuando, el no haber utilizado desde el principio herramientas que ayuden en la automatización del 80% del esfuerzo y en la creación y mantenimiento automatizados del Directorio de Información.

La tercera regla la podemos enunciar así:

Piense en "el día después". Ayúdese desde el principio de herramientas para la extracción, auditoría de calidad,