Ayer saque algo de tiempo para leerme un artículo que prometía mucho: "Seven Key Interventions for Data Warehouses Success" , articulo de Tim Chenoweth, Karen Corral y Haluk Demirkan publicado en enero de este año 2006 en Communtications of the ACM.
El punto de partida es brillante "The success of data warehouses depends on the interaction of technology and social context [...].The trick is knowning when and how to intervene."
Son las interacciones de la tecnología con el contexto social y corporativo lo que determina el éxito (que se use) o el fracaso (que no se use) de un data warehouse.
¿No os recuerda esto algo?, ¿no es recuerda al primer párrafo del Manifiesto Agil.?
"En este trabajo valoramos:· Al individuo y sus interacciones más que al proceso y las herramientas."
Si estos investigadores tienen razón en su estudio, podremos responder ya a una de las preguntas que me hacía anteriormente: ¿Son aplicables las metodologías ágiles para los sistemas decisionales?
Los tres primeros puntos de intervención los tenemos en el inicio del proyecto del data warehouse. Os lo resumo en este esquema.
Los puntos de intervención 1 y 2 son de sentido común. Si no tienes alguien que esponsorice el proyecto desde la alta dirección o si en su defecto no tienes a los usuarios a favor, difícilmente tendrás éxito con una implementación de DWH o de un ERP o de un CRM. Son puntos de intervención que caen por su propio peso, pero a veces se nos olvidan. De hecho yo no estoy del todo de acuerdo con la posibilidad de seguir con el proyecto con solo un "Champion" de dirección que apoye el proyecto (sin tener en cuenta a los usuarios finales). Soy de la opinión de que hay que buscar el respaldo de los usuarios finales durante las primeras fases del proyecto. Un usuario boicoteador puede hacer muchísimo daño, mientras que un usuario implicado en el proyecto desde el inicio difícilmente echará a perder su propio esfuerzo. Por eso me gusta tanto la posibilidad de aplicar metodologías ágiles en los sistemas decisionales.
Sin embargo el punto 3 ya nos da una nueva visión sobre si es bueno o no el uso de los datamarts multidimensionales o si podemos aplicar un modelo de data warehouse mas al antiguo estilo, al de "Almacén" de datos sin estructurar excesivamente, sin encorsetarlos en unas jerarquías pre-establecidas.
Así pues tenemos dos alternativas de éxito para un sistema decisional, para lo que hasta ahora muchos creen que es él único paradigma válido, el modelo multidimensional, nos encontramos que con aproximaciones mas clásicas y menos elaboradas podemos obtener el mismo éxito.
La pregunta que nos tenemos que hacer es ¿tenemos un amplio abanico de información a la que acceder?, si la respuesta es sí y atacamos con un modelo multidimensional iremos directamente al fracaso. Si por el contrario no tenemos esta necesidad, entonces el modelo multidimensional nos es muy válido.
En las conclusiones del artículo los autores reflexionan que en muchos de los casos estudiados una aproximación simplista y "One-dimensional" llevaba al éxito en la mayoría de casos.
¿A que os recuerda esto?. Al Décimo principio de la metodologías ágiles.
"X. La simplicidad es esencial. Se ha de saber maximizar el trabajo que NO se debe realizar."
Otra reflexión que se me ocurrió mientras leía el artículo es si no tendría relación los usuarios que tienen que acceder a una gran cantidad de información con los perfiles decisionales de los que ya os hablé sistemas decisionales y estilos de tomas de decisión. Por desgracia no encontré ninguna referencia en el artículo que me pudiera justificar que para decisiones estratégicas se necesite este amplio abanico de información, mientras que para decisiones operacionales y tácticas no. La verdad es que tiene la pinta y encajaría perfectamente con mi teoría, pero eso ya es mucho pedir.
Os dejo con estos tres primeros puntos, nos faltan cuatro, pero espero que estos nos den juego para reflexionar.
3 comentarios:
Os adjunto un link vinculado con este post de los amigos de Hispasec
http://www.hispasec.com/corporate/noticias/122
Un saludo
Interesantísimo blog, que acabo de descubrir (y no sé muy bien como).
Despues de diseñar e implantar varios DWH en otras compañías, creo que hay algo que no has tratado y que, viendo el tratamiento que das a otros temas, sería interesante. Me refiero al momento de iniciar el proyecto de DWH. No todas las organización son suficientemente maduras para lanzarse a ello. Me refiero, sobre todo, a madurez de procedimientos y sistemas.
O todo el mundo llama igual a la misma cosa (lo que no siempre sucede) o la ontología entre sistemas no servirá para nada si son los usuarios los que no tienen esa ontología común.
Por otro lado, los sistemas (que, como dices, tienden al caso) tienen también una fase previa a la madurez en que los cambios son constantes y afectan incluso a la definición de conceptos claves. Intentar montar el DWH sobre un sistema aún no estable, suele ser una mala decisión.
Perdona por el rollo, pero seguro que puedes ayudarnos con tus ideas al respecto.
Un saludo
Lo aconsejable, como bien dices, es que el sistema o sistemas operacionales de los que extraes la información estén ya consolidados, estable y lleven un tiempo de rodaje antes de comenzar con un DWH. Pero no siempre es así y a veces necesitamos información decisional precisamente para redefinir esos conceptos claves en la fase de madurez del sistema operacional. En estos casos lo que no hay que hacer nunca son DOS PROYECTOS, por una parte el operacional y por otro el DWH. LO que hay que hacer es vincular en un solo proyecto el sistema operacional y el decisional.
Si son varios los sistemas operacionales que no están en la fase de madurez, lo mejor es esperarte o hacer datamarts completamente aparte (al estilo de antes) uno para cada sistema operacional que sirvan de embrión para un posterior DWH Corporativo. Pero siempre visto desde una solución temporal y motivada por la urgencia.
Con respecto a la "ontología corporativa" yo he visto de todo, lo mas típico son jerarquias de productos totalmente diferentes entre producción, marketing y logística cada una definida desde los punto de vista específicos de cada departamento, codificaciones de producto no únicas... y el famoso concepto de MARGEN que se puede presentar en una gran variedad de formas (con abonos, sin abonos, con gastos indirectos, con amortizaciones, etc...) y todos lo ponen con la etiqueta MARGEN en sus informes de Excel, con lo que las reuniones de dirección se convierten en precisamente lo que tu dices, una discusión constante para entender que ontología esta usando cada directivo.
Para estos caso yo recomiendo un proyecto previo al DWH de Master Data, en el que unifiquen las codificaciones y los criterios, y sesiones de "lenguaje corporativo" con guias de como nombrar a cada cosa por su nombre y que conceptos incluye o excluye. Este ultimo a mi me ha dado buenos resultados, entregar un diccionario junto con el DWH a todos los usuarios.
Un saludo
Publicar un comentario