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.

Mi cerebro.. ¿un producto cartesiano?

Despues de algunos dias sin poder escribir he conseguido sacar algunos minutos para continuar con el blog. Estoy "cerrando" proyectos ya que en breve nacerá mi primer hijo (en 4 semanas) y no quiero dejar ningun cabo suelto.

Hoy me gustaria reflexionar sobre como estructuramos la toma de decisiones. Nuestro cerebro esta acostumbrado a realizar con precisión procesos semiestructurados, en los que hay una parte de incertidumbre que tenemos que despejar. Esto hace de los procesos decisionales algo muy complejo. Trasladarlos a un automatismo es muy complicado ya que no se puede prever con exactitud el tipo de información que vas a necesitar y anticiparte con un informe. Es esta necesidad la que hace nacer los sistemas OLAP (On-Line Analytical Process) que nos ayudarán en la ejecución de los análisis dinámicos. El más conocido de ellos es sin duda el modelo dimensional también conocido por cubos multidimensionales, pero debemos recordar que no es el único..

El modelo dimensional nos representa una actividad que es objeto de análisis a la que se denomina “hecho” y las dimensiones que caracterizan la actividad, estructuradas jerárquicamente. La información relevante sobre el “hecho” (actividad) se representa mediante el uso de medidas o indicadores. Por ejemplo para el hecho venta tendríamos los indicadores unidades y euros, y las dimensiones tiempo, producto, vendedor, zona, almacen, etc… Moviéndonos y cruzando dichas jerarquias obtenemos los valores de los indicadores que necesitamos.

Reflexionad un momento en porque siempre es necesaria la dimensión tiempo, pero tomaos un tiempo antes de seguir leyendo........
........
........
........
otra vez
........
........
........
es necesaria porque los humanos no sabemos tomar ninguna decisión sin hacer referencia a hechos sucedidos en el pasado, es decir sin utilizar nuestra experiencia. Recuerdo cierto episodio de Star Trek Deep Space Nine en que se encontraban con una forma de vida que no tenia la referencia temporal..... l¡¡¡¡ la comunicación era practicamente imposible !!!!!.... y tomar decisiones conjuntas mas todavía. Así que si eres humano necesitas la dimensión tiempo en tu sistema decisional.

Sigamos con las preguntas: ¿Que es un cubo multidimensional?........., pues es un almacén de información en el que calculo previamente todas las combinaciones de todos los niveles de la jeraquía de la dimensión con todas las dimensiones. En otras palabras; un “bonito” producto cartesiano que me almacena todas las combinaciones. El almacén de un hecho en concreto es lo que se denomina Datamart.

Un momento, ¿pero eso no es una salvajada?. Pues en cierto modo si, es una semiestructuración basada en la “fuerza” que nos garantiza poder acceder de forma rápida y sencilla a la necesidad decisional que nos salga en ese momento. Obviamente esto requiere de grandes cantidades de procesos de cálculo y de un almacén de datos que ya no tiene por que ser una base de datos relacional (diseñado para la transacción) sino que puede ser una de las modernas bases de datos multidimensionales, diseñadas específicamente para hacer eficiente este modelo de semiestructuración de la información.

¿Es esta la mejor forma de acometer un sistema decisional?
¿Es mi cerebro un conjunto de productos cartesianos que utilizan la dimension tiempo?
¿Como puedo agilizar entonces la toma de decisiones con un metodo tan poco "agil"?

Tres conceptos, tres blogs

Son tres los blogs que creo que pueden ser útiles para tener una visión mas detallada, de todo aquello de lo que quiero tratar en este espacio.

El primero de ellos es el blog de Antonio Valle:

Gobierno de las TIC. Conocimiento Adquirido

