El papel del usuario de negocio en el BI Governance (2ª parte) .

Continuando con el papel del usuario de negocio dentro de la gestion y gobierno del Business Intelligence, otro de los puntos en los que su papel es muy, muy importante son:

3) Calidad y acceptación del dato.

Los usuarios deben definir las políticas y criterios ha establecer en lo referente a calidad del dato, así como desarrollar test de aceptación que permitan asegurar que los datos que agregamos y transformamos en información son coherentes y aceptados por laorganización. El peligro de poner en duda los datos se elimina si son los propios usuarios los encargados de definir los test de calidad y aceptación de los datos. Utilizando el símil del pastel, estamos cocinando un pastel con datos, nosotros somos los cocineros, pero es el dueño del local quiencomprará los huevos y la harina, y es él quien probará la primera versión que hagamos del pastel antes de ofrecérsela a los clientes. Si los huevosestan podridos y/o nos hemos pasado con él azúcar, afectará al negocio.

4) Usabilidad y aplicabilidad de la información.

Cada información es extraída para usarla en la toma de decisiones de uno o varios procesos, la forma de aplicarla en el día a día, es crucial para hacer que las herramientas de BI fructifiquen en nuestras organizaciones y maduren hacia organizaciones orientadas al valor.
Saber como aplicar las informaciones de los reports al día a día y conocer las necesidades surgidas en el transcurso de la jornada son cruciales para orientar los sistemas de BI hacia su máximo nivel de aprovechamiento, y eso solo lo saben hacer los usuarios de negocio.

5) Escenarios de recuperación.

¿Que pasa si el sistema cae?. ¿Qué pasa si la plataforma de BI o el Data Warehouse dejan de funcionar?. El diseño de escenarios de recuperación, de como manejar los procesos que tenemos controlados con el BI sin utilizar el BI, de como sacar datos de control de los sistemas operacionales son ejercicios altamente recomendables. Por una parte ayudan a comprender mejor el control de los procesos, por otra tenemos unmapeo directo entre fuentes de datos operacionales e información reportada, y por último nos permite hacer conscientes a los usuarios de la importancia de introducir los datos de forma correcta en los sistemas operacionales.

6) Selección de herramientas de BI.

La llamada "experiencia de usuario" es fundamental si queremos que seleccionar herramientas de BI.


Seguro que se os ocurren muchas mas pero.... a mi ya no, asi que espero sugerencias :-D.

P.S: Tras las críticas de Marc sobre la última imagen espero que esta sea mas de tu agrado, así tambien hago un homenaje a los 40 años de los Teleñecos.

El papel del usuario de negocio en el BI Governance (1ª parte) .

En muchos de mis anteriores post he comentando la importancia de que el proyecto de BI Governance, su ejecución y su mantenimiento sean propiedad conjunta de los usuarios de negocio y de IT. Pero ¿qué es lo que deben hacer?. ¿Cuál es su papel en los diferentes órganos de gobierno del BI?. ¿Qué grado de implicación necesitamos para garantizar el éxito?.
De todas estas interesantísimas preguntas hoy solo responderé una, bueno de hecho solo media ya que este post lo he partido en dos partes porque sino es muy largo. y así me va bien para generar suspense, a ver si así comentáis algo.

Funciones a desarrollar por los usuarios en el BI Governance.

1) Modelo de datos: El papel de los usuarios en esta fase del diseño de los sistemas BI y en su posterior implantación, es fundamental, explicar las preguntas del negocio a los Arquitectos de Datawarehouse y revisar conjuntamente si el modelo ayuda a responderlas es una de las misiones clave de los usuarios de negocio. No solamente se trata de decir cosas a ver si los consultores por un casual entendemos lo mismo, sino que se trata de enunciar las preguntas clave de los procesos de negocio y definir su aplicabilidad al día a día del control de los procesos. El usuario no debe ser simplemente un "emisor de requisitos funcionales", sino un transmisor de la usabilidad del modelo en el trabajo diario del resto de compañeros de área. Es el propietario del modelo de datos que ha encargado a un sastre, pero de él es la responsabilidad de detectar si el modelo sigue adapatándose en el transcurso del tiempo o si por el contrario hay que hacer reajustes que se adapten a las necesidades cambiante


2) Definición de estándares: El conocimiento colectivo del control de un área funcional de cualquier organización se basa en los indicadores sobre los que reporta su actividad, los informes que maneja y los análisis que realiza cuando algún indicador va mal. Alguna otra vez he hablado sobre la importancia de tener registrados los análisis particulares de cada persona, la forma en la que accede a la información y los caminos analíticos que crea en la ejecución de su labor. Documentar y estandarizar cada una de estas partes nos permitirá hacer crecer el nivel de madurez de los sistemas decisionales de nuestra organización.
Así la segunda de las funciones a desarrollar por el usuario de negocio es definir estandarizaciones en el acceso a la información y en las formas de analizar, creando estándares para:

• Categorizaciones de conceptos.
• Definiciones de indicadores, métricas, índices, etc...
• Estructuras de carpetas.
• Caminos analíticos.
• Reporting corporativo por área de negocio.
• Nomenclatura.

En definitiva, estandarizar el uso y distribución de la información .

En el siguiente post hablaré de la importancia del usuario de negocio en la integración y la calidad del dato.

Y para aquellos que estes atentos como podeis ver un papel tan relevante del usuario nos acerca cada vez mas al Agile BI Governance.

IT y Negocio: Seamos amiguitos

Interesantísimo articulo de Maria C. Villar, Theresa C. Kushner, titulado "4 Steps to Create an Effective IT and Business Partnership" que podéis consultar aquí.

Me ha encantado el hecho de olvidarse del término alineación de IT con el Negocio, nada de alinearse, lo mejor es ser amigos de los usuarios de negocio, comprenderles, y formar un equipo. Muchas veces os he hablado del BI governance como vehículo catalizador que reducirá el gap IT/Business con lo que el planteamiento de Maria y Theresa me ha encantado.

