¿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

¿Qué debe cumplir una metodología de data warehousing.?

Empezaremos el 2007 mirando un articulo de TDWI llamado "Ten Mistakes to Avoid for Data Warehouse Project Managers" realizado en el segundo trimestres de 2005, vale es un poco antiguo pero me sirve para ilustrar dos conceptos sobre la necesidad de un metodología diferente para los sistemas de dwh.

Los 10 errores que podemos evitar que se comentan en el articulo son:

1) Failing to Use a Methodology (uy que bien me viene para el post de hoy)
2) Ineffective Team Project Structure
3) Failing to involve the business people
4) Failing to have application releases
5) Failing to have an active Project Charter
6) Lack of a readiness assessment
7) Inadequate testing
8) Underestimating Dara Cleansing Efforts
9) Ignoring Metadata
10) Being a Slave to Project Management Tools (uy esta tambien me va bien)


La autora es Larissa Moss del Cutter Consortium , que entre otras cosas ha escrito BI Roadmap: The Complete Lifecycle., vamos que sabe de lo que habla.

En el post de voy a comentar los puntos 1 y 10, el primero y el ultimo
Larissa comenta en estos dos puntos cosas como esta:

" (...) They are often surprised to learn that project managers and project teams must consider approximately 920 tasks when developing a data warehouse. Who can rememner 920 tasks?. No one. But everyone can look up 920 tasks in a methodology!"

920 tareas diferentes, intendad poner eso en una metodología rígida y formal o en una de las tradicionales en cascada que hemos estado utilizando para los grandes proyectos operacionales, sin duda solo con la gestión nos ocuparía la mayor parte del tiempo del proyecto.pero eso no es motivo para que no funcione, nos iremos de plazos seguro, pero no funcionar, eso es decir mucho ¿no?... pues no, no va a funcionar por estos dos motivos:

"(...) a traditional methodology does not include cross-organizational business integration tasks"

"(...) a traditional methodology (...) assumes you are building a product and will not evolve or expand over time"

Ok, no podemos utilizar las tradicionales, pero debemos tener una metodología.

¿Que debe cumplir esa metodologia para que sea util en la creación de un datawarehouse?

1) Que este orientada al cambio y no a la consecución de un producto final.
2) Que gestione el proyecto como cross-funcional a la empresa, una data warehouse no es de un departamento ,es de una empresa, y todos tienen que estar implicados.
3) Debe poder manejar multiples subproyectos a la vez y en paralelo (Etl, data cleasing, reports, querys, KPIs, cubos, etc..)
4) Que posea TODAS las tareas a tener en cuenta, no se trata de que se ejecuten todas, seguramente muchas no serán necesarias, pero no tenerlas incluidas lo único que te asegura es que te olvidarás de una critica y luego tendrás que rehacer el trabjo o algo mucho peor
5) Que utilice los caminos críticos, para su gestión. Es decir que tenga sentido común, centrate en las tareas criticas que puden hacer cambiar la planificación, solo replanifica cuando estas se vean afectadas

¿No os parece que una metodología ágil encajaría perfectamente?

Feliz Navidad (un clásico)

Os deseo a todos una Ágil Navidad y que en este Metodológico 2007 tomeis buenas decisiones ;-D

¡¡¡¡FELIZ NAVIDAD Y PRÓSPERO AÑO 2007!!!!

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

Kimball 1 - Inmon 1 (Usabilidad vs Representación)

La "lucha" Kimball vs Inmon es ya de todos conocida, pero quizás no lo sea tanto las aseveraciones y mensajitos que ambos se han lanzado.

Kimball aseguró en 1997 su modelo multidimensional era "la única manera viable de diseñar bases de datos destinadas a su uso directo por parte de un usuario final".

Casi todos le siguieron la corriente, pero obviamente algunos valientes se le tiraron a la yugular entre ellos Inmon en 2000 cuando dijo que si diseñas un DWH desde el punto de vista de análisis de un solo individuo condenas al resto a su mismo punto de vista y que dificilmente en el modelo dimensional puedes incluir información no incluida en el foco original del análisis.

Pero no solo Inmon cuestiona este punto de vista, tambien Haughey en el 2004 comenta que "el mundo no es una estrella" y que el modelo multidimentional no puede representar de forma efectiva escenarios complejos de negocio.