Antonio es unico culpable de que yo me haya lanzado a la tarea de crear este espacio de debate. Lo conozco desde hace años y he de decir que es la persona mas parecida a un gurú que conozco. Desde hace años me hablaba de ITIL y COBIT con auténtico fervor, cuando no eran mas que pequeños embriones de los actuales estándard, y yo le escuchaba pensando que ojalá aquel conjunto de buenas intenciones se transformase en una realidad palpable. Sin duda el trabjo y el esfuerzo de Antonio Valle a permitido cristalizar este estándar en el ámbito nacional.
De nada sirve nada de lo que aqui transmitimos si no tenemos una gestión eficaz y eficiente de la TIC. os animo a que le pegueis un vistazo. ¡Gracias Antonio!

El segundo de ello es uno de los referentes a nivel nacional sobre Business Intelligence, se podría decir que allí esta "todo".
Se trata de Todo BI (http://todobi.blogspot.com/), quizás la única pega por ponerle alguna es que trata el CRM como parte de del BI, cosa con la que yo no estoy de acuerdo, pero en fin es simplemente una opinión.


El tercero es la web de Agile Spain (http://www.agile-spain.com) foro de debate el lengua castellana sobre las metodologías ágiles.

A medida que vaya teniendo tiempo añadiré algunos links más.

Espero que os sean de utilidad.

Que son eso de las metodologías ágiles

Ya hemos visto que entiendo por Business Intelligence, así que ahora le toca el turno al otro puntal de lo que debería ser el objetivo de este espacio: las metodologías ágiles.


En el Manifiesto Ágil se definen los cuatro valores por las que se deberían guiar las metodologías ágiles.

“ Estamos buscando mejores maneras para desarrollar software y ayudar a otros a desarrollarlo. En este trabajo valoramos:
· Al individuo y sus interacciones más que al proceso y las herramientas.
· Desarrollar software que funciona más que a obtener una buena documentación
· La colaboración con el cliente más que la negociación de un contrato.
· Responder a los cambios más que seguir una planificación.
De esta manera, mientras mayor valor tengamos en la parte derecha más apreciaremos los de la parte izquierda “

Manifiesto Ágil.

Firmado por Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland y Dave Thomas.

Veamos que significa cada uno de estos valores:

1) Al individuo y sus interacciones más que al proceso y las herramientas.

Sin duda la herramienta fundamental del desarrollo de sistemas decisionales es el cerebro humano. Unas jornadas maratonianas de 14 horas de trabajo van en detrimento de la calidad del producto final. Pero una persona sola no realiza un proyecto, necesita de un entorno en el que desarrollar su trabajo y de un equipo con el que colaborar. Estas interacciones deben también cuidarse. Un factor clave para el éxito es construir un buen equipo, que se lleve bien entre ellos, y que además sepan como construir su propio entorno de desarrollo. Muchas veces se comete el error de construir primero el entorno y esperar que el equipo se adapte a él. Esto nos resta eficiencia, es mejor que el equipo lo configure en base a sus necesidades y sus características personales.

Además las interacciones que haga el equipo con el usuario final deberían ser igual de fluidas siendo este usuario un miembro más del equipo, con un objetivo común, que es conseguir que el proyecto funcione y sea útil para él.

Si todo esto funciona bien es obvio que la elección de las herramientas y el proceso mismo de desarrollo pasan a estar en un plano totalmente secundario en la ecuación del éxito del proyecto.

2) Desarrollar software que funciona más que a obtener una buena documentación

Uno de los objetivos de una buena documentación es poder ir a consultarla cuando haya que modificar algo del sistema. Sin duda es un arma de doble filo, una buena documentación actualizada en cada modificación y bien mantenida al día, te permite saber el estado de la aplicación y como realizar las modificaciones pertinentes, pero son pocos los que con las presiones externas de tiempo y dinero acaban actualizando la documentación.

En la filosofía ágil lo primordial es evitar estos fallos, la regla no escrita es no producir documentos superfluos, y solo producir aquellos que sean necesarios de forma inmediata para tomar una decisión importante durante el proceso de desarrollo. Estos documentos deben “ir al grano”, ser cortos y centrarse en lo fundamental, olvidándonos de los circunloquios que no aportan nada a la comprensión del problema.

3) La colaboración con el cliente más que la negociación de un contrato.

