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.