Con lo que el primer gol de lo asigno a Inmon, así pues Kimball 0 - Inmon 1.

Pero mira por donde este grupo de investigadores decide mirar si la aseveración un poco prepotente de Kimball con la que hemos empezado era cierta o no y publican el siguiente artículo:

Comparing the Effect of Alternative Data Warehouse Schemas on End User Comprehension Level
David Schuff
209F Speakman Hall, Fox School of Business, Temple University
Karen Corral
BA297L, W.P. Carey School of Business, Arizona State University
Ozgur Turetken
209G Speakman Hall, Fox School of Business, Temple University

En el que hacen un estudio de como ambos modelos son vistos por los usuarios finales y como afectan ambos modelos a la usabilidad decisional.
La conclusión del artículo (que lo podeis descargar entero) hace que el marcador se iguale a 1, ya que concluye que para usuarios con poca experiencia el modelo dimensional es mucho mas usable y productivo.

Así pues por un lado ganamos capacidad para representar escenarios complejos pero necesitamos usuarios listos y expertos, mientras que por el otro perdemos capacidad de representación pero ganamos que cualquiera pueda usuarlo.

De momento 1-1.

¿Alguien se anima a meter algún gol mas?
¿Creeis que es lícito sacrificar esa capacidad de representación en pro de la usabilidad?.

Tres enfoques para una metodología DWH

Buscando metodologías de BI, me he encontrado con el siguiente artículo:

Data Warehouse Methodology:A Process Driven Approach
Claus Kaldeich and Jorge Oliveira e Sá
Universidade do Minho, Escola de Engenharia
Departamento de Sistemas de Informação, Campus de Azurém
4800-058 Guimarães, Portugal

No es precisamente lo que estaba buscando pero en la introducción hace referencia a los tres enfoques que puede tener una metodología para datawarehouse.
La idea es que el enfoque de toma de requisitos (requeriment-driven approach) no sirve para este tipo de proyectos ya que este enfoque no satisfará las demandas futuras de los usuarios, y los usuarios dificilmente son capaces de definir y explicar como toman sus decisiones.

Así pues, nos brinda tres alternativas, para que nos hagamos nuestra propia metodología.

• Data-Driven approach: Este enfoque deja de lado a priori a los usuarios, los objetivos de la organización y se centra en los datos. En como están estructuraros, en quien los usa, en la forma en que los usan. Se fija en los datos con mayor tasa de acceso, aquellos que se consultan con mayor frecuencia, como se relacionan entre ellos, que consultas suelen venir asociadas. Son los datos los que dirigen el proceso. Es un poco como el doctor House, los usuarios mienten, pero los datos no.

• Goal-Driven approach: Este enfoque se centra en el objetivo de los procesos de la organización y se basa en el análisis de la interación de tanto clientes como usuarios hacen para conseguir dicho objetivo. A partir de ahí establece necesidades de información e interrelaciones entre ellas que darán lugar a la estructura del datawarehouse. Fijaos que este método da lugar una estructura quizás no del todo estructurada, mas al estilo de Inmon que de Kimball.

• Demand-Driven (or user-driven) approach: Este enfoque asume que todos los usuarios conocen la estrategia empresarial y se comportan de forma coherente con ella. Si realmente son ellos los que van a tomar las decisiones, son ellos los que deben dirigir el proceso de creación del datawarehouse. Se empieza con un primer prototipo muy rudimentario basado en los objetivos empresariales y a partir de ahí los usuarios definen las necesidades de información, las preguntas que le van a hacer al DWH, etc.. .......¿no os recuerda de forma clara a las metodologías ágiles?
  

Pero aquí solo estamos hablando de DWH, con lo que hago la siguiente reflexión ....
¿que pasaría si utilizasemos estos tres enfoques en cada uno de los ámbitos de toma de decisiones?

Conclusión:

• Seguramente nos encontraríamos que en las decisiones operacionales el Data-Driven Approach será el mas adecuado, mientras que en las tácticas un Demand-Driven Approach nos dará mas beneficio y obviamente en las decisiones estratégicas el Goal-Driven Approach será el mas útil.

¿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.

Si no eres de Vulcano necesitas Fuzzy OLAP

Como bien dice Angel Agueda en un blog "Inactivad es sinonimo de mucho trabajo"
Así que voy a hacer una pequeña anotación para recordaros que sigo en la brecha, a pesar de que el ritmo no es que yo desearía.