La consultoría informática de los últimos años se ha convertido en una lucha a muerte entre el proveedor del servicio y el cliente que lo contrata. Por una parte el cliente intenta que se hagan el mayor número de funcionalidades con el mismo dinero, por otra parte el consultor intenta que por ese dinero solo se realicen las funcionalidades contratadas inicialmente. En las reuniones de seguimiento de los proyecto es fácil oír frases del tipo “esta modificación no entra en el contrato” respondida generalmente por la tan típica “pues yo ya no tengo más presupuesto y así no podemos trabajar”. Al final este tipo de proyectos hacen que el consultor informático sea un híbrido entre analista y abogado. Desarrollando habilidades legales para salvaguardarse en caso de conflicto jurídico.
Sin embargo para que un proyecto tenga éxito la complicidad y el contacto continuo entre el cliente y el equipo de desarrollo es fundamental. El cliente debe ser y sentirse parte del equipo. De esta manera ambos entenderán las dificultades del otro y trabajarán de forma conjunta para solucionarlo.

4) Responder a los cambios más que seguir una planificación.

Una organización cambia constantemente, se adapta a las necesidades del mercado y reorganiza sus flujos de trabaja para ser mas eficiente. Es difícil pues, que en el desarrollo de un proyecto, este no sufra ningún cambio, pues es seguro que las necesidades de información de la empresa habrán cambiado y mas cuando se trata de sistemas decisionales, no siempre tomamos las decisones de la misma manera. . Son muchos los factores que alterarán nuestra planificación inicial del proyecto, si la adaptamos a estos cambios corremos el riesgo de que cuando acabemos, nuestra aplicación no sirva para nada y el cliente se haya gastado el dinero en vano. La habilidad de responder a los cambios de requisitos, tecnología, presupuestarios o estrategia, marca sin duda el camino del éxito del proyecto.

Como consecuencia de estos cuatro valores, el Manifiesto Ágil también enuncia los doce principios que caracterizan un proceso ágil diferenciándolo de otro tradicional en los que este enfoque no se había aplicado lo suficiente, siempre se había dejado implícito pero sin hacer hincapié en ellos.

I. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software que le aporte un valor.
II. Dar la bienvenida a los cambios incluso al final del desarrollo. Los cambios le darán una ventaja competitiva a nuestro cliente.
III. Hacer entregas frecuentes de software que funcione, desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas.
IV. Las personas del negocio y los desarrolladores deben trabajar juntos diariamente a lo largo de todo el proyecto.
V. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos.
VI. El diálogo cara a cara es el método más eficiente y efectivo para comunicar información dentro de un equipo de desarrollo.
VII. El software que funciona es la principal medida del progreso.
VIII. Los procesos ágiles promueven un desarrollo sostenido. Los promotores, usuarios y desarrolladores deben poder mantener un ritmo de trabajo constante de forma indefinida
IX. La atención continua a la calidad técnica y al buen diseño mejoran la agilidad.
X. La simplicidad es esencial. Se ha de saber maximizar el trabajo que NO se debe realizar.
XI. Las mejores arquitecturas, requisitos y diseños surgen de los equipos que se han organizado ellos mismos.
XII. En intervalos regulares, el equipo debe reflexionar con respecto a cómo llegar a ser más efectivo, y ajustar su comportamiento para conseguirlo.

Llegados a este punto podemos intuir que las formas de hacer las cosas están cambiando, adaptándose más a las personas y a las organizaciones en las que han de funcionar las aplicaciones.
Para completar todo esto os adjunto un link imprescindible http://agilemanifesto.org/

¿Estamos en la antesala de una revolución?. Posiblemente. ¿Pero podemos aplicar esta metodología a los sistemas decisionales o solo es aplicable a los sistemas operacionales?

Esa es mi gran duda.

¿Qué entiendo por Business Intelligence?

El Business Intelligence (BI), o Inteligencia de Negocio, es un término de ambigua definición bajo el que se albergan diferentes acrónimos, herramientas y disciplinas: OLAP, Datawarehousing, Datamarts, Mineria de Datos, Executive Information Systems, Decisión Support Systems, Redes Neuronales, Sistemas Expertos, Cuadros de mando, Balanced Scorecards, y un largo etcétera.