Parten de la siguiente premisa: La identificación y definición de los datos críticos de negocio requiere de una fuerte alianza entre el negocio y las IT. Ambas organizaciones deben ponerse de acuerdo sobre cómo los datos se crean, se actualizan, se controlan, se informan, se eliminan y se archivan. Hay por tanto que establecer una relación de éxito entre ambas partes.










Son 4 los pasos que hay que seguir para conseguirlo.

• Paso 1. Conocerse mutuamente.
• Paso 2. Desarrollar una relación.
• Paso 3. Definir roles y responsabilidades
• Paso 4. Establecer comunicación regularmente y de forma abierta, sincera.

El artículo se basa sobretodo en la gestión y la calidad del dato, pero es perfectamente extrapolable a la gestión de indicadores analíticos.

Uno de los puntos en los que estoy mas de acuerdo es a la hora de establecer comunicación de forma abierta con los usuarios de negocio:

• Soñando el mismo sueño, todos tenemos que tener los mismo objetivos, remar en la misma dirección
• Eliminando las capas de interferencia, muchas veces se ponen "personas intermedias" que trasladan las necesidades de negocio a los de IT. Esto hay que eliminarlo, se necesita un contacto directo para que ambos mundos se pongan a trabajar como partners, se necesita incentivar el contacto entre ellos, se necesita hacer sesiones de "un día en la vida del comercial" o "un día en la vida del analista de Business Intelligence" para que nosotros veamos lo difícil que es vender y que ellos vean lo difícil que es transformar datos en información y en indicadores.
• Confiando en que cada uno hará bien su tarea "confía en que el cocinero cocine", que nadie este constantemente metiendo las narices en el trabajo del otro.

La verdad es que me ha gustado mucho el enfoque que le han dado a la alineación y creo que esta muy en linea con las metodologías ágiles y la vuelta a la confianza en las personas para llevar al éxito a las organizaciones.

Crystal Methodologies y los equipos de desarrollo

Hacia mucho tiempo que no revisaba Crystal Methodologies, no se trataba de una única metodología sino de un conjunto de ellas centradas en las personas que tienen que desarrollar el software, el equipo es la base de estas metodologías creadas por Alistair Cockburn.

La idea de este planteamiento creo que es muy acertada, no es lo mismo cocinar para cuatro personas que para veinte, no es lo mismo planificar un fin de semana para dos personas que para cuarenta, entonces ¿porque utilizamos la misma metodología para un grupo de tres desarrolladores que para un grupo de quince?. Desarrollar aplicativos ha de ser como un juego en el que todos cooperan, aportan su parte de invención y se comunican, ¿porqué olvidamos esta parte en las metodologías de desarrollo?.

El equipo de desarrollo es el factor clave y solo está limitado por los recursos a utilizar. Mientras mejor sea su comunicación e inventiva, mejor aprovecharán estos recursos. Crystal establece una serie de políticas de trabajo en equipo (Methods) orientadas a fomentar la mejora de estas habilidades. Dependiendo del tamaño del equipo se establecía una metodología u otra designadas por color. Crystal Clear para 3-8 personas, Crystal Yellow para 10-20 personas, Crystal Orange para 25-50,…)Como todas las metodologías ágiles, se basa en ciclos iterativos de desarrollo incremental (de 1 a 4 meses máximo), a lo que añade una reunión previa y posterior al ciclo, en la que reflexiona sobre el proyecto y sobre como ha ido ese ciclo. Antes de comenzar el siguiente ciclo al menos dos usuarios finales deben revisar, de forma independiente, lo desarrollado y validarlo.

De este planteamiento inicial, de Alistair con el tiempo solo se ha desarrollado en profundidad Crystal Clear, de la que recientemente se ha publicado un libro; Crystal Clear: A Human-Powered Methodology for Small Teams

Pero realmente es un lástima, porque la idea de una metodologia adaptativa por tamaño y experiencia del equipo no creo que sea una nada mala solución para los sistemas de Business Intelligence.

Dos nuevos blogs

Hoy me gustaria presentaros dos nuevos proyectos que empiezan estos dias sus singladuras por la web y que tienen pinta de que van a dar mucho de que hablar en los próximos meses.



El primero es Caribis, Inteligencia de negocio y pensamiento sistemico, el blog que ha comenzado mi amigo Carlos Luis y que espero que se lance a compartir todo el conocimiento que posee con todos nosotros.

El segundo me llega a traves Xavier Albadalejo, se trata de un proyecto de mas recorrido, no tanto un blog como un portal de conocimiento basado y centrado en enseñar y aprender SCRUM. Se trata de Proyectos ágiles una web que acaba de nacer y que creo que puede ser una referencia de las metodologías ágiles en España y Latinoamerica.

A ambas iniciativas les deseo mucha mucha suerte.

¿Improvisar en Business Intelligence?

Esta es la pregunta que me hago tras leer el curioso articulo de Jørgen P. Bansler y Erling C. Havn de la Technical University of Denmark, titulado "IMPROVISATION IN INFORMATION
SYSTEMS DEVELOPMENT".

Lo mejor de los conciertos de Jazz se da en el momento en que los músicos deciden improvisar sobre las piezas de música que estaban interpretando, dando lugar a una nueva composición que generalmente es lo mejor de la noche. ¿Por que no improvisar entonces?.

Para ello revisan lo que debería ser el concepto de improvisación aplicado a las organizaciones, entendiendo que


1) La improvisación ha de ser deliberada, entendiendo que es el resultado de esfuerzos intencionados en nombre de la organización o de sus miembros.
2) La improvisación ha de ser extemporanea, es decir ha de funcionar sin un plan preestablacido, sin guias y sin métodos.
3) La improvisación ocurre durante la acción, igual que en el jazz, se actua sobre el problema tal cual surje sin analizar previamente.
4) La improvisación requiere de la preexistencia de un conjunto de recursos, puestos por la organización para un plan de acción sobre el que surge la improvisación consumiendolos a modo de bricolage (como McGyver).

El caso de estudio es sobre un proyecto web, pero mi pregunta es... ¿lo podemos aplicar al BI?.