¿Recordamos todos Star Trek? Supongo que si, sabreis entonces que Spock( y todos los de Vulcano), regían sus acciones sobre la más estricta de las lógicas, sin inmutarse ni pestañear, refrexionaba todo cuantitativamente y daba la respuesta más lógica. Mítica es la frase "el bienestar de la mayoria supera al de la minoria y de a uno solo" con el que Spock decide que es más lógico sacrificarse él por salvar a toda la tripulación del Enterprise.

El caso es que su contrapunto en la serie era el Capitán Kirk que tomaba las decisiones sin meditarlas demasiado, con el estómago como quien dice, al mas puro estilo "humano".

Así pues, si fueramos de Vulcano nos serviría perfectamente la estructura OLAP tradicional (como ya comenté en el post Mi cerebro ... ¿un producto cartesiano?), pero obviamente no tenemos esa capacidad y el cosquilleo en el estómago y la intuición a veces tienen un peso más que específico dentro de nuestra toma de decisiones. Eso me recordó que quizás la lógica difusa (fuzzy logic) podría ayudarnos mas que la lógica pura, y que quizás un análisis cualitativo fuera mas adecuado para la toma de decisiones. Sin muchas esperanzas me puse a buscar y ¡oh! ¡Sorpresa! alguien ya estaba investigando en esa linea.

El articulo con el que he topado es

	Fuzzy OLAP cube for qualitative analysis Pavan Kumar, K.V.N.N.; Radha Krishna, P.; Kumar De, S.; Intelligent Sensing and Information Processing, 2005. Proceedings of 2005 International Conference on 4-7 Jan. 2005 Page(s):290 - 295 Digital Object Identifier 10.1109/ICISIP.2005.1529464 Summary: Data warehouse systems enable decision-makers to acquire and integrate information from heterogeneous sources and query very large databases efficiently. Data warehouse provides the users with an online analytical processing (OLAP) facility by which .....

Como siempre de investigadores de la India que cada vez están mas fuertes (o tienen más tiempo libre). El artículo tiene la bondad de no solo teorizar sino de implementar un ejemplo práctico con un cubo de ventas, que si bien es muy limitado si que nos da una idea de como utilizar la lógica difusa en la consulta de cubos OLAP.

El ejemplo con el que juegan es ¿cuando un cliente/vendedor se puede calificar de Bueno, o Medio o Malo? ¿Lo tenemos claro? ¿Es totalmente estricto o dejamos cierto margen de variabilidad?. Pare ello utiliza algoritmos de lógica difusa mezclados con algoritmos de mineria de datos sobre un cubo OLAP. Es una buena aproximación sobre la que seguiré reflexionando.

¿Inmon o Kimball? o cuanto apreciamos la trazabilidad decisional

Despues de un tiempo de silencio (la entrada en septiembre ha sido un poco dura) y tras hablar de ontologías, vamos a bajar de nuevo a la parte de decisiones operacionales y tácticas.
En este ambito la creación de los Datawarehouse tienen dos grandes gurús, por un lado el archiconocido Kimball con su modelo multidimensional, y por el otro el quizás menos conocido pero no menos importante Inmon.

Me he estado leyendo este artículo que la verdad aporta poco y no es mas que una revisión de todos los conceptos de un datawarehouse, pero que me ha servido para reflexionar cual es mi propio de creación de datawarehouse y cual sería el más apropiado para una metodología ágil

MODELING STRATEGIES AND ALTERNATIVES FOR DATA WAREHOUSING

Articulo de Nenad Jukic publicado en communications of ACM en abril de este año.

Y me ha sorprendido comprobar que estoy mas de acuerdo con las tesis de Inmon que con las de Kimball, yo que he sido un fiel seguidor del primero

Aquí podemos ver dos típicas arquitecturas al "estilo Kimball"


El primer modelo es el utilizado en algunas implementaciones MOLAP puras en las que tenemos varios procesos ETL, que se conecta a diferentes fuentes de datos y generamos los diferentes datamarts dimensionales. Son generalmente datamarts independientes entre ellos para el uso de un solo departamento o incluso de una sola persona.


El segundo modelo es el Kimball mas corporativo en el que un proceso ETL nutre un espacio datawarehouse en el que se comparten las dimensiones entre diferentes puntos de vista y en el que los datamarts de cada departamento forman utilizando los hechos y las dimensiones ya establecidas para toda la compañia.



