La cultura de la cooperación

Acabo de ver a través de DM Review un artículo muy pero que muy interesante y que además enlaza perfectamente con mi anterior post.

Se trata de "Culture of Cooperation" en este artículo de Rand Losey (que habla sobre qué debemos tener en cuenta cuando diseñamos, y ponemos en marcha, un modelo decisional), encontramos frases tan buenas como estas:

• Will all business questions be met by the logical data model?
• Will any technical person reading the logical data model have the same understanding of its contents?
• Will any subject matter expert reading the logical data model have the same understanding of its contents?
• Will any business partner reading the logical data model have the same understanding of its contents?

Es decir, cuando modelamos un data warehouse (ver como se hace en el blog de Chema Arce), el arquitecto modela lo que le dice el usuario final o el usuario experto, se intenta mostrar una realidad de negocio, una forma de ver las cosas, pero al final de todo la pregunta es obvia.... ¿SACAMOS LAS MISMAS CONCLUSIONES DEL MODELO? ¿SIGNIFICA PARA TODOS LO MISMO?.

Esta idea, hace que el autor ponga diferentes revisiones para que se mantenga el significado, y esto me parece genial, de hecho es lo que estoy proponiendo en mi modelo de Agile BI Governance, que el sistema sea propiedad CONJUNTA de IT y de Negocio, y para ello Rand Losey propone primero 4 fases de revisión del modelo.

• Completeness and Standards Compliance Review
• Clarity Review
• Reuse of Existing Designs Review
• Business Partner Understanding Review

Es esta última la que más me interesa porque ademas ilustra con unas técnicas que se pueden aplicar para que el usuario se involucre y vea si ese modelo es entendible por él.

Finaliza con un gran parrafo:

"A high-quality logical data model is built according to a recognized set of rules that enable the model to be used to greatest effect. The importance of these rules is that the organization can use their logical data models with assurance that they will be uniformly understandable and consistent regardless of who developed the model or when it was designed."

La idea de que un modelo debe de ser uniformemente comprensible para toda la organización, tanto para IT y como para Negocio es el motor del framework de Agile BI Governance y de esta idea de la propiedad conjunta, veo que no voy por mal camino. La cultura de la cooperación.

Agile BI Governance

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

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

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

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

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

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

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

Feliz Navidad y esas cosas

Y no olvideis el auténtico espiritu de la Navidad... no perder la capacidad de ilusionarse.









¡¡¡nos vemos en el 2008!!!!

Madurez de las soluciones Bi en las organizaciones

Una de las características básicas para el éxito de los sistemas de Business Intelligence es sin duda la cultura organizativa y el nivel de madurez en el que se encuentre la organización en la que se va a implantar.
Crear y gestionar una cultura de medición de indicadores necesita de tiempo.
Sin esta evolución de la organización, es imposible que las soluciones de BI florezcan en ella con el esplendor necesario.

Ver articulo completo "Madurez de las soluciones BI en las organizaciones".

Espero ansioso vuestros comentarios

Outsourcing de Business Intelligence

Inauguro una nueva sección en la que me gustaria que comentaramos los articulos que voy publicando en GdR, una especie de feedback colectivo que origine nuevas reflexiones y a la vez nuevos articulos.

Empezamos con el primero.

"Si BI es un servicio, ¿entonces se puede externalizar totalmente?,
¿puedo realizar un proceso de outsourcing total de mi Business
Intelligence? Y lo que es más crucial ¿debo realmente hacerlo?"

A estas preguntas respondo en el artículo:

¿Donde pongo el cerebro de mi empresa?

Gestión del rendimiento nº 4

Buneo, ya la tenemos aquí y online, el número 4 de la revista gestion del rendimiento.
Como siempre lo podeis descargar gratuitamente en pdf, pero yo es recomiendo que os subscribais porque impreso se lee mejor.

(haz click en la imagen para descargar)

Que la disfruteis.

No pagueis el rescate que me he escapado

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

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

Pero aparte de al blog le debo varias cosas.

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

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

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

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

Cognos tambien cae

Que poco ha durado, despues de la adquision de Business Objects por parte de SAP.

IBM ha adquirido Cognos.

El mercado de BI como fabricantes independientes desaparece disuelto por los grandes fabricantes.