¿Podemos añadir la improvisación a nuestros proyectos sin sentir un poco de vergüenza a la hora de decirlo?, Por que estoy seguro que muchos habeis improvisado sobre la marcha en algún proyecto según aparecían los problemas.

¿Y las metodologías ágiles? ¿Son mas proclives a incluir la improvisación?.

Ahí os dejo el guante.

Otras voces en Business Intelligence y Metodologías ágiles

Al final en la encuesta ha habido un empate entre este tema y el de consejos de dirección de BI, pero por alguno hay que empezar.

Como todos sabeis desde hace tiempo estoy investigando esta relación desde el punto de vista de académico en mi tesis doctoral. Siempre he creido que existe una relación clara entre las necesidades del BI y el enfoque de esta metodología de gestión de proyectos. Hace tiempo la gente me miraba mal por decirlo, pero ultimamente estan saliendo otras voces que también abogan por este enfoque. Uno de ellos es Karthikeyan Sankaran, que tiene un blog que os recomiendo en la versión en ingles del B-Eye Network. Recientemente Karthikeyan ha presentado un excelente paper (agradezco que me lo haya remitido tras solicitarselo) titulado "Agile Framework for Business Intelligence". Y del que podeis ver aquí un resumen.

Me encanta que otras voces empiecen a hablar de esta relación, y felicitar a Karthikeyan por su aportación. Al menos ya no estoy solo. :-D

Agile BI Governance

Feliz 2008
Últimamente he estado muy liado con mis temas profesionales, y con la propuesta de proyecto de tesis. He estado redactando y escribiendo mucho orientado para poder defender mi propuesta de tesis y ver si el tribunal que evalúa los PT da su aprobación para que pueda dedicar dos años mas a desarrollar la tesis doctoral. De momento, hoy he hecho el depósito y espero que pueda defenderlo a principios de febrero y obtener el DEA (Diploma de estudios avanzados). En fin esas cosas de los doctorados. :-D. El caso es que despues de 4 años de esfuerzo, al final estoy en el primer checkpoint. Como dice mi codirector de tesis y amigo el Dr. Enric Mayol... "Jorge.....ya has puesto el huevo".

¿De que vá?, pues de lo que todos ya sabeis, de mezclar metodologías ágiles y gestión de proyectos de BI, de aplicar los principios ágiles al BI Governance.

Fruto de este trabajo, voy a publicar dos artículos, uno en Novatica y el otro en GdR.

El primero habla de BI Governance desde el punto de vista mas formal, ligado a las metodologías de IT Governance, gracias a la influencia de Antonio Valle. mi gran mentor en estos temas.

El segundo habla de mí visión del BI Governance, lo que he llamado Agile BI Governance y que en una primera definición del concepto ha quedado mas o menos así.

Agile BI Governance es el proceso de definición y ejecución de la infraestructura que prestará apoyo a los objetivos de empresa. Es propiedad conjunta de Tecnologías de la Información y de las diferentes unidades de negocio, y se encarga de dirigir el proceso estratégico de obtención de valor del Business Intelligence en la empresa a través de los valores y principios del Manifiesto Ágil.

Una vez definida, hay que construir un Framework de referencia, y de eso es de lo que hablo en el próximo número de GdR de enero-febrero'08, que os pondre en cuanto este online.

No pagueis el rescate que me he escapado

Sigo vivo.
Como cada final de año, la verdad es que se me acumula la faena y no he tenido tiempo para dedicar al blog, y me sabe muy mal, porque queda muy mal lanzar preguntas al aire y no dar la respuesta.
Eso no significa no haya estado escribiendo, he estado liado con:

• GdR en el ultimo número del año, en el que ademas de mi sección he escrito un articulo sobre " Madurez del BI en las organizaciones" que espero poneros on line en breve.
• Novatica escribiendo un articulo sobre "BI Governance" que aparecera en el especial de febrero sobre IT Governance y entre cuyos editores invitados esta Antonio Valle.
• Proyecto de Tesis Doctoral. Que si todo va bien tendre que defender en enero y si me lo aceptan ya podré por fin escribir mi tesis doctoral titulada "Agile BI Governance".

Pero aparte de al blog le debo varias cosas.

• Felicitaros a todos por el éxito de BI Beers, ya somos 70 personas vinculadas al grupo. Yo no pensé que pasariamos de 30, estoy gratamente sorprendido. Ahora tendriamos que organizarnos por grupos geográficos, si alguien se quiere responsabilizar de una zona, que me lo diga y lo haré administrador del grupo.
• Agradeceros el éxito y el nivel de las respuestas a la pregunta al aire "Que debe almacenar un datawarehouse", tengo pendiente hacer mi post de respuesta, os lo prometo.
• Mirarme a fondo el Triadic Continuum, Jane me ha enviado documentación para poderlo hacer y en cuanto acabe con lo del proyecto de tesis, me pongo.
• Exponeros mi proyecto de tesis, como va a ser y que podais ver en que trabajo y que podais indicarme en que me estoy equivocando, pero eso ya será mas adelante.
  

En fin muchas cosas que quiero compartir con vosotros en cuanto me sea posible.
Ademas veo que ya no soy el único que empieza a defender la relación de metodologias ágiles con BI, os adjunto unos links del blog de Karthikeyan Sankaran que va por mi mismo camino.

BI Implementation Enabler: Agile Framework for Data Warehousing – Part 1

BI Implementation Enabler: Agile Framework for Data Warehousing–Part 2

Pair Thinking para DWH

En una de las metodología ágiles mas extendida la XP ,una de las formas de trabajo que se recomienda es el Pair Programming, en la que un programador codifica y el otro "mira". Algu muy Typical Spanish (:-D).
La verdad es que inicialmente puede chocar, la programación siempre se ha visto como algo solitario, y tener dos personas delante de un solo teclado y de un solo monitor sorprende en un inicio.