Todo normal hasta aquí y perfectamente de acuerdo con ello, yo mismo he hecho decenas de dwh utilizando el dogma Kimball


Pero miremos ahora el "estilo Inmon"
Coincide con Kimbal en un único proceso ETL que nutra un DWH corporativo, pero el que él nutre no es dimensional es un DWH basado en el modelo Entidad-Relación.
La idea de Inmon es que el modelo E-E mucho mas rico y adaptable que el multidimensional.

Una vez tenemos el DWH E-R corporativo generamos los datamarts dimensionales que queramos, y no solo eso, nos puede servir para crear cualquier otra extracción para cualquier otro sistema decisional, como puede ser para mineria de datos o para sistemas expertos, por ejemplo.

Lo que me gusta de Inmon es que no se cierra a un solo modelo y no solo eso, además su arquitectura mejora la trazabilidad decisional. Con ella podemos desgranar un valor en un KPI hasta una serie de análisis y reports que lo expliquen en detalle, tan en detalle como nos permiten los modelos E-R que tenemos en nuestros sistemas operacionales.

Parece maravilloso, pero el problema es que es mas costoso de mantener y de implementar. El de Inmon es un modelo que mira a largo plazo y para una metodología ágil el largo plazo es secundario. Para adaptarlo y no perder la agilidad de por ejemplo el primer modelo de Kimball, yo he utilizado a veces lo que he llamado la "Starting Area".

Si el proyecto necesita de una trazabilidad que llegue hasta el ultimo nivel de detalle, lo mejor es crear un capa que sea una copia exacta de los diferentes modelos relacionales de los que se nutre el modelo dimensional. Una simple BULK COPY nos servirá inicialmente, no hace falta unificar el modelo E-R de las diferentes fuentes origen en uno solo, eso es demasiado trabajo. La idea es dejar la semilla de una capa relacional por debajo del dimensional y que ambas crezcan de forma conjunta alo largo del proyecto.

Creo que esta sería la mejor opción para una metodología ágil, nos permitirá tener la rapidez del modelo Kimball y la visión de futuro del modelo Inmon.

De la Web Semántica a la Ontología Decisional (2ª parte)

Todo Ontología se compone de tres partes:
1) Clases e instancias de los objetos que la componen
2) Propiedades que establecen relaciones
3) Reglas para modelar el conocimiento y los comportamientos complejos ( Creación, Restricción y Reacción).

Si no aplicamos el último componente (las reglas) obtendremos o bien una ontología ligera o bien una Taxonomia que no es el objetivo que buscamos en principio.

Así pues ,si queremos tener una ontología decisional, ¿debemos utilizar reglas?.

La utilización de reglas nos origina el problema de la capacidad del motor de inferencia, cuando la base de conocimiento sobre la que se intenta inferir es muy grande, los motores tienen graves problemas de escalabilidad, siendo inviables hoy en dia.