Es el fin de una época. :-(

Red Social BI Beers

Al final me he decidido por poner mi perfil en LinkedIn, y viendo el éxito de la red social que esta montando Antonio Valle sobre Gobierno de las TIC, y recogiendo el testigo que lanzó Jose Maria Arce cuando dijo "esto mejor lo hablamos tomando unas cervezas". He fusionado ambas ideas y he creado la red social "BI Beers".

El objetivo de esta red no es otro que aglutinar a los entusiastas del BI para que estemos en contacto y podamos tomar unas cervezas cuando coincidamos en el mismo lugar.
La idea que me ronda la cabeza es que surjan grupos tanto en España como en Latinoamerica y que esta etiqueta sea realmente una red social que nos aglutine. Así que os invito a que os unais al grupo, solo teneis que pulsar este link y automaticamente estareis dentro.

http://www.linkedin.com/e/gis/40499/4D25D00C3BC7

Aquellos de vosotros que querais poner el link de BI Beers en vuestro blog, no os corteis, esta iniciativa es de todos los que comentais y escribis los blogs sobre Business Intelligence.
Bueno, si la respuesta es buena y consigo engañar a mas gente, quizas podamos hacer una web y todo, con foros y wikis y esas cosas de la web 2.0.

Saludos y animaos a apuntaros.

P.S: Antonio, no te copio, simplemente me inspiras ;-D

The Triadic Continuum, el fin del Datawarehouse

La verdad es que este post es absolutamente fruto de la casualidad, no lo tenía planificado como la continuación de mi anterior post pero me viene que ni caido del cielo.

No lo digo yo, lo dicen en DM REVIEW

The Best New BI Invention You’ve Never Heard Of

Este fantambuloso invento viene a jubilar definitivamente a los Datawarehouse y a la estructuras de Inmon y Kimball. La nueva "padre" de los sistemas decisionales es Jane Mazzagatti. y su nuevo invento tiene nombre de capítulo de Star Trek NG:

THE TRIADIC CONTINUUM.

¿Que es lo que han hecho Mazzagatti y su equipo de la empresa Unisys? Pues han inventado una estructura de autoaprendizaje en tiempo real, que se "alimenta" de querys de las que "aprende" a dar respuestas, a medida que se va alimentando de datos las respuestas a las preguntas que se hacen al Triadic Continuum pueden ir variando, al igual que funciona el conocimiento en los humanos.
La idea principal del TC es que mientras que en una Base de Datos tradicional (ya sea relacional o multidimensional) nos centramos en la busqueda de datos e información , el centro de atención del TC esta en la adquisición de conocimiento útil y con un proposito decisional determinado. El TC no solamente se centra en el dato, sino en las relaciones que hay entre ellos, sobre estas relaciones, el sistema "aprende" y crea los métodos de explotación y acceso a la información.

Es una estructura que mezcla conceptos de modelado de datos con mineria de datos, en una única herramienta. ¿no os suena de algo? los que habeis seguido el debate del post anterior os resultará esta conclusión muy pero que muy familiar.

La estructura física de este Triadic Continuum la verdad es que se me ha escapado un poco, según el artículo de referencia de DM REVIEW

"El modelo conceptual de la estructura de la Triadic Continuum es bastante simple. Mazzagatti y colegas utilizan el término "simple y elegante" en la explicación de la forma en que está organizada. En pocas palabras, se trata de una estructura de tipo arborea con nodos llamados "tríadas." Estos nodos están conectados entre sí por ramas o caminos. Las tríadas que conforman la Triadic Continuum puede ser visualizadas como tres nodos organizados de forma triangular, en cierta formación. El primer nodo se conecta al segundo nodo mediante un puntero bidireccional, y el segundo se conecta al tercero tambien con otro puntero bidireccional. Los punteros identifican a que nodeo y desde que nodo se conectan , lo que permitirá a todos los nodos a saber siempre su relación dentro de la continuidad de las estructura consultando sólo dos punteros."

Vamos que no me he enterado de nada, pero eso sí, parece que no soy el único que se esta dando cuenta que el Datawarehouse y los sistemas de BI deben de dar un paso evolutivo hacia el "conocimiento", dejando atras los "datos"

Prometo buscar mas info sobre THE TRIADIC CONTINUUM.

MODIFICACION 2-Nov-2007

Ayer recibí un email que me ha dejado patidifuso, un mail muy corto pero a la vez sorprendente y que me ha recordado que estamos realmente es un mundo conectado y que esto de la blogosfera realmente es algo increible.

El contenido del mail es este:

I have read your blog and sent it to my team – I love the TNG picture – the team members were excited to see that someone really grasped the ideas - Jane

Y si señores, es la Jane que sospechais,... ¡¡¡¡Jane Mazzagatti!!!!.

Pregunta al aire: ¿Qué debe "almacenar" un DataWarehouse?

Yo cada vez tengo mas claro que debe almacenar todo menos datos, de hecho empiezo a sospechar que el concepto de DataWarehouse está llegando a su fin.

(SILENCIO)

(SILENCIO)

(SILENCIO)

Este silencio es para causar estupor :-D.

No me he vuelto loco, simplemente cae por su propio peso .

Si recordamos la metodología User-Driven , en ella el punto de partida es que los requisitos no son suficientes con lo que se busca mostrar al usuario un prototipo funcional para intentar captarlos lo mejor posible. Esta metodología buscan tener muy bien definido la interfaz de usuario y que la calidad del dato mostrado sea muy buena, el objetivo es conocer al usuario y las cuestiones que se tienen que responder de cara al negocio, sobre todo las de caracter estratégico.

Afolabi y Thiery, es su articulo "Using Users’ Expectations to Adapt Business Intelligence Systems", nos hablan de la importancia de usuario en este tipo de sistemas, no solo a la hora de definirlo, sino basado en sus propias fases cognitivas: observación; abstracción elemental; razonamiento y simbolización; y creatividad. A través de estos estudios podremos adaptar nuestro sistema de BI al tipo de consultas que nos hará el usuario final (Query Adaptation) y al tipo de respuestas que le tenemos que devolver (Response Adaptation).

Conocer como los usuarios "entienden" la información nos permitirá que los sistemas de BI se entronquen directamente con la gestión del conocimiento creando nuevos sistemas que algunos autores ya estan denominado Knowledge Datawarehouse.

Así pues la pregunta esta clara:

¿Que debe almacenar un Datawarehouse?
a) Datos
b) Información
c) Conocimiento.