La semana pasada estuve en varios de mis clientes, supervisando a los equipos e intentando ayudar en algunos puntos del desarrollo en el que se estaban teniendo algunas dificultades, al final de la semana, cuando volvía a casa reflexionando de como me había ido, me di cuenta de que lo que habia estado haciendo en la mayoria de casos es Pair Thinking y que habia funcionado muy bien.

Si lo pensais las ventajas son muchas; y mucho mas en entornos decisionales, en los que no solamente hay que ver como estructuras los datos, sino en como los interpretará el usuario final.

Pensad en como funciona la mente humana, nos he muy complicado pensar a nivel abstracto y luego pasar a pensar a nivel concreto. Nos es difícil pasar de alto nivel a bajo nivel y si lo hacemos de forma continua acabamos desconcentrados y cometemos errores.

Es por esto que cuando estamos estructurando un DWH primero pensamos la estrategia de estructuración de datos que vamos a seguir y luego nos ponemos a codificar cada una de lso procesos ETL, sin pensar de nuevo a nivel estratégico hasta que no finalizamos alguno de los datamarts o a veces la totalidad del data warehouse, y entonces cuando nos lanzamos con el reporting vemos los errores o las cosas que nos hemos dejado en la estrategia de codificación original.

Pensar a lo grande y en detalle a la vez nos es imposible con un solo cerebro. Pues pongamos dos.

En el Pair Thinking uno de los miembros debe esta pensando a nivel táctico y el otro a nivel estratégico de manera de que esos dos procesos siempre estén activos reduciendo así los errores y mejorando la calidad de la información resultante.

Si utilizamos la gran experiencia de XP en sus roles de Pair Programming y los plagiamos sin ningún tipo de rubor, podemos decir que estos dos roles deberian intercambiarse cada poco tiempo entre los miembros de la pareja para abarcar todas las posibilidades tácticas y estratégicas del diseño del DWH.

El nivel de los miembros de la pareja ha de ser equivalente, no sirve que uno sepa mucho y otro no tenga ni idea, deben de estar equilibrados y obviamente llevarse bien para que tenga éxito. Pero no solamente entre ellos sino también con el usuario final. En el Pair Thinking el usuario final ha de ser contantemente consultado para saber "que espera" y los conocimientos del área de negocios de ambos diseñadores del DWH deben de ser muy amplios o les será totalmente imposible pensar a nivel estratégico.

Así pues, para aplicarlo correctamente necesitariamos dos "Arquitectos DWH" con mucha experiencia en negocio, cosa que es dificil de justificar en un proyecto de diseño a tiempo completo por lo que supone en costes. (si fuera Pair programming sería mas facilmente justificable)

Por eso quizas la mejor aproximación sería la de realizar sesiones rutinarias de Pair Thinking, dentro del ciclo de la metodología de diseño del DWH.

Y esto es lo que, sin darme cuenta, he ido haciendo en los últimos años.

Tres razones para cambiar a metodologías ágiles

Leyendo el post The Risks of Traditional Modeling del gurú del desarrollo ágil Scott W.Ambler

Se me ha ocurrido esta adaptación mas sencilla e igual de impactante.

1.) Reducirás el riesgo de que nadie quiera el software que estas desarrollando o que no esté alineado con el negocio. Si el usuario de negocio está en el equipo seguro que tendrás entre manos una solución que se usará y que finalmente aportará valor.

2.) No darás nada por sentado. En las metodologías tradicionales puedes caer en el riesgo de trabajar bajo un falso sentido de seguridad. Con las metodologías ágiles seguro que no darás nada por sentado, sabrás que te mueves en aguas pantanosas y eso te hará .... reflexionar, hecho fundamental para que cualquier proyecto tenga mayores probabilidades de éxito.

3.) Reducirás el coste del cambio en mitad del proyecto. Con las metodologías ágiles evitarás las decisiones arquitectónicas demasiado tempranas cuando apenas sabes nada del problema, con el riesgo que ello conlleva. Además te facilitan que a mitad del camino puedas decir "ostras la he cagado" y tomar una dirección mas acertada. En las metodologías tradicionales en las incurres en grandes costes al principio de vida del proyecto seguramente te lo pensarás dos veces antes de cambiar de dirección a pesar de que estes en un camnio incorrecto.

Así que como dice Scott W. Ambler,

"[..]esta llegando el tiempo en que nos empezaremos a plantear los riesgos de seguir con una metodología tradicional. [..] ( y los costes)"

¿Quien ha intentado cambiarse?

Green Lantern Methods for Redesign (GLMR)

Despues de darle muchas vueltas, esta tarde he pasado a la accióm. Junto con mi amigo Marti Ibarz, nos hemos puesto a darle forma a una posible metodología ágil de rediseño de data warehouse. El porqué me he decidido finalmente a hacer una metodología propia para este proyecto y no reutilizar ninguna de las existentes, es principalmente el hecho de que la casuística de un proyecto de rediseño no ha de ser la misma que la de un proyecto que empieza desde cero. También me da la oportunidad de probar una metodologia ágil en un proyecto de menor riesgo.

El esqueleto resultante es este que os comento a continuación, y que a partir de ahora voy a llamar Green Lantern Methods for Redesign o acronizando un poco GLMR.

GLMR será un conjunto de métodos que podrán aplicarse a cualquier proyecto de rediseño de aplicaciones, la primera versión, claro esta, será (porque aún no la tengo hecha) la versión para Data Warehousing (GLMR for Data Warehousing) pero animo a cualquiera a que realice su propia versión para proyectos de rediseño en otros ámbitos.

El esquema principal se compone de una primera fase lineal en la que nos haremos una idea de la vision global y de como la evolución del negocio ha hecho que nuestro sistema sea insuficiente para las necesidades de la organización, a esta fase le sigue un ciclo iterativo en el que se rediseñan los datamarts y en el que se obtiene check list de implementacion de funcionalidades y optimizaciones para cada datamart. El proceso finaliza con otra fase lineal en la que se ponen los cambios en marcha y se planifica los criterios que harán que en un futuro se desencadene de nuevo otra reingenieria.


