miércoles, octubre 25, 2006

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.


jueves, octubre 19, 2006

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

miércoles, octubre 04, 2006

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


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.