d) Todas las anteriores

e) Ninguna de las anteriores

Os pongo una encuesta para que interactueis, pero el debate esta abierto.

Pair Thinking para DWH

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

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

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

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

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

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

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

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

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

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

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

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

Tres razones para cambiar a metodologías ágiles

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

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

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

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

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

Así que como dice Scott W. Ambler,

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

¿Quien ha intentado cambiarse?

Juro que no les he sobornado :-D

Si en junio de 2006 cuando puse mi post de Tres conceptos, tres blogs (en el que recomendaba desde mi humilde posicion de blogger principiante al blog de TodoBI como referencia fundamental para temas de BI) me dicen que 16 meses despues yo iba a estar en la lista de los blogs de BI que ellos recomiendan, me lo habría tomado a broma.

Así que solo decir gracias a ese equipo encabezado por Emilio que hacen dia a dia posible

y no os perdais el resto de la lista

algunos viejos conocidos
BIB (BI Blog)
Information Management

Algun "novato" que apunta
Estudiando BI

y autenticas sorpresas que sin duda voy a seguir de cerca

Xperimentos
DBRunas
Marketing & Innovavion

BOMBAZO: Business Objects esta en Venta

Segun el diario Le Figaro. Business Objects ha contratado a la empresa intermediaria Goldman Sachs para buscarles un comprador. Sus acciones han subido un 5% en un dia.

¡¡¡¡Y sorpresa!!!! SAP parece la mejor posicionada por delante de Oracle e IBM

Podeis leer la noticia completa aquí.

¡¡¡Se admiten apuestas!!!!

ACTUALIZACION 23-09-2007

Los de todoBI, han puesto la lista de posibles candidatos,

Yo no habia pensado en la opción de HP, pero si lo pensais bien es la que daría mas independencia al producto tal y como se entiende a dia de hoy. Si lo compra Oracle o SAP o Microsoft dejará esa independecia que el producto tiene actualmente y si lo compra IBM seguramente no le dará el fuelle necesario. EMC2 podria ser un candidato con mucho empuje pero yo no lo veo claro.

Actualizacion 08-10-2007

Y EL GANADOR ES............ SAP

Leido aquí


"SAP announced Sunday afternoon it plans to acquire Business Objects in a cash deal valued at slightly more than $6.8 billion.
The acquisition, which is expected to close in the first quarter of 2008, is SAP's largest acquisition ever. The deal is especially noteworthy for SAP, which has tended to favor developing its own technology, rather than acquiring it. "

Empezaremos 2008 con un aspecto del mercado muy muy diferente.