Es una version muy simplificada sobre la que seguiré trabajando, los siguientes pasos que voy a dar implican la definicion de las tareas de cada fase, la documentación resultante (que será la mínima necesaria) , los roles que han de intervenir (donde el usuario final ha de formar parte del equipo con un papel destacado) y las reuniones e hitos de control.

Si, ya lo se, TODAVÍA ESTA MUY VERDE.... je je je (no he podido resistirlo), pero creo que va a dar un buen resultado.

Como siempre admito sugeriencias, aunque ya estoy perdiendo la esperanza :-(

¿Dynamic Systems Development Method para DWH?

Después de descartar SCRUM mi siguiente metodología candidata es DSDM, y creo firmemente que dentro de las metodologías ágiles puede ser la adecuada, a ello me ha llevado mi gran intuición y el white paper llamado "DSDM and Data Warehousing" que yo con pocas pistas enseguida pillo el concepto. ;-D

Veamos un poco de que se trata esto de DSDM

DSDM se ha desarrollado teniendo como ideas fundamentales:

· Nada es construido a la perfección a la primera.

· La vieja regla del 80-20 es cierta ( el 80% de las funcionalidades del proyecto se realizan con el 20% del tiempo, y el 20% restante, los detalles, consumen el 80% del tiempo restante)

· Es improbable que alguien conozca todos los requisitos del sistema desde el primer día.

De estas ideas nace una metodología cuyas principales características son:

· Un proceso iterativo e incremental

· Un equipo de desarrollo con el que el usuario final trabaja conjuntamente.

Este principio me puede ser util para la reingenieria de data warehouse que os comentaba en el anterior post. La idea dominante en DSDM es que tiempo y recursos se mantienen como constantes y se ajusta la funcionalidad de acuerdo con ello. Es decir, la idea no es “¿cuánto me va a costar desarrollar este sistema?” sino que mas bien es “Con este tiempo y estos recursos ¿cuántas de las funcionalidades del sistema puedo hacer. Si hablamos de reingeniria de Data warehousing, seguramente deberiamos preguntarnos: ¿Cuanto podemos optimizar y cuantos nuevos enfoques decisionales podemos añadir a los existentes?

Entiendo que la naturaleza de las preguntas necesariamenta ha de ser específica para el proyeco, pero las dos características princiapels encajan a la perfección en el proyecto que quiero desarrollar.

Sigamos pues por este camino.

DSMD propone cinco fases, las tres últimas son iterativas:

· Estudio de la viabilidad. Lo primero que se evalúa es si DSDM se puede o no aplicar al proyecto.

· Estudio del negocio. Se estudia el negocio, sus características y la tecnología. Debe crearse el Plan de Prototipado (base del DSDM).

· Modelado funcional. En cada iteración se planea se refinan los procesos funcionales del negocio sobre el prototipo

· Diseño y construcción. Aquí es donde se construye la mayor parte del sistema. El prototipo se vuelve apto para su utilización por parte de los usuarios

· Implementación. Pasamos de un prototipo a un sistema de producción. Se entrena a los usuarios para que lo usen..

En el gráfico queda mas claro (pulsad sobre el para ver mas grande)

Ahora el siguiente paso que tengo que dar es estructurar una metodología de reingenieria de DWH basada en DSDM y probarla.

¿Alguna sugerencia de por donde empezar?

¿SCRUM para DWH?

El término SCRUM tiene su origen en el ámbito del rugby, se trata de una posi-ción entrelazada en círculo que toman los integrantes de ambos equipos. El pro-pósito del scrum es el de reiniciar el juego, rápida, segura e imparcialmente, después de una infracción menor o de una detención.

SCRUM es una metodología que nace ajena al desarrollo del software, de hecho sus principios fundamentales fueron desarrollados en procesos de reingeniería por Goldratt, Takeuchi y Nonaka en la década de 1980 y no fueron aplicados al proceso de desarrollo de software hasta 1993 por Jeff Sutherland, siendo formalizada con la colaboración de Ken Schwaber en una presentación en OOSPLA 96.

Eso lo hace muy versatil para desarrollar proyectos de workflow por ejemplo, pero mi duda es si se puede aplicar de forma eficiente a un proyecto de datawarehouse.

A priori, un buen proyecto para aplicarlo sería el de una "reingenieria de un dwh existente", y tengo precisamente tengo una entre manos, asi que voy a decicar este post a "refrescar" los principios sobre los que se basa SCRUM a ver si lo puedo aplicar o no a este proyecto

El Scrum se ha desarrollado teniendo como principios fundamentales:

• Principio de requisitos indefinidos de Humphrey: para un nuevo aplicativo, los requerimientos no serán totalmente conocidos hasta que el usuario no lo haya usado.
• Lema de Wegner: es imposible definir completamente un sistema iterativo.
• El principio de incertidumbre de Ziv en la ingeniería del software: la incertidumbre es inherente e inevitable en el proceso de desarrollo de aplicaciones.

Podríamos decir que Scrum se basa en cierto “caos controlado”, el proceso del ciclo de desarrollo de Scrum parte del conocimiento de que el proceso de desarrollo fundamental del producto esta totalmente indefinido, es incluso caótico, pero establece ciertos mecanismos para controlar esta indeterminación, manipular lo impredecible y controlar la flexibilidad.

Y aqui nos encontramos con la primera pega, SCRUM es segun sus propios autores un.... "Modelo de desarrollo ágil de productos"

"Producto", un dwh NO es un producto que se pueda acabar como ya dije en el post anterior, asi que quizás no sea tan buena idea lo de SCRUM. Pero los principios me parecen muy adecuados. Claro si pensamos en el origen de la metodología es obvio que esta orientada a producto así que no se yo hasta que punto voy a poder aprovecharla.

Pero sigamos viendo, ahora me centraré en el ciclo de vida de Scrum. Este es una analogía de la jugada de rugby de la que recibe su nombre. En Scrum el balón ha de disputarse entre ambos equipos, los jugadores de un equipo se reúnen en circulo y deciden que es lo que van ha hacer, luego se posicionan enfrente del otro equipo de forma entrelazada, con el balón en medio, y comienza la jugada en la que no se sabe que va a pasar, ni quien tendrá el balón ni hacia donde se atacará. El equipo ha de adaptarse rápidamente hacia una jugada ofensiva o defensiva según quien se haya hecho con el balón.

¿Eso me sirve para el rediseño de un DWH? Uy que pinta un poco mal. Si yo ya tengo claro hacia donde tengo que ir, que estructura tengo que optimizar, que usuarios utilizan el sistema y como lo utilizan. ¿necesito esa adaptabilidad tan extrema?. Empiezo a ver que no, pero quiero darle una oportunidad antes de descartarla

En la metodología Scrum se establecen tres fases : pre-juego, juego y post-juego.

En el pre-juego se definen y/o revisan las funcionalidades que ha de tener el sistema, haciendo la lista de funcionalidades que cuando estén completadas podremos decir que el desarrollo del sistema. Dicha lista recibe el nombre de Release Backlog .Una vez hecho esto se elige un subconjunto de estas funcionalidades con el que se va a trabajar el próximo mes, llamado Sprint Backlog y entonces comienza la siguiente fase.

En el juego es donde se desarrolla el Sprint, las reglas de esta fase son sencillas, se distribuyen las tareas para cada miembro del equipo, se trabaja duro y se intentan conseguir el objetivo. Todos los miembros del equipo han de participar en una reunión diaria que en ningún caso deberá exceder los 30 minutos, llamada Sprint-meeting. En esta reunión cada desarrollador debe dar respuesta a tres preguntas:

• Que hizo desde la última reunión.
• Que dificultades se estan teniendo en el desarrollo de la tarea.
• Que va a hacer hasta la próxima reunión diaria.

Al finalizar el Sprint, pasamos a la fase de post-juego, en ella se evalúa la entrega de funcionalidades del Sprint , se ven las tareas pendientes, se evalúa el progreso del proyecto y se redefine el tiempo de entrega del mismo si fuera necesario. En este paso se compara las funcionalidades actuales con el Release Backlog y en el caso de no cumplirse se vuelve a la fase de pre-juego para realizar una nueva iteración. Si por el contrario, sí se cumplen entonces pasamos la creación de la versión final y a la creación de la documentación pertinente.


Pues creo que yo ya lo tengo claro, no me aporta demasiado para una reingenieria de DWH, quizás para un proyecto de DWH nuevo desde cero si que me podría ser útil, pero para una reingeniera de DWH claramente no, porque ya se que funcionalidades ha de dar, y porque no tengo que ir dando pequeñas funcionalidades cada semana, ya que lo tengo bastante mas simple, cuando acabe la reingenieria, desactivaré el antiguo data y conectaré el nuevo data. Y si todo va bien los usuarios no se darán ni cuenta.



Bueno, para finalizar explicaré los roles básicos de SCRUM así os haceis a una idea, os pongo los 4 principales.

• Scrum Master: Es el responsable de asegurar que el proyecto se es-tá desarrollando según las reglas de la metodología Scrum.
• Product Owner. Es el responsable de la lista de funcionalidades (Re-lease Backlog).
• Scrum Team: Es el equipo responsable la organización y ejecución de cada uno de los Sprints.
• User/Customer: Participan en la creación y revisión de la Release Backlog.

Pero a mi me sigue gustando SCRUM, ya que la forma de trabajar que se adopta es muy colaborativa, un equipo de Scrum tiene entre 7 y 9 miembros, a los que se les incentivará para que adopten soluciones ingeniosas y que aprendan de forma conjunta en un ambiente totalmente cambiable pero controlado parcialmente.

A mi, la verdad, me gusta trabajar así. :-D

La metodología como caballo de troya

Uno de los problemas que nos podemos encontrar en las organizaciones es que no estén lo suficientemente maduras para la agilidad como ya comenté en ¿Cuando puedo aplicar una metodología ágil? y en 7 Paradigmas a romper para ser ágiles

Si a esto le unimos la semiestructuración de los procesos decisionales, nos encontramos que para aplicar una metodología ágil en un proyecto de Business Intelligence, tenemos que tener muy claro a que nos estamos enfrentando. Para ello el primer proyecto que se haga de estas características en la organización tiene que tener no solo el caracter de una metodología rigurosa y seria, sino también la característica de "evangelizar", de ser un caballo de Troya que infecte a todos los ambitos de desarrollo de la organización.

Un metodología (que desgraciadamente su autor no ha seguido desarrollando) es el Adaptative Software Development, esta metodología parte de la idea de que las necesidades del cliente son siempre cambiantes durante el desarrollo del proyecto (y posteriormente a su entrega). Cosa que nos viene que ni pintada para los sistemas decisionales

Su impulsor es Jim Highsmith, la novedad de esta metodología es que en realidad no es una metodología de desarrollo de software, sino un método (como un caballo de troya) a través del cual inculcar una cultura adaptativa a la empresa ya que su velocidad de adaptación a los cambios marcará la diferencia entre una empresa próspera y una en declive.

La incertidumbre y el cambio continuo son el estado natural de los sistemas de información, pero parece ser que muchas organizaciones aún no son conscientes de ellos. La idea de “finalizar” un proyecto carece de sentido porque debe seguir adaptándose y con mas razón si se trata de un sistema decisional. Siempre estamos cambiando nuestros puntos de vista.

Así pues tenemos una metodología (mas bien un metodito) con 4 objetivos claros (independientemente de que el proyecto sea un éxito)

1. Concienciar a la organización de que debe esperar cambio e incertidumbre y no orden y estabilidad.
2. Desarrollar procesos iterativos de gestión del cambio.
3. Facilitar la colaboración y la interacción de las personas a nivel interpersonal, cultural y estructural.
4. Marcar una estrategia de desarrollo rápido de aplicaciones pero con rigor y disciplina.El ciclo de vida que propone se basa en tres fases

El ciclo de vida que propone se basa en tres fases

Fase 1: Especulación. Se inicia el proyecto y se planifican las características del aplicativo a desarrollar.

Fase 2: Colaboración. en esta el equipo de desarrollo se encarga de implementar las características

Fase 3: Aprendizaje. En ella se revisa su calidad, se aprende de los errores y se vuelve a iniciar el ciclo de desarrollo y/o se entrega al cliente.

Pero lo importante no son las fases ni nada por el estilo, lo realmente importante es que cambia la semántica de la creación de sistemas de información:

En lugar de analizar, diseñar, implementar, etc.. que es el lenguaje habitual con una semántica de infalibilidad y definitud (creo que me he inventado esta palabra) algo jactante, pasamos a especular, colaborar y aprender juntos y eso creo que es una buena característica para una metodología, sea cual sea su ámbito de actuación.


Por favor no me pongais ningún comentario a esta entrada (estoy probando la psicología inversa a ver si consigo mas colaboración) :-D

¿Cuando puedo aplicar una metodología ágil?

He hablado mucho de metodologías ágiles, y parece que se pueden adaptar fácilmente a las necesidades del datawarehouse, pero aún no hemos visto cuando debemos utilizar un metodología ágil, independientemente de que el proyecto sea o no de Business Intelligence. Cada proyecto necesita de una metodología adecuada a él que le garantice el éxito. Necesita que se adecue no solo a sus funcionalidades a desarrollar, sino además al equipo de desarrollo, a los recursos disponibles, al plazo de entrega, al entorno socio-cultural, la cultura empresarial, etc…

Un buen profesional no debería cerrarse en una metodología de forma ciega, siempre se ha de cuestionar si es la apropiada antes de empezar el proyecto. Pero aún así existen algunas reglas básicas, de “sentido común”, que voy a tratar de resumir en .....



Las Siete preguntas que nos darán la llave de la agilidad.
(No sé que me pasa con el siete, se admite debate) :-D



Pregunta 1 ¿Cómo es de grande tu proyecto?.

Si se trata de un proyecto pequeño y/o con un equipo reducido de desarrollo, de tres a ocho personas, tienes una oportunidad de experimentar con los métodos ágiles

Pregunta 2 ¿Son tus requisitos dinámicos?.

Si te encuentras ante un ámbito de actuación los puntos de vista de análisis estan constantemente cambaindo como podría ser un datamart de fuerza de ventas, entonces la metodología ágil te ayudará a responder a esta variabilidad
Si estas en un ámbito en el que el dinamismo es poco, por ejemplo el análisis de los estados financieros y contables, en el que los KPI son casis siempre los mismos para todas las empresas, quizás no te sea tan útil.

Pregunta 3 ¿Qué pasa si tu sistema falla?.

Si te encuentras en un sistema crítico en el que cualquier fallo involucre grandes pérdidas humanas o grandes cantidades de dinero, por favor no utilices las metodologías ágiles.
Si nuestro Datamart involucra decisiones operacionales a corto plazo por ejemplo en la creacion de un Business Activity Monitoring, mejor asegurarnos el éxito con una metodología orientada al plan.

Pregunta 4 ¿ Tu cliente tiene tiempo para dedicarlo al proyecto?.

Si la respuesta es no olvidate de la metodología ágil haz el tipico contrato legal o mejor no aceptes el proyecto

Pregunta 5 ¿Cuantos perfiles juniors tienes en tu equipo de desarrollo?.

Las metodologías ágiles requieren de una gran madurez, experiencia y una dosis de talento. Deben de ser equipos con gente seniors o semi-seniors. Si tu equipo lo constituyen principalmente novatos lo mejor es que no lo intentes con las metodologías ágiles.

Pregunta 6 ¿Cuál es la cultura empresarial de la empresa en la que se va a desarrollar el proyecto?.

Las metodologías ágiles requieren de cierto ambiente “informal”, que fomente la comunicación de igual a igual. Si la organización en la que se quiere desarrollar el proyecto tiene un alto grado de ceremonia, pomposidad y jerarquías estrictas, no deberías utilizar las metodologías ágiles.

Pregunta 7 ¿Te apetece?
Realmente tienes ganas de probar una metodología ágil, aprender cosas nuevas supone casi siempre un nuevo sacrificio.

Si tu equipo es pequeño y esta formado mayoritariamente por gente con talento y experiencia, si el cliente final está involucrado y no impone barreras de comunicación, si los requisitos son altamente cambiantes, si no es proyecto crítico y no es demasiado grande, y te apetece probar una metodología ágil, no lo dudes, es el momento de experimentar con las metodologías ágiles.

7 Paradigmas a romper para ser ágiles

En uno de los comentarios de los ultimos post Rafa comentaba acerca de los DWH. "No todas las organizaciones son suficientemente maduras para lanzarse a ello...".

Eso me hizo reflexionar sobre la idea de qué debe cumplir una organización para poder abordar un proyecto utilizando metodologías ágiles, que paradigmas se han de romper para tener garantías de éxito en un proyecto de este tipo. El resultado son estos siete puntos (sí otra vez siete, como Los Siete Samurais)

1) Cambiar el estilo de gestión de "orden y control" hacia "liderazgo y colaboración".