• RuleML (http://www.ruleml.org/)es un ejemplo de lenguaje de reglas basado en XML, si la base de conocimiento no es demasiado extensa, funciona perfectamente. Pero...
• ........¿que tipo de toma de decisiones tiene una base de conocimiento relativamente pequeña?. Desde luego las decisiones estratégicas no, con lo que una de mis primeras intuiciones, aplicar reglas basadas en conocimiento en los sistemas estratégicos, parece que se va limitar a ambitos de actuación muy especializados. Mi gozo en un pozo.

La no utilización de reglas nos origina el problema de la poca capacidad expresiva del conocimiento. Hay varias alternativas una de ellas es utilizar lenguajes lógicos que alternen capacidad expresiva y posibilidades computacionales reales, ya que la lógica de predicados de primer orden es intrinsecamente indecidible.

• OWL-DL, reduce las posiblidades expresivas de la lógica de predicados de primer order obteniendo un lenguaje de razonamiento de capacidad exponencial pero que puede ser procesado (ya no es indecidible, aunque es exponencial). OWL-DL tiene la potencia suficiente como para representar un modelo de Entidad-Relacion (E-R) (OWL-DL can represent E-R Models). Actualmente se esta investigando como mapear modelos OWL-DL sobre diagramas UML. Con lo que se nos abriría una via importante para su utilizacion en entornos decisionales operacionales.

La otra alternativa es la utilizacion de ontologías lígeras (sin reglas) pero fortalecidas con "razonadores" que expanden las consultas utilizando una base de datos relacional y por lo tanto todas las capacidades de ejecución y optimización que poseen en la actualidad. Esta alternativa no plantea problemas de escalabilidad, y aunque no es tan purista, posiblemente sea mas fácil de implantar para entornos tácticos y estratégicos.

Así pues ya tenemos una idea de como crear nuestras ontologias decisionales, pero lo que no sabemos es lo fundamental... ¿como le hago una pregunta? ¿me sirve el SQL de toda la vida?. Obviamente no. Existen lenguajes de consulta específicos para atacar a las ontologías, uno de ellos es SPARQL( Un lenguaje de consulta para RDF ). No es el único, exiten otros como RDQL y RQL, pero es el que parece que se convertirá en estándar de la W3C.

Así que ya podemos pensar en que al SQL le ha salido un nuevo compañero de viaje. Sin duda en el futuro los sistemas decisionales hablaran SPARQL.

De la Web Semántica a la Ontología Decisional (1ª parte)

El auge de estudios que se están produciendo entorno a la Web Semántica está disparando hacia la madurez a la Ingeniería Ontológica a pasos agigantados y en el camino se están sembrando una gran cantidad de conceptos que nos pueden servir para definir una nueva forma de entender los sistemas decisionales.

Así que pensando que cualquier analogía es buena, me lancé a leer mas sobre el tema, de entre los articulos que he ido hojeando, dos son los que mas idea me han ido dando y que por suerte os podeis descargar desde la web de Novatica.

Son estos:

1. La Web Semántica: fundamentos y breve "estado del arte" , Luis Sánchez Fernández, Norberto Fernández García [resumen][contenido completo en formato PDF - 285 KB]
2. Recuperación de información en la Web Semántica . David Vallet Weadon, Miriam Fernández Sánchez, Pablo Castells Azpilicueta [resumen][contenido completo en formato PDF - 340 KB]

Si os gusta el tema os recomiendo que os los leais detenidamente y los complementeis con los articulos que Javier Urrutia esta publicando recientemente en su blog con respecto a la aplicacion empresarial de ontologias

El primer paso que tenemos que dar para pasar de la sintaxis a la semántica es dotar a los usuarios de un vocabulario común en el que todos utilicemos las misma palabras con los mismos significados semánticos, eso o bien pedirle peras al olmo. Cualquier de las dos nos vale como utopía.

Eso es imposible y ademas no deseable, para obtener un sistema decisional orientado hacia la semántica, lo primero que debemos pedirle es precisamente que los diferentes tipos de usuarios utilicen su propio vocabulario con sus propias connotaciones de negocio.

Como en la web semántica este requisito es idéntico, la W3C ha creado un lenguaje para representar (y anotar) conocimiento en la web, es el RDF (Resource Description Framework) pensado para anotar documentos web y xml.

Ahora bien, yo me pregunto: ¿como trabajan la mayoria de los Suites de Business Intelligence actualmente? ... pues en entorno web. Todos los informes generados son presentados a través de un navegador, ¿que pasaría si los propios usuarios pudieran dotar de anotaciones que aportasen significado a estos informes?. Y no solo eso, ¿qué pasa con todos esos informes que circulan en documentos word, powerpoints y excel por las empresas (a veces el 80% de la información de caracter analítico y decisional) que pueden ser exportados a xml?. ¿Qué pasaría si el MS Office (por decir uno) te dotase de la capacidad de hacer anotaciones semánticas en tus presentaciones de resultados?. Como veis la capacidad de dotar de semántica a todos nuestros actuales sistemas de análisis esta a punto de ser realidad aprovechándonos de la web semántica.

Existen algunas herramientas que estan saliendo que facilitan la anotación manual (por ejemplo SHOE KnowledgeAnnotator ), pero.... ¿me sirve de algo?. Si tengo que ir informe por informe anotando manualmente, posiblemente me canse o las anotaciones sean de menor valor o rutinarias. Para ello existen sistemas de anotación semiautomáticos como puede ser PANKOW que exploran el documento buscando referencias a conceptos descritos en ontologías.

Con lo que llegamos a mi primera conclusión: La anotación semántica decisional debe tener un caracter semi-automático

Vale, ya tengo anotados todos mis informes y análisis, pero para anotarlos necesito hacer referencia implícita o explícitamente a una ontología, quiera yo o no quiera, y esa ontología si quiero hacer algo con ella debo procesarla y compartirla con el resto de usuarios de mi organización.

Aunque parezca una perogrullada, para tener una ontología debo especificarla antes, pero ¿como las especifico?, yo nunca he creado ninguna y las que utilizo están implitas en mi cerebro, ¿que tengo que poner? ¿por donde empiezo?. No os preocupeis, por suerte hay gente muy lista en todo el mundo y algunos de ellos estan pensando en una metodología para el desarrollo de ontologías. Una de las inciativas mas conocidas es METHONTOLOGY . La siguiente pregunta que me viene a la cabeza es ¿será una metodología ágil o el armatoste de siempre?. La respuesta es.....que es el armatoste de siempre, es del año 1997 y el ciclo que proponen no es que sea demasiado ágil. Así que seguiré buscando por si hay alguna.

Con lo que llegamos a mi segunda conclusión: Necesitamos de una metodología agil para crear ontologías decisionales que puedan ser aplicables al negocio

Tambien necesitaremos herramientas de creación de ontologías decisionales, pero con el tiempo estarán integrads dentro de las suites de BI, Por ahora existen varias en el desarrollo, pero quizás la que esta teniendo mas éxito es Protegé realizado en la Universidad de Stanford

Pero sigamos explorando las caracteristicas que podemos aprovechar de la Web Semántica.

En un sistema decisional, un grupo de usuarios, posiblemente del mismo departamento, deberán compartir una ontología común, pero el resto de usuarios de otros departamentos posiblemente tengan las suyas. El concepto Margen para un departamento es posible que sea diferente del que tiene otro, por ejemplo si incluimos o no incluimos los abonos o los impuestos, pero en el informe se utiliza la misma palabra y cada uno entiende el concepto según su ontología.

Obviamente, si no queremos nichos de información aislados y pequeños Reinos de Taifas Reinos de Taifas , estas ontologías deben poder relacionarse. para ello nace una linea de investigación llamada onthology mapping que trata de resolver el problema de detectar qué dos conceptos definidos en dos ontologías se relacionan entre si de alguna manera o si son el mismo concepto.

Con lo que llegamos a mi tercera conclusión: Necesitamos mapear las diferentes ontologías decisionales, no solo por departamentos sino también por tipología de decisión (operacional, táctica, estratégica) aunque esto último es mas una intuición que una conclusión sólida.

Y como se me esta haciendo muy largo, dejaré para otro el siguiente post los motores de inferencia y las reglas decisionales.

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.

Intermedio por paternidad

Hola a todos. Finalmente mi hijo nacio el 18 de julio. Tanto la mama como el están bien, en casa, recuperándose. La verdad es que es un niño precioso, por suerte sale a la madre.

Entre medio de esta borágine, los amigos de Todo Bi publicaron un articulo mío publicado originalmente en la revista Data Ti con la que llevo ya 5 años colaborando.
Os adjunto el link de Todo Bi por si os lo quereis descargar.
http://todobi.blogspot.com/2006/07/articulo-bajo-el-paraguas-del-business.html

En breve publicaré otro comentario sobre un articulo muy interesente de profesores de la Universidad de Arizona, que me estoy leyendo entre pañales y biberones.

Sistemas decisionales y estilos de toma de decisiones.

Acaba de caer en mis manos un articulo de la Harvard Deusto Review de mayo de este año que no tiene mala pinta.

"El estilo de toma de decisiones de los directivos experimentados "

ABSTRACT: El trabajo de un directivo consiste, ante todo, en tomar decisiones. En cualquier momento de cualquier día, la mayor parte de los directivos participa en algún aspecto de la toma de decisiones: intercambiando información, revisando datos, sugiriendo ideas, evaluando alternativas o poniendo en práctica directivas. Sin embargo, a pesar de que los directivos de todos los niveles deben representar el papel de la persona que toma las decisiones, el modo en el que un directivo de éxito enfoca el proceso de toma de decisiones cambia a medida que asciende en la organización.
Autor: Kenneth R. Brousseau, Michael J. Driver, Gary Hourihan y Rikard Larsson

Para verlo completo podeis pedirlo en en siguiente link http://www.e-deusto.com/frontal/deusto/documento1.asp?cod=35743

Bueno el caso es que el articulo empieza muy bien pero acaba un poco flojo, sin embargo tiene unas cuantas ideas que me gustaria comentar

1) Existen dos aspectos principales para caracterizar el perfil de la toma de decisiones:

a) El uso de la información.

• ¿Cuanta información necesitamos consultar antes de tomar una decision? ¿Toda la existente?
• ¿Solo una poca hasta hacernos una idea?
• ¿Exhaustiva y contrastada o por el contrario la suficiente para generar una hipótesis?

Si eres de las personas que necesitan abundante información, consultarla toda y estar seguro que esa es la mejor solución, eres del perfil "Maximizador"

Si por el contrario eres de los que necesitan la información justa para poder ponerte manos a lo obra, entonces eres de los llamados "Satisfechos", es decir, decides cuando tienes la información suficiente para satisfacerte.

b) El objetivo al que nos encaminamos cuando tomamos esa decision.

• ¿Solo tienes un objetivo en mente cuando tomas una decision?
• ¿Un camino único, recto y lineal, con un objetivo claro?
• ¿Tu decisión puede satisfacer la consecución de varios objetivos?
• ¿Varios caminos no del todo definidos pero que pueden satisfacer tus necesidades?

Si eres del camino recto y un único objetivo, entras dentro de la clase "Unica opción"

Si eres de los de varios cursos de acción posible entonces tu etiqueta es de "Opciones múltiples"

2) Los autores del articulo (tras un estudio de mas de 120.000 curriculums profesionales de todo el mundo), han identificado 4 perfiles de "estilo de toma de decisiones" basados en los dos aspectos anteriores.