Y he perdido una cerveza. :-(

Nueva actualización 08-10-2007

Podeis ver el analisis de Todo BI. y la nota oficial de BO

Ha sido una compra pactada y de buenos amigos.

¡¡¡¡¡¡¡¡¡GdR Gratis!!!!!!!!!

Bueno, a Paco Marin (editor de DotNetMania y GdR) se le ha ido la chaveta y de la noche a la mañana ha decidido que la revista sea......

¡¡¡¡¡¡Gratis!!!!!!!, by de face.

Eso si en formato PDF.
Y para aquellos que les guste tenerla impresa y hacerse la cole, hay una subscripcion 2x1 de dos años (12 números) al precio de 1 por tan solo 35 euros, vamos tirao de precio. Y si aún no estais convencidos podeis acceder a una subscripcion de tres numeros impresos gratis si sois profesionales.

Así que suscribete ya.


O empieza leer los tres números publicados gratis en pdf.


No os olvideis de leer los artículos de mi sección "Gap de oxímoron"

Nº 1 Origenes y tendencias de los cuadros de mando.
Nº 2 El dato es heterogéneo pero la informacion es única.
Nº 3 La utopia de los requisitos

y el de mi visita al Forum Barc y mi debut como fotoreportero :-D

ESTO HA SIDO UN PUBLIREPORTAJE DESCARAO :-D

Mirando el Model Driven Approach

Uno de los articulos que ha caido entre mis manos es este de P. Chowdhary, K. Bhaskaran et Al: Model Driven Development for Business Performance Management. IBM SYSTEMS JOURNAL, VOL 45, NO 3, 2006: 587- 605 que lo podeis descargar de aquí.

El MDD es una metodología que pretende tender un puente entre el negocio y el departamento de IT, intentando proporcionar la base para desarrollar soluciones rápidas, que evolucionen fácilmente y flexibles. Es pues una buena candidata para los entornos de BI tal y como los entendemos.

La idea esta en el desarrollo de un "modelo conceptual" que ayuda a simplificar la complejidad
de la realidad y que después puedan desplegarse en diversas arquitecturas, preferentemente en SOA.

Debido a su alto nivel de la reutilización de la abstracción y del código, la metodología de MDD se ha aplicado extensamente en las áreas relacionadas tales como reutilización del software, reingeniería inversa, diseño del interfaces de usuario.


Las ventajas de adoptar MDD incluyen tiempo de desarrollo reducido, mejora de la calidad y del mantenimiento de la solución.


El MDD no es mas que una evolución del simple prototipaje de toda la vida, pero con modelos conceptuales y dirigido a SOA, cosa que le da muchas posibilidades de cara al futuro. Yo seguiré mirandolo con mas detenimiento a ver como se puede aplicar.


¿Alguien ha trabajado con este modelo?.

La vuelta al cole siempre me dió pereza

Septiembre, estoy de vuelta tal y como prometí (aunque he estado tentado de dejarlo, no lo niego).

Lo malo de escribir una lista de propositos es ver que despues de estos tres meses no has hecho ni la mitad de lo que querias hacer.

1) Recapitular. Vamos ni lo he intentado

2) Volver a enfocar los objetivos. Sigo sin saber si mantener desvinculadas mi faceta profesional de mi faceta académica, pero al final es practicamente imposible separar al "Jorge" Director de consultoria Business Intelligence de Abast Solutions del "Jorge" Profesor de la Universitat Politécnica de Catalunya y estudiante de doctorado. Así que seguramente pondré un acceso mas detallado a mi perfil para que se pueda consultar desde el blog, no se si ponerlo en Neurona o en LinkedIn. ¿Que me recomendais?. Eso sí, seguiré manteniendo la total independencia de productos de Business Intelligence, quiero seguir hablando de BI con MAYUSCULAS.

3) Cambiar el look&feel. Je je je , me da la risa

4) Averiguar de dónde sale ese pop-up con publicidad . Me lo dijo Antonio, fue facil, bueno miraré si me cambio de contador de visitas.

5) Dedicarme a mi doctorado que lo tengo paradito. Eso si lo hice, escribí y presenté la primera parte de mi tesina, con lo que el camino hacia el doctorado esta mas cerca, que quizás era el objetivo inicial que me propuse cuando empecé este blog. En esta primera parte hago una correlación entre los principios ágiles y los factores de éxito de los sistemas de Business Intelligence. El resultado es alentador, espero escribir algún articulo divulgativo sobre ello, aunque no se si en el blog o en mi sección de la revista GdR