Una organización basada en una visión clásica de dar ordenes y controlar al personal, dificilmente podrá asumir un proyecto ágil. Las jerarquías estrictas de jefe-ordena y empleado-obedece, acabn indefectiblemente en situaciones en que las personas se limitan a hacer sus tareas y nada más sin aportar nada por lo que no se le pague. En un organización ágil, el coaching y el liderazgo colaborativo harán que el equipo de lo máximo de si. No queremos un jefe que mande, queremos un lider que motive. No queremos un control, queremos una colaboración.

2) Cambiar la cultura empresarial de "centrada en los procesos" hacia "centrada en las personas".

La visión única de control de procesos de negocio sin tener en cuenta las interacciones de estos procesos con las personas que los ejecutan tiene que desaparacer. Ya lo vimos en el anterior artículo, el éxito está en la interacion de las personas con los procesos y con la tecnología. Si queremos ser ágiles debemos organizar nuestra empresa en torno a las personas, que son las que pueden darnos esa agilidad, esa capacidad de adaptación a situaciones nuevas que no hayan sido previamente pensadas y modeladas en un proceso, pero que son vitales para la supervivencia de una orgnaización.

3) Cambiar la gestión del conocimiento no crucial de "explícito" a "tácito".

El conocimiento de una organización suele estar siempre en los cerebros de sus empleados, las organizaciones tienden a intentar guardarlo de forma explícita, absolutamente todo y al máximo nivel de detalle posible, eso nos deja en la penosa situación de documentar periodicamente nuestro conocimiento y claro no lo haces como lo explicarías de viva voz, porque has de ser formal y explícito. Precisamente este ansia de documentarlo todo, es loq ue ha veces nos corta las alas de la creatividad, perdemos tiempo en documentar en lugar de invertirlo en crear, en adquirir nuevo conocimiento. Prefiero documentar una idea genial en una servilleta de papel y que tener toneladas de documentos repletos de vacuidades.