• Decisivo (Satisfecho y unica opción)
• Jerarquico (Maximizador y unica opción)
• Flexible (Satisfecho y múltiples opciones)
• Integrador (Maximizador y múltiples opciones)

El artículo sigue discerniendo luego sobre la evolución de las carreras profesionales y los distintos enfoques que prevalecen a medida que vas subiendo las responsabilidades a la hora de tomar decisiones.

Pero eso ya es harina de otro costal, lo que a mi me interesa es el hecho de que:

¡hay diferentes formas de tomar las mismas decisiones!.

Fijaos en la estructura del un datawarehouse clásico. Tenemos un "bonito" producto cartesiano en el que agrupamos todas las posibilidades para esa estructura dimensional, para esa jerarquía en concreto, es decir seguimos un camino decisional y tenemos todos los cálculos. Este enfoque de adquisición se parece mucho al perfil de toma de decisiones Jerárquico, que en el artículo se vincula con los mandos con caracter mas operacional.

Muchas veces, con alguno de mis clientes, sobretodo con los cargos cercanos a director general, me encuentro en que se quejan de la poca flexibilidad de los sistemas decisionales, en concreto de los cuadros de mando (de los que os hablaré en mi próximo post), pues bien según este estudio el perfil que predomina en este nivel decisional es el Flexible.

Todo empieza a encajar: los datawarehouses y los sistemas clásicos de BI sirven en los entornos operacionales y tácticos, pero en los niveles de decisión estratégicos los caminos decisionales son múltiples y no necesitamos tener "toda" la información.

De manera que el esquema sigue tomando forma:

1. Niveles operacionales y tácticos: Sistemas de BI tradiciones
2. Niveles estratégicos: Ontología + Reglas + Precálculos

Creo que estoy en el buen camino.

El espíritu de la toma de decisiones (Juego de palabras)

Llevo varios dias dándole vueltas al hecho de que un sistema decisional ágil debe ayudar a la toma de decisiones pero sin sustituir al que toma la decision.

Sin duda las métricas, los indicadores y el modelo dimensional forman parte de los análisis previos que hacemos antes de decidirnos por algo. Pero también evaluamos muchas otras posibilidades y descartamos otras de forma rápida, tal como dice Marti en el anterior post "la toma de decisiones se realiza en mucha parte descartando opciones." pero también hay un componente que Antonio ha introducido muy bien 'La decision 'aparece' en mi mente sin seguir nunca un proceso claro... hay 'algo' que me dice cual es la mejor opcion".

Así que me he volcado en el google (que como todos sabemos es el compendio de todo el saber del mundo, mejor que la biblioteca de Alejandría) y he encontrado estas dos referencias:

La primera es la de Zona Espirita en donde he encontrado la siguiente reflexión: http://zonaespirita.divulgacion.net/