BI las cobija a todas bajo su etiqueta, pero toda esta variopinta y diversificada fauna, tienen tres carácterísticas en común en el que todas coinciden.

La primera de ellas es proveer de información para el control del proceso de negocio, independientemente de donde se encuentre esta información almacenada.

Obviamente, el BI, forma parte del sistema de información de una empresa, que es el órgano que controla la ejecución y el correcto funcionamiento de los procesos que en ella se desarrollan.

En una visión clásica como la de la Figura 1 podemos ver que los procesos de transformación sufren perturbaciones externas, como pueden ser cambios en el mercado, productos sustitutivos, nuevas legislaciones, etc.. que deben ser controladas y corregidas. Además de todos es sabido que los sistemas con el tiempo tienden a la desorganización y al caos. Es por esta razón que la medición de indicadores empresariales y la comparación con los objetivos fijados es la forma que tenemos de detectar que algo esta yendo mal en nuestra organización.

Los procesos generan y consumen información durante su ejecución, una parte de ella es consumida en el corto plazo, es lo que llamamos información operacional, pero gran parte de ella queda almacenada en los diferentes sistemas transaccionales (ERP,CRM, SCM, etc…) a la espera de que puedan ser utilizadas para la toma de decisiones tácticas (medio plazo) y/o estratégicas (largo plazo).

Agrupar esta información y ponerla en el tiempo adecuado a disposición del sistema de control del procesos, independientemente de en que sistema operacional se encuentre nos ayudará a optimizar nuestros procesos, ya sean los operacionales, los tácticos o los estratégicos. Obviamente el nivel de agregación y unificación de fuentes heterogéneas de datos será mayor para los procesos de carácter decisional, y es precisamente este carácter decisional el que da una nueva impronta a la definición de Business Intelligence: la ayuda a la toma de decisiones es la segunda característica en común bajo este extenso paraguas, y sin duda la más importante de ellas.

BI, no solo se limita a presentar la información si no que da la capacidad de manipular y navegar sobre ella para poder analizar las causas. En la toma de decisiones el análisis es fundamental, no se toma decisiones con una sola información, las informaciones se contrastan, se relacionan entre si, se podría decir que están “vivas”. Esta capacidad de análisis nos garantiza tomar mejores decisiones sobre el negocio.

Y en este punto nos podemos hacer la siguiente reflexión: ¿Quién toma las decisiones con la información que le hemos entregado necesita saber de sistemas de información para interpretarla?. Obviamente no, únicamente ha de saber de negocio, de hecho solo debería saber de negocio. Y aquí nace la tercera característica del BI; la capa semántica.

No podemos tomar decisiones sobre el negocio si no hablamos el lenguaje propio del negocio, da igual donde este la información almacenada, ni como la hayamos transformado o agregado, lo verdaderamente importante es “servir” esta información al usuario final en un lenguaje de negocio que el comprenda, con el que se sienta cómodo y que no necesite interpretar a que se refiere. De esta manera, le facilitamos el trabajo para que en poco tiempo pueda tomar un decisión sobre nuestros procesos que los mejores y que nos ofrezca una ventaja competitiva en el mercado.

El enfoque del Business Intelligence esta claro: la información reduce nuestra incertidumbre (sobre algún aspecto del mercado o de nuestros procesos de negocio) y, por tanto, nos permite tomar mejores decisiones que nos pueden dar ventaja competitiva.

Como podéis ver no es una definición pero nos sirve para focalizarnos en la idea de que el éxito de una organización y de la gestión empresarial se encuentra en el uso que esta hace de la información, no podemos gestionar lo que no controlamos, si no tenemos información para controlar los procesos, estos tenderán al caos, y tampoco podemos controlar lo que no medimos, de nada sirve el mejor sistema BI si la información no ha sido introducida adecuadamente en los niveles operacionales.