viernes, agosto 04, 2006

7 Intervenciones para el éxito de un DWH (2ª Parte)

El cuarto punto de intervención está en elegir la herramienta de explotación del DWH.
La cuarta pregunta que os debeis hacer es :

¿Los usuarios necesitan herramientas restrictivas o no restrictivas ?

Usar herramientas restrictivas (es decir herramientas que limitan las opciones del usuario final) sin duda nos ayudará a reducir la complejidad y la ambigüedad semántica, pero nos limitan las posibilidades.

Usar herramientas no restrictivas (es decir herramientas que dan una amplia gama de opciones al usuario) nos permitirán acceder a información menos estructurada, pero son mas complejas de usar por los usuarios y es facil que generen conflictos semánticos.

Obviamente los investigadores detectaron que aquellos que tenian un repositorio simple como DWH (sin datamarts) y que habían tenido éxito habían optado por herramientas no restrictivas, preferian invertir en aprender la complejidad de este tipo de herramientas antes que utilizar una mas simplificada.

Ahora me gustaria hacer una pequeña reflexión: ¿somos conscientes de que cuando utilizamos un Datamart estamos "semiestructurando" nuestros tipos de análisis?. ¿Somos conscientes que al simplificar, al crear dimensiones, jerarquías y hechos de análisis, dejamos algunas manzanas fuera del cesto?.

Unas herramientas que nos simplifiquen la interacción tambien nos harán mas sencillos los tipos de análisis que podamos hacer, perdiendo parte de ese capacidad por el camino. Si nos limitamos a decir "no, mejor todas las posibilidades" entonces introducimos complejidad innecesaria, dificultamos el aprendizaje del DWH, e incentivamos a los usuarios a que busquen la información por otro lado, en algún listado del ERP combiando con un Excel que les pasa su vecino de mesa.

No es lo mismo acceder a la informacion mediante informes realizados en herramientas específicas de BI, diseñadas para el análisis y el reporting (Business Objects, Cognos, MicroStrategy, MIS, etc...), que hacerlo directamente con sentencias SQL. Seguro que con sentencias SQL podemos acceder a cualquier posibilidad que exista en el DWH, pero la complejidad de su uso quizá no merezca la pena.

Por lo tanto este equilibrio entre lo que pierdo de capacidad de análisis y lo que gano en sencillez es vital para el éxito del DWH. Pensad que los usuarios finales son generalmente bastante vagos (lo digo por experiencia) y siempre encontrarán la manera mas sencilla y mas cómoda para acceder a la información.

Desde el punto de vista de las metodologías ágiles, la utilización de una herramienta restrictiva creo que es la más adecuada, ya que la famosa regla del 80-20 se cumple inexorablemente. Quizás podamos dejar un 20% de análisis no típicos que al semiestructurar perderemos, pero el 80% restante lo tendremos con solo el 20% de esfuerzo. ¿Merece la pena aplicar otro 80% de esfuerzo por esos análisis?. Pues generalmente no. Pensad que uno de los principios básicos de las metodologías ágiles es potenciar la puesta en marcha rápida de todo aquello que sea útil desde la perspectiva de negocio, eliminando lo superfluo.

Fijaos que si ya tenemos la información "semiestructurada" en un Datamart, esa pérdida ya la hemos cometido con lo que el uso de la herramienta restrictiva apenas nos quitará juego y nos aportará simplificación del uso y reduccion de la ambigüedad semántica (esto último se consigue al crear el Datamart y luego ponerle una capa de abstracción o semántica o de metadatos con la herramienta de explotación del usuario que escojamos).
Por el contrario, si no tengo la informacion "semiestructurada", es decir, si tengo un repositorio simple, al introducir una herramienta restrictiva estoy poniendo mucho en juego, estoy perdiendo esa amplitud de análisis que precisamente me habian llevado a elegir un repositorio simple. No es de extrañar entonces que los investigadores detectasen que para estos casos se eligieran herramientas no restrictivas.
Podriamos pues deducir, que si tenemos un repositorio con información semiestructurada y elegimos una herramienta no restrictiva, seguramente llegará un momento en que deberemos completar esos "huecos" con información no estructurada, para permitir recuperar esa pérdida de capacidad de análisis. ¿ Esta situación no se parece mucho a la arquitectura HOLAP (Hybrid On-Line Analitical Process) ?.
Obviamente en el artículo no se nombra nada de esto, pero creo que cae por su propio peso, sacar como conclusion el siguiente esquema decisional para el cuarto punto de intervención.
Si alguno de los lectores estais en alguna de estas situaciones me gustaria que lo comentarámos para confirmar este esquema.
Hemos visto el 4º punto de intervención, me he extendido demasiado así que dejaré los tres últimos puntos para la tercera parte de este artículo.

4 comentarios:

Anónimo dijo...

Después de leer los dos post sobre “7 intervenciones para el éxito de un DWH” que me han perecido muy interesante. Me han venido estas reflexiones en la cabeza. Que quizás algunas sean interesantes y otras…


PRIMERA REFLEXIÓN (SOBRE LOS USUARIOS):