¿Que voy a hacer este año?

Pues creo que voy a seguir publicando refrexiones sobre BI, sobre las metodologías ágiles y voy a potenciar algo que me gusta mucho; comentar articulos científicos que me voy leyendo.

¡¡¡¡¡En marcha!!!!!!

Un añito blogueando y una pausita breve

Pues si, parece mentira, pero ya ha pasado un año desde que Antonio Valle, me engañó y me metió en esto de hacer mi propio blog, eso si, me he vengado porque ahora el habla de Sistemas Decisionales sin pestañear siquiera.

Han sido 37 post que han recibido mas de 18.000 visualizaciones de página, pero lo mas sorprendente es que solo el 33% han sido desde España, la gran mayoria un 58,5% han sido visitas desde allende los mares, desde latinoamérica. Jamás lo habría imaginado hace 365 dias.

Gracias a todos los que os habeis paseado por este raro blog, a los que me habeis hecho consultas en el mail, a los que habeis dejado vuestros comentarios y a los que me habeis animado a seguir con esto.

Ahora toca recapitular, volver a enfocar los objetivos, cambiar el look&feel, averiguar de dónde sale ese pop-up con publicidad que yo nunca he puesto pero que sale y no se porqué, y dedicarme a mi doctorado que lo tengo paradito. Por eso, hoy 8 de junio de 2007 empiezan las vacaciones escolares del blog "Sistemas Decisionales, algo mas que Business Intelligence" que volverá en septiembre como los niños al cole.

Buen verano a todos.

P.S: Últimamente me comentais poco, a ver si os animais el curso que viene.

Balanced Scorecard: El cuadro de mando (parte IV)

Ya tenemos definido nuestro mapa estratégico y nuestros objetivos locales a cada perspectiva, pero.. ¿cómo sabemos que los estamos alcanzando?. Ha llegado el momento de crear los indicadores (también llamados medidas), ellos nos permitirán visualizar si los estamos cumpliendo o no.

Se pueden distinguir entre dos tipos:

1. (indicadores de resultado) los que nos miden la consecución del objetivo
   
2. (indicadores de causa) los que nos miden el impacto de las acciones que estamos haciendo para conseguirlo .

Veamos un ejemplo, si tenemos como objetivo “aumentar la capacidad comercial” de nuestros vendedores, podemos utilizar el número de visitas mensuales, el incremento medio de las ventas y el tanto por ciento de oportunidades que se convierte en ventas, como indicadores de resultado, y las horas de formación por comercial , como indicador de causa. Este conjunto de cuatro indicadores nos darían información del nivel y causa de la consecución (o no) del objetivo marcado.

Ahora nos tocaría fijar las metas (¿hasta donde queremos llegar?). Deben ser metas posibles para no desmotivar pero a la vez ambiciosas para que nadie se relaja.

Por último debemos definir las iniciativas, acciones concretas con las cuales pretendemos alcanzar nuestras metas y nuestros objetivos.

Con los indicadores, las metas y las iniciativas definidas, ya estamos en disposición de crear el Cuadro de Mando Integral, cuya misión será mostrarnos “de un solo vistazo”, el estado entre la visión y la acción en cada una de las perspectivas y que complementará al mapa estratégico.

Para facilitar la comprensión muchos de los CMI utilizan la analogía con el semáforo, cuando un indicador esta mal, se pone el semáforo en rojo, cuando esta bien, se pone en verde. Otros utilizan banderas incluso he visto algunas implementaciones utilizaban caras sonrientes, serias, tristes y llorosas. Lo importante es que el estado de las cuatro perspectivas se vean sin esfuerzo inicial y que luego se pueda profundizar para analizar con la información que queramos.

El CMI, no es mas que un cuadro de mando aplicado a cada una de las 4 perspectivas, realmente ha de ser un conjunto de cuadros de mandos jerarquizados y con vinculaciones con el análisis y el reporting. La sensación final ha de ser un poco como el malo de james bond, que desde su panel de control en su guarida secreta observaba como se iba ejecutando su plan.

Muchas implantaciones de Balanced Scorecard se han quedado solo con el elemento de cuadro de mando integral, es por esto que algunos autores han llegado a equiparar los términos. A mi me gusta mantener esta distinción ya que es esta diferencia lo que hace que el BSC sea todo un sistema de gestión estratégica y que no se convierta tan solo en un sistema de gestión táctica.

Y con este post termino la serie sobre BSC