El cerebro no trabaja con sustancias materiales y, sí con impulsos de energía. El efecto inteligente proviene de una causa inteligente. ¿Podría, por sí mismo el cerebro tomar decisiones? (...) Si no puede, ¿quién lo hace?...

Claro me he quedado de piedra, yo aqui pensando en como ayudar al cerebro a tomar mejores decisiones y es posible que no sea él quien las tome.¿Y si son los pies? Tendria que replantearme todo mi estudio.

Así que seguí leyendo :

La centella divina, que es nuestro psiquismo, viene viajando desde el principio de los tiempos para formar experiencias y madurez, pasando por el mineral, donde duerme, en el vegetal que es sensación, en el animal instinto y más tarde, incorporándose al Espíritu, tornándose una individualidad con una trayectoria milenaria impresa en el psiquismo.

¡Ostras pues si que tenemos información almacenada!. Despues de la risa volví a analizar la analogía:

Es decir que para tomar decisiones tenemos que tener un DWH milenario "centella divina" en el que almacenemos información externa al problema pero que nos puede ayudar en la toma de decisiones, algo que nos indique que significa el problema... ¿tendrá algo que ver con la ontología decisional?

El segundo link es un libro on-line de gestión del conocimiento un poco mas serio gestion-del-conocimiento.html

"El cerebro humano cuando ha desarrollado una idea suficientemente y ha llegado a una conclusión la incorpora a la memoria para no tener que repetir todo el proceso. Normalmente los preconceptos más importantes se cargan en la memoria inmediata todos los días, formando en realidad una parte importante de lo que se denomina "el carácter de una persona".

Pero fijaos que la idea de no repetir los mismos análisis y basarnos ciegamente en ejecuciones previas hace que nuestra toma de decisiones se acelere. Por supuesto que fallamos ya lo dice Antonio : "no te creas que fallo en el 50% de los casos"

Sin embargo tomamos las decisiones de forma mucho mas rápida y en base a aproximaciones.

Es curioso la casualidad, mientras escribía esto estaba en casa escuchando Shakira y una frase ha llegado flotando a mi desde la parte de atrás de mi cerebro en forma de letra de canción "las mujeres somos las de la intuición".

Creo que empiezo a entender: Ontología + Reglas + Precálculos

¿nos podría servir?

Ontologias Decisionales

Son muchos los ámbitos de los Sistemas de Informacion donde esta apareciendo el concepto ontología. Las ontologías surgen con la idea de estandarizar y facilitar el intercambio de “conceptos” entre sistemas de información, se trata de una forma de representar los conceptos compartidos sobre un mismo dominio de manera que ambos sistemas entiendan lo mismo cuando hablan del concepto “factura” por ejemplo. Gruber las define como “la especificación explícita, compartida y formal de una conceptualización”.

Las ontologías han irrumtido en ámbitos como la arquitectura SOA (orientada al servicio) cuando los los investigadores se dieron cuenta que no solo necesitaban una sintaxis, sino una semántica no ambigua, y que no solo la necesitaban en ese punto sino en toda la arquitectura que se había creado hasta ese momento.

Dos son las iniciativas que se están desarrollando el WSMO y el OWS-L y algunos esfuerzos se están duplicando. Veamos en qué consiste cada una de ellas.

OWS-L (Ontologies Web Services Language) permite que los servicios web sean descubiertos, invocados y gestionados dinámicamente, ya que gracias a él son “comprensibles” por la máquina, es decir podemos distinguir su objetivo conceptual.

WSMO (Web Services Modeling Ontologies) es el modelo para la creación de ontologías de los servicios web semánticos. En este enfoque la semántica “domina” a la sintaxis.

Fijaos en el hecho de que al construir el sistema nervioso del sistema de información, ya estamos definiendo qué significan las cosas, como las interpretamos, sin embargo en los sistemas decisionales aún continuamos con el arcaico método de ejecución de las métricas y almacenamiento con productos cartesiano.

Algunas herramientas decisionales incorporan "capas de negocio" o "capas semánticas" pero se refieren solo a la explotación de los datos por parte de los usuarios finales y no a su consecución y consolidación.

La creación de ontologías decisionales previas a las creaciones de los almacenes de datos puede ser una via para hacer evolucionar la forma en que entendemos las tomas de decisiones.