Bajo mi perspectiva la reflexión que se hace sobre la implicación de los usuarios finales en el primer post: “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).”

Creo que es esencial para que un proyecto de data warehouse tenga éxito, ya que el equipo directivo generalmente no dedica su tiempo a “cocinarse” los datos, sino que encarga este trabajo a algún de sus ayudantes. Estos serán los usuarios reales del data warehouse. Así que bajo mi perspectiva este perfil de usuario es quien debe comprender realmente que aportaciones y facilidades le aportará trabajar con herramientas de BI sobre un data warehouse. Siguiendo la regla del 80-20 también se puede afirmar que el 80 % de los informes estarán desarrollados por el 20 % de los usuarios (Nombrados los “key users” en mucha literatura especializada).

A partir de esta reflexión creo que se podría concluir que el éxito de un proyecto de data warehouse (como de muchos otros proyectos, tecnológicos o no) es detectar estos key users y convencerles de la las posibilidades, facilidades y mejoras que pude ofrecer la implantación de nuestro proyecto. Creo que en este punto es donde realmente intervine la psicología y la mano derecha de la persona que lleva a cabo el proyecto para detectar y convencer a los “key users” (Este punto se podría considerar la segunda venta).


SEGUNDA REFLEXIÓN (SOBRE LAS HERRAMIENTAS Y LA ESTRUCTURAS DE INFORMACIÓN):

Pienso que las claves a tener en cuenta al crear un data warehouse son tres: la simplicidad y la velocidad de implantación y el convencimiento de los usuarios de veracidad de los datos.

La simplicidad como se apunta en el post “… este equilibrio entre lo que pierdo de capacidad de análisis y lo que gano en sencillez es vital para el éxito del DWH.”. Este característica nos ayudara a convencer a los usuarios de la simplicidad, agilidad y mejora en la calidad de la su trabajo de análisis al usar el data warehouse.

La velocidad de implantación creo que es importante para dirección para satisfacer las ansias lógicas del retorno de la inversión del equipo directivo y por otra parte las no menos preciables perspectivas creadas a los “key users” (generalmente en la fase de análisis). En este apartado las herramientas elegidas son importantes para facilitar el desarrollo rápido (Usar herramientas ETL puede ser otra consideración importante a tener en cuenta).

Por terminar, y en general, muy pocas veces valorada necesidad de convencer los usuarios de veracidad de los datos ya que generalmente al implantar un data warehouse en muchos casos empiezan a aparecer resultados diferentes a los calculados hasta el momento debido a errores en los procesos de calculo antiguos al data warehouse. También aparecen resultados de partes que no se habían analizado anteriormente y que muchas veces sorprenden y hay casos en los que es necesario convencer de la veracidad de estos datos.

Por lo tanto creo que una estructura simple y las herramientas restrictivas son la elección adecuada para que la mayor parte de los proyectos sean un éxito.

Bueno de momento es todo, quizás en otro momento tenga alguna otra idea al respecto que ya haría llegar… ;•)

Un Saludo a todos,

Martí

Jorge Fernández González dijo...

Hola Marti

En tu primera reflexión comentas
" detectar estos key users y convencerles de la las posibilidades, facilidades y mejoras que pude ofrecer la implantación de nuestro proyecto. (..)(Este punto se podría considerar la segunda venta)."

Fijate que estas apuntando el papel de los usuarios desde el punto de vista de una metodología tradicional. Es cierto que en mucha ocasiones hay que volverles a vender la moto para que utilicen los DWH, pero si aplicamos una metodologia ágil, un conjunto de usuarios forman parte del proyecto, con lo que serán ellos los que "evangelicen" al resto de usario. En el post de hoy, en la tercera parte se ve que efectivamente tu visión es muy acertada, pero ¿que pasaria si la mano izquierda que necesitamos la incluimos en una metodología?. ¿No crees que mejorariamos nuestras posiblidades de éxito?.

Con respecto a tu segunda reflexión, la simplicidad y la velocidad de implantacion (dar los resultados lo antes posibles) ¡¡¡tambien forma parte de la metodologías ágiles!!!! Es genial ¿no?.

El problema de convencer que los datos son reales, es cierto, pasa muy a menudon y me lo apunto para ver si reflexiono sobre ello un poco mas.

Un saludo

Anónimo dijo...

Excelente articulo, y felicitaciones por tu blog. Me encanta cuando encuentro blog como este que se concentran en temas muy particulares y afines a mi y mi profesion.

Voy a leerlos detenidamente y me gusto mucho el uso del MindManager que usaste para ilustrar las ideas. Te copiare el concepto :).

Tambien te suscribire a mis lista.
Una vez mas gracias por compartir tu conocimiento. Mi ultimo articulo muy breve esta relacionado al Empowerment y me hace sentido con tus post.

Saludos Cordiales

Javier Urrutia T.
http://MisBytes.wordpress.com

Jorge Fernández González dijo...

Gracias Javier.

Acabo de leer tu articulo y me encanta el concepto de "La crisis del desarrollador líder".
http://misbytes.wordpress.com/2006/08/21/como-delegar-mejor-empowerment/