Obviamente, esto nos deja en una situación bastante comprometida de dependecia de nuestros empleados, pero no nos engañemos, eso SIEMPRE es así, el autentico conocimiento esta en las personas, nos podemos engañar diciendo que no, pero es eso, un simple engaño.

4) Cambiar la comunicación de "formal" a "informal".

Si queremos hacer equipos, que colaboraren , compartan conocimiento, y funcione al unísono, no podemos encorsetarnos en comunicaciones rígidas, formales y llenas de burocracia.

5) Cambiar el rol del usuario final de "importante" a "fundamental".

En las metodologías tradicionales, el usuario o cliente formaba parte de la fase de análisis en la que tomabamos los requisitos del sistema. Con las metodología ágiles los usuarios finales forman parte del equipo de desarrollo y son una pieza fundamental del proyecto. Sin ellos, simplemente no hay proyecto.

6) Cambiar la estructura de la organización de "jerárquica" a "orgánica".

Debemos pasar de un entorno burocrático y altamente formal a una orgnaización felxible, reflexiva, participativa y que facilite la cooperación. Si os fijais las neuronas no están organizadas en forma de arbol jerárquico, sino en forma de red. Cada persona es como una neurano del "cerebro" de la organización.

7) Cambiar los "roles estrictos" por "roles intercambiables".

En la revolución industrial teneia serntido, que una persona se especializase solo en una cosa, pero en la época actual, el poder intercambiar roles y funciones en un mismo proyecto, nos da la posibilidad de desarrollar nuevos puntos de vista y así atacar los mismos problemas desde diferentes puntos de vista. Nuestros empleados crecerán en motivación, en conocimiento y la empresa será mas adaptable.

Seguramente son 7 grandes barreras, pero hay que empezar a romperlas si queremos adaptarnos a los nuevos paradigmas

Modificación del 4/12/2006

Joserra ha escrito este estupendo complemente que no os podeis perder
La confianza y las metodologías ágiles.

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

Con este post terminamos con las 7 intervenciones.

El punto de Intervención 5 es asegurarse de que los usuarios finales saben como aplicar la información extraída del DWH a sus tareas diarias. Si no saben como les puede ayudar el DWH obviamente no lo utilizarán y el DWH caerá en desuso y posteriormente en el olvido. Si no hay que realizar formaciones específicas con los usuarios para garantizar la aplicabilidad de la información.

En esta linea creo que no solo es necesario que los usuarios finales entiendan como aplicar la información a sus tareas diarias, sino que comprendan la globalidad del proceso del negocio (del cual estas tareas forman parte), el objetivo del mismo y las perturbaciones a las que puede ser sometido, tanto internas como externas a la organización.

Tener un mapa conceptual de lo que pueden significar diferentes metricas y valores en el ámbito del negocio es útil, pero si nos limitamos a repetir esa aplicabilidad sin entender el significado global nos arriesgamos a caer en la paradoja que a veces explico en clase la de "Los 12 monos" que repiten un proceso sin comprender el significado de lo que hacen. (El link aprovecho la adaptacion de Antonio Valle de esta paradoja que me llegó hace años por internet y que no se quién es el autor)

El punto de Intervención 6 es asegurarse que la relacion entre el departamenteo de sistemas de información y los usuarios finales es fluida. Si no encontramos con hermetismo por alguno de los dos lados, seguramente la implanción será un fracaso, es mejor retrasarla hasta propiciar un entorno colaborativo.

Fijaos que este punto es plenamente coincidente con las metodologías ágiles en los que los usuarios finales forman parte del equipo del proyecto, participando en las reuniones periodicas, aportando ideas, añadiendo o eliminando funcionalidades, pero como uno mas, no como el usuario al que se le pregunta cuando se tienen dudas y que lo que el diga luego nos servirá de excusa o de salvoconducto.

El punto de Intervención 7 es asegurarse que entre los usuarios finales va a haber uno que conozca muy bien tanto las capacidades del DWH como el uso de las herramientas de explotacion, lo que los autores llaman el "Power User" y a lo que yo llamo "el empollón gafotas" . Si queremos tener éxito en el uso continuo y a largo plazo del DWH es necesario una persona de negocio que explore todas las posibilidades y que ayude e incentive al resto de compañeros. No hay nada como un usuario que consigue maravillas con el DWH para que los demás imiten su camino.

Los autores dicen que si ese perfil no éxiste hay que crearl, en una metodología ágil ese usuario ya se crea durante el proyecto, ya que forma parte del equipo.

Ya hemos visto los 7 puntos de intervención que nos garantizarán el éxito ( o mejor dicho el no fracaso) de un DWH, muchos de ellos tienen coincidencias con las metodologías ágiles como hemos podido ver, con lo que mi propia conclusión de este artículo es que la aplicacion de una metodología ágil en la implantacion de un DWH nos acerca un poco mas al éxito que no las tradicionales.

Cuatro de la siete intervenciones están incluidas ya en las metodologías ágiles.

¿No os da eso qué pensar?

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.

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

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.