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

Balanced Scorecard: El mapa estratégico (parte III)

El mapa estratégico, es sin duda el elemento más importante de un BSC, por desgracia en muchas implantaciones nos olvidamos de este elemento fundamental.
El mapa estratégico debe describir, en forma clara y visual, la estrategia de la organización. Debe permitir comprender, de un solo vistazo, la estrategia de la empresa, incluidas las relaciones causa-efecto y las dependencias entre los objetivos.

Veamos un ejemplo de mapa estratégico (mapa publicado en la revista DATA.TI)

En primer lugar, para crear un mapa estratégico tenemos que identificar las perspectivas por la cuales queremos analizar el estado de nuestra empresa.

Cuatro de ellas ya las sabemos, pero quizás necesitemos añadir alguna más.

Seguidamente debemos definir los objetivos estratégicos y trazar la forma de conseguir con objetivos locales a cada perspectiva. La representación de estas relaciones causa-efecto será nuestro mapa estratégico. Si al acabar el mapa no tenemos ningún objetivo local en alguna de las dimensiones, veremos claramente que nuestra estrategia no esta equilibra, no esta “balanceada” como pretendemos con el BSC.

El mapa estratégico puede a su vez estar subdividido por líneas de actuación, como puede ser la de crecimiento, la de productividad o la de calidad.

Por último no debemos olvidar, que un mapa estratégico no es algo que se crea una vez y se arrincona, es algo dinámico, que debe reflejar la estrategia cambiante según las necesidades del entorno en el que nos movemos nosotros y nuestros competidores.

Por eso debe mantenerse periódicamente y mostrar de forma gráfica y clara (por ejemplo mediante el uso de colores) el estado de consecución de cada uno de los objetivos.

La importancia de los mapas estratégicos en el Balanced Scorecard es tanta que los mismo Kaplan y Norton, ya practicamente no hablan de otra cosa en los ultimos años, priorizándolo por encima del cuadro de mando y la representación de indicadores de la que hablaré en el próximo post.

Balanced Scorecard: De la visión a la acción (parte II)

Ya hemos visto las 4 perspectivas "tipicas" de Kaplan y Norton, pero son solo son una sugerencia de estos dos profesores, a la hora de la verdad podeis poned tantas perspectivas como creais necesarias para guiar vuestra organización. Actualmente esta bastante de moda poner la perspectiva "Responsabilidad Social" o "Medio Ambiente", pero eso ya lo dejo en vuestras manos.

Pero los que estais pensando que estas perspectivas son para "controlar", os estais equivocando de plano, el BSC va más allá de un simple sistema de control de gestión. Una correcta implantación de un BSC ha de alcanzar la entidad de sistema de gestión estratégica, debe ser el sistema de información en el que se refleje si nuestra visión se está reflejando en las acciones de nuestros empleados y directivos. Debe ser una guía que nos lleve de la visión a la acción, que nos permita traducir la estrategia de la empresa en acciones concretas.

Lo primero que hay que tener para desarrollar de un sistema de gestión estratégica es tener definida una “Estrategia Empresarial”. Esto que parece una perogrullada, no lo es en absoluto. La empresa que quiera implantar un BSC debe tener clara su Misión (Para qué existe), su Visión (Qué quiere llegar ha ser) y su Estrategia (Qué hacer para conseguirlo).

El siguiente paso, una vez definida la estrategia, es: no mantenerla en secreto. La estrategia de la empresa no es un secreto que se deba guardar bajo llave y que solo pueden conocer los altos directivos. Si el empleado final no conoce la estrategia de la empresa ¿Quién la pondrá en práctica?. ¿Cómo podrá ejecutar sus acciones orientado a conseguir la visión de la empresa, si desconoce la estrategia para conseguirla?. ¿Quien tomará las decisiones del día a día para conseguir los objetivos marcados?.

La clave del éxito es sin duda conseguir alcanzar la alineación estratégica de
arriba abajo. En una empresa ideal (utópica) , absolutamente todos los
miembros de la organización, conocerían, comprenderían y estarían comprometidos
con la estrategia global.

Pero esta situación se acerca a la utopía así que tenemos que traducir la estrategia en objetivos locales más cercanos a cada grupo de personal y en indicadores que nos puedan decir si se están cumpliendo o no esos objetivos.

Los tres mecanismos típicos que nos permiten traducir nuestra estrategia son:
1) Programas de comunicación y formación. Es el paso inicial se deben estructurar como auténticas campañas de marketing interno, creando concienciación y promoviendo conductas estratégicas.
2) Programas de objetivos. Una vez tengamos un nivel básico de comprensión, deberemos traducir los objetivos de alto nivel a objetivos personales, de equipos y de unidades de negocio.
3) Sistema de incentivos. Que recompensen las acciones orientadas estratégicamente. Pero mucho cuidado con como lo implementamos, el BSC no debe derivar nunca en un sistema de castigo-recompensa, aunque por desgracia muchas veces ocurre esto.

Ya estamos en disposición de comenzar la implantación de un BSC y la creación de sus dos elementos básicos: El mapa estratégico y el Cuadro de Mando Integral.

Que lo dejo para el siguiente post.

Balanced Scorecard: El acantilado (parte I)

Siempre que empiezo una clase o seminario o conferencia me gusta ilustrarla con un ejemplo inicial impactante, entre mis favoritos estan "el pollo sin cabeza", "los doce monos" y "el coche y el acantilado".

Este último es el que siempre utilizo para hablar de Cuadro de Mando Integral o Balanced Scorecard.

Dos pasajeros en un coche se
dirigen a un acantilado a toda velocidad.

El compañante pregunta:
“¿Seguro que vamos bien?”

y el conductor le responde:
“No te preocupes, nos queda más de la mitad del depósito.”.

Dirigir una organización utilizando como única guía los sistemas financieros, es muy parecido a esta situación. Una visión que no tenga en cuenta los intangibles ni el largo plazo nos puede llevar a la catástrofe.
Por esta razón están surgiendo nuevos modelos de gestión que utilizan,además de la perspectiva financiera tradicional, cualquiera otra perspectiva de la organización que nos permita vislumbrar su situación real.
Una de estas aproximaciones es el Balanced Scorecard (BSC), concebida por Robert S. Kaplan y David P. Norton a principios de los 90,

Una solución: 4 Perspectivas

La propuesta BSC de Kaplan y Norton incluye cuatro perspectivas “equilibradas”: Finanzas, Clientes, Procesos internos y Formación. Esto es solo una posible solución, cada empresa podrá añadir tantas perspectivas como considere oportunas para su control., aunque se recomienda que se mantengan siempre estas cuatro y que el total no sobrepase las seis.

¿Por que controlar estas cuatro perspectivas?. La hipótesis es sencilla: si nuestra gente esta bien formada, diseñará buenos procesos, que satisfarán a nuestros clientes, que nos seguirán comprando y repercutirá en una buena situación financiera. Si cualquiera de estos elementos causa-efecto se desnivela, se desequilibra, la situación de nuestra empresa puede cambiar, por eso debemos al menos controlar estos cuatro ya que nos garantizan el equilibrio entre una visión puramente cortoplacista y una visión demasiado centrada en el largo plazo.

Sobre estas perspectivas se definen una serie de indicadores cuyo objetivo es mostrarnos de forma sencilla el estado de salud de nuestra empresa en esa perspectiva, permitiendo así la creación de Cuadros de Mando Integrales (CMI) y la unificación de las visiones a corto y largo plazo.

Dando respuestas a preguntas.

Como ya he comentado, estas cuatro perspectivas deben tomarse a modo de punto de partida básico y nunca como objetivo final. Cada perspectiva da respuesta a una pregunta.

· Perspectiva Financiera: ¿Qué objetivos financieros queremos alcanzar, para satisfacer a nuestros accionistas?
· Perspectiva Clientes: ¿Qué necesidades de nuestros clientes debemos satisfacer para alcanzar los objetivos financieros que nos hemos marcado?
· Perspectiva Procesos Internos: ¿En que procesos debemos llegar a la excelencia para satisfacer a nuestros clientes y accionistas?
· Perspectiva Formación: ¿Cómo debemos aprender y adaptarnos para alcanzar nuestros objetivos?

Bueno el resto para los siguientes post

Nace la revista GdR (Gestión del Rendimiento)

En estos dias he estado muy liado entre otras cosas ayudando a llevar a cabo un proyecto muy interesante, una revista en papel, de esas antiguas que se leían antes de que existieran los blogs, pues de esas. Se trata de la revista GdR (Gestión del Rendimiento) Al final me he involucrado tanto que hasta tengo sección propia y todo, con un título bastante críptico "Gap de Oxímoron".

El artífice de esta experiencia es Paco Marín, que no solo ha conseguido enredarme a mi, sino tambien a otro conocido blogger del BI Jose Maria Arce.

El caso es que el primer número ya esta en la calle, este año serán 4 números y para aquellos que llegueis tarde al primer número os podreis subscribir GRATIS a los 3 siguientes.

Os pongo el índice del primer número para que podais ver de que trata.

Espero que os guste.

Starting Area (Características: Tercera Parte)

_{(Nota: Este post lo estoy haciendo desde los Docs de Google a ver como queda. Es que desde que perdí todos los datos de mi agenda, me he pasado a las aplicaciones de google y la verdad me están sorprendiendo gratamente.)}

Con este post acabo la trilogía de la STA, lo prometo ;-D.
Por cierto dejad de comentad tanto que no me da tiempo a leerlo todo
_{(ostras, no veo como se pone la letra en "irónica", solo he encontrado "cursiva", je je)}

Características:

1) Responder de forma ágil cualquier petición decisional que nos surja.

Si mezclamos información de detalle, con estructuras de Inmon, podemos responder de forma ágil a cualquier petición de información decisional.
Luego si vemos que es necesaria entonces ya crearemos una estructura de análisis de tipo dimensional (Kimball) si es necesario. Pero muchas de estas peticiones suelen morir al cabo de pocas semanas, de esta manera podremos ver el uso que se hace y si debemos incorporarla definitivamente a la estructura estable del DWH. Siempre que nos pidan algo muy específico, podemos poner la información en "cuarentena" en la Starting Area antes de decidir si es lo suficientemente madura para formar parte del DWH.

Así en la Starting Area tendremos información de detalle (operacional), información agregada (operacional) al estilo ODS, información agregada decisional (Inmon) que esta esperando la "madurez" para pasar al DWH e información unificada de diferentes modelos que sirve de embrión al Masterdata.

¿Que información almaceno entonces en la STA?
Pues en la Starting Area tendremos 4 tipos de información diferente:

1. Información de detalle (operacional) inicio de los procesos ETL.
2. Información agregada (operacional) al estilo ODS.
3. Información agregada decisional (tipo Inmon) que esta esperando la "madurez" para pasar al DWH.
4. Información unificada de diferentes modelos que sirve de embrión al Masterdata..

2) Diluirse a medida que la estructura decisional madura.

Obviamente mucha de esta información que ahora estamos poniendo en la STA, tiene que seguir si propia evolución hacia un sistema decisional mas completo, la información de tipo 2 y 3 deberían ir migrando hacia un DWH estilo Inmon de forma gradual, la información de tipo 4 evolucionar hacia un proyecto de Masterdata y la de tipo 1 ir desapareciendo a medida que se consolidan en otros sistemas los otros tres tipos de información.

Por eso la Starting Area tiene una fecha de caducidad.

Starting Area (Funcionalidades: Segunda Parte)

En el anterior Post introduje como nació la Starting Area (STA de ahora en adelante).

Esta idea ha ido evolucionado y la STA cumple actualmente 4 funcionalidades y posee 2 características (que ya avancé en el anterior post)

1) Relanzar los procesos de ETL cuando los necesites.

La primera de ellas la pudimos ver en el anterior post. Se trata de tener siempre "llenos" los primeros pasos de los procesos ETL, y no borrar esa información. Para ello cogemos el último nivel de agregación desde el que construimos el DWH. Obviamente como vamos a dejar la información de forma permanente la STA debe estar obligatoriamente en una base de datos relacional diferente a la Staging Area (STG) para poder optimizarla y realizar tunning de forma separada en el caso de que el volumen de datos así lo hiciera recomendable.

2) Ser el embrión del MasterData

Obviamente todos estos procesos necesitan de una unificación del modelo cuando las fuentes de datos son heterogeneas. Por ejemplo si estamos unificando el concepto "Cliente" podemos tener un modelo E-R de Cliente en el ERP que nada tenga que ver con el "Cliente" del CRM y que en la aplicación de gestión comercial tenga otro significado muy distinto. Obviamente desde el punto de vista decisional nosotros tenemos un único "Cliente" así pues en la STA, cuando las fuentes de datos son heterogeneas ,nos quedamos con el último nivel de detalle pera una vez unificado el modelo. Así esta tabla puede ser unificada no solo en la parte decisional sino que cualquier otra aplicación que quiera hacer uso de "Clientes" puede intorducirla como su fuente de datos operacional, de esta manera tenemos el embrión de un MasterData de la organización que mas adelante pueda servirnos tanto para la parte de sistemas de información transaccionales, como para los sistemas de información decisionales. Es una buena manera de empezar a difundir el concepto de MasterData en aquella empresas que no están maduras.

3) Proveer de Reporting para la trazabilidad decisional a nivel de detalle.

Muchas veces desde el DWH necesitamos vincular con información de detalle cuyo detalle tenemos que ir a buscarlo al operacional, por eso nos puede llegar a interesar tener algún repositorio con esa información ya almacenada (siempre que no estemos tratando de información a tiempo real). Por ejemplo, si queremos saber el número de incidencias de producción la semana pasada lo tenemos fácil, pero si queremos buscar una descripción de los incidentes de gravedad 1 de esa misma semana para ponerlo en el Informe, entonces deberíamos ir al operacional. Para facilitar esto lo que podemos hacer es traernos un nivel de detalle mas bajo que el que estamos utilizando en el DWH y vincularlo con la base de la estrella al mas puro estilo Inmon, como Reporting. Alguien podría decir que esto no es mas que un ODS (Operational Data Storage) y le daría la razón pero con un matiz, y es que los ODS carga información operacional agregada y yo cargo información de detalle muy bajo, ya que la información típicamente agregada del ODS para mí es parte del modelo del DWH al combinar Inmon y Kimball en la base de la estrella.

Este nivel de detalle bajo nos puede ayudar también a crear el MasterData y nos da esa capacidad de reporting complementaria al DWH sin que tengamos que molestar a los operacionales.

4) Realizar mejora de la calidad de forma "continua"

La STA como he dicho tiene un repositorio diferente de la STG y obviamente del DWH, así que podemos lanzar los procesos de carga de la STA con una periodicidad mucho mas pequeña que no la del DWH limpiando y puliendo los datos antes de hacer la carga definitiva del DWH. Esto nos da la posibilidad de detectar los errores antes de lanzar los procesos definitivos y mas costosos, mejorando la calidad del dato y los tiempos de los procesos de carga.
De esta manera podemos construir escenarios en los que la STA se cargue diariamente y el DWH mensualmente. La mayoría de los posibles problemas de calidad del dato tienen 30 oportunidades de ser detectados antes de cargar el DWH.

Estas son las funcionalidades de la Starting Area, en el próximo (el último de esta trilogía) comentaré como construirla y sus dos características:

1) Responder de forma ágil cualquier petición decisional que nos surja.

2) Diluirse a medida que la estructura decisional madura.

Starting Area (Orígenes: Primera Parte)

Bueno, me lanzo al final. Llevo varios dias intentando ver como explico lo de la starting area, lo he explicado muchas veces y lo he puesto en marcha varias mas, y funciona, pero no se porque, escribirlo, me da un poco de respeto y lo he estado evitando. Pero en fin allá voy.

La Starting Área (STA) tiene dos carácterísticas principales, la primera es que está ligada intrínsecamente al concepto de metodologías ágiles y la segunda es que tiene fecha de caducidad.


El concepto es el siguiente: La idea de la Starting Area la empecé a madurar al encontrarme "malas" implementaciones de la Staging Area. La Staging Area (STG) por definición es el área donde se ejecutan los procesos ETL y que tiene un caracter volatil, es decir al finalizar el proceso, la Staging debe de quedar vacia, sin contenido. Sin embargo, me encontraba que muchas implementaciones, tanto propias, como de otros arquitectos de DWH, acababan dejando información en la STG. En mi época más purista blasfemaba cada vez que me encontraba una STG con datos, pero a medida que trabajaba con estas arquitecturas me daba cuenta que si bien en algunos casos era pura negligencia, en otros casos incluso yo mismo estaba dejando esos datos "permanentes" de forma deliberada. Esto siempre ocurría en implantaciones con mucha limpieza de ETL, al final decidia no borrar la STG para poder ir haciendo pruebas en desarrollo y no tener que esperar a cargar de nuevo los origenes. Al final, tenía un proceso ETL en el que en lugar de finalizar con el borrado de la tabla, dejaba los datos hasta la siguiente ejecución , con lo que cada proceso se iniciaba borrando los datos que habían sido utilizados en la anterior ejecución.

Obviamente esto solo lo hacía durante el desarrollo del DWH y una vez lo ponía en marcha cambiaba el modelo a la ejecución normal dejando la STG totalmente vacia. Y así lo estube haciendo hasta que cierto día en uno de mis clientes, alguien cambió un elemento de una jerarquía en el operacional por error, una operación que el ERP validó pero que no tenia sentido lógico, error que se propagó a la información que daba el DWH, y que nadie comprobó hasta al cabo de varios dias. Con lo que teníamos que rehacer el DWH y con urgencia, porque al dia siguiente había la reunión del comité de dirección. Me avisaron a las 9:00 de la mañana, tardé en borrar la información erronea unos 20 minutos y tube que esperarme hasta las 20:00 horas que cerraban el turno para poder conectarme al operacional y lanzar la carga del DWH. A las 21:00 ya estaba cargado y solventado, y a las 21:30 cogia el tren hacia mi casa pensando "esto no tiene sentido, tiene que haber una manera mejor de hacer las cosas". Y ahí fué cuando empecé a crear mi idea de la Starting Area.

Su primera versión consistió en no borrar el primer estadio de todos los procesos ETL del DWH, dejarlo como en el modo de desarrollo, es decir borrando al iniciar, pero solo en el primer paso de cada proceso ETL, con el que "todo empieza", de ahí su nombre "Starting Área". Eso me daba la ventaja de poder ejecutar el proceso anterior de nuevo sin necesidad de esperar a la ventana de tiempo del proceso de carga, sin embargo no me solucionaba nada cuando tenía que rehacer varias ejecuciones anteriores del proceso ETL, o si tenia que recargar TODO el DWH.

Así que di paso a mi segunda versión que solamente utilizaba en desarrollo y que consistía en hacerme una copia exacta de las fuentes de datos en un repositorio diferente. Y cuando estaba haciendo esto me di cuenta que estaba volviendo a los origenes del DWH, en los que haciendo una copia "exacta" del operacional se construían los sistemas decisionales. Y entonces me dí cuenta que algo se me estaba escapando y que así no iba bien, que tendría que volver a los origenes y ver que estaba pasando. Fué así como empecé a descubrir a Inmon y como me replanteé las funciones que debería tener la Starting Area.

Obviamente la Starting Area (STA) no se ha quedado en simplemente eso, ha evolucionado mucho mas, dando soporte a otras necesidades que me he encontrado, como la hetorogeneidad de fuentes que comentaba en el post anterior, el reporting operacional (funcionalidades de ODS) y mejoras en los procesos de calidad del dato, siempre desde la perspectiva de las metodologías ágiles, en el que el tiempo de desarrollo y de entrega ha de ser de ciclo corto.

Pero ya se me ha hecho muy tarde y eso lo dejaré para el próximo post.

La heterogeneidad de fuentes complica la toma de decisiones

Comunmente nos encontramos con entornos empresariales en los que el ERP es de un fabricante, el CRM de otro, el SCM es un desarrollo a medida, ninguna de las aplicaciones se ejecuta en el mismo sistema operativo, casi todas están desarrolladas en diferente lenguajes de programación, y para diferentes plataformas, tenemos múltiples bases de datos con información crucial y no contrastada, y en los que el CIO se tira de los pelos día si y día también.

Son generalmente sistemas de información con una larga evolución histórica y que se han visto abocados sin remedio a convivir con multitud de subsistemas. Citaré cuatro ejemplos de cómo se puede haber originado, y seguro que alguno de vosotros se encuentra en esa misma situación:

* Heterogeneidad originada por el paso del tiempo. Nuestra empresa inicialmente comenzó con un ERP sobre un AS400, con el paso del tiempo vió la necesidad de un SCM, pero como las tecnologías habían cambiado decidió hacer una aplicación a medida en un entorno cliente/servidor. Pasaron unos años más y la web era lo último y se decidió poner un sistema CRM estándar y basado en J2EE, etc, etc.

* Heterogeneidad originada en departamentos. Algunos departamentos de nuestra organización tienen necesidades diferentes y/o muy específicas, que les han hecho optar por SI departamentales, en los que existe un alto grado de independencia con respecto al SI organizacional.

* Heterogeneidad originada por fusiones. Nuestra empresa, se ha fusionado con otra empresa heredando todos sus SI y duplicando funcionalidades. Son entornos en los que nos podemos encontrar con dos ERPs conviviendo a la vez.

* Heterogeneidad originada por descentralización. Tenemos muchas filiales distribuidas geográficamente y es difícil controlar la evolución de los SI en cada una de ellas debido a que poseen un alto grado de independencia necesario para adaptarse a las características especiales de su zona geográfica en concreto.

¿Cómo podemos implementar un sistema que nos ayude a tomar decisiones en estos entornos tan caóticos?.
¿Cuales son las pautas metodológicas que nos harán crear un sistema decisional que no tenga los pies de barro?.

Mi solución mezcla ingredientes de Masterdata, ODS y Staging Area, claro esta sazonada con un pizca de Inmon, es lo que llamo la Starting Area y a la que pienso dedicar el próximo post.

Antonio Valle, la disfunción cromática y la disonancia cognoscitiva

La ventaja de poder colaborar con Antonio Valle es que siempre se saca algo de la chistera que te deja con la boca abierta y con cara de tonto. El martes fue uno de esos dias y hasta hoy no te tenido tiempo de "novelar" lo ocurrido.

Estabamos en una charla animada, en una consultoría, evaluando los posibles escenarios finales y los resultados que se podrían derivar de que un determinado KPI /Métrica, apareciera en rojo en el cuadro de mando. A lo que yo argumenté que si sucedia ese hecho, era un claro indicador de que estaba pasando en hecho X y que teníamos obligatoriamente que tomar la decisión Y.

A lo que Antonio, se me quedó mirando, hizo una pausa de esas que tanto le gustan y nos espetó a todos los presentes en la reunión : "Bueno, eso será así siempre y cuando el analísta no tenga disonancia cognoscitiva o disfunción cromática".

Y ahí se me quedó la cara de tonto, pero es verdad, todo sistema decisional muestra la información de la manera objetiva y nos creemos que con eso es suficiente que ya esta hecho el trabajo, pero aún faltan dos procesos:

• La recepción de la información en el cerebro del análista
  

Casi todas las herramientas de BI, muestran la información o a través de reports o cuadros de mando o complejas anílíticas interactivas....¿pero llega esta información de forma correcta al receptor? ¿Que pasa si muestras gráficos de barras, tendencias, diagramas de pareto, alarmas, códigos semáforicos y el analista sufre disfunción cromáticamas conocida como daltonismo?

Imaginaos que teneis esta gráfica triple y simplemente teneis que explicar porque no se ha conseguido el objetivo (en azul) y las discrepancias entre lo planificado (en verde) y lo ejecutado (en rojo).

• La ejecución del proceso físico de toma de decisiones en el analista.
  

Que pasa si la información que recibes entra en frontal conflicto con tu paradigma decisinal, que pasa si esa información hace que tengas que tomar una decisión que está en total disonancia con lo que tú realmente piensas. ¿la tomarás igualmente o cambirás el peso que esta información tiene en tu toma de decisiones?. Eso es lo que se llama disonancia cognitiva y que en el artículo que os linko se resume como:

"Es el conflicto mental que abunda en la experiencia cuando se presentan evidencias de que una creencia propia o asunción personal es incorrecta. La teoría de la disonancia cognoscitiva afirma que hay una tendencia en la gente a reaccionar para reducir tal disonancia. Una persona puede evitar la nueva información o convertirse manipulador de argumentos para mantener su creencia o juicios.
Por ejemplo, Erlich, Guttman, Schopenbach y Mills (1957) mostraron que los nuevos compradores del coche evitan selectivamente los anuncios de la lectura para los modelos del coche que no eligieron, mientras que por otra parte los atrajeron a los anuncios para el coche ellas eligieron. "

Ambos procesos pueden sufrir fallos que nos hagan tomar una decisión erronea, y eso no hay sistema decisional que lo pueda solventar.

Así que mantened vuestras mentes abiertas :-D

Green Lantern Methods for Redesign (GLMR)

Despues de darle muchas vueltas, esta tarde he pasado a la accióm. Junto con mi amigo Marti Ibarz, nos hemos puesto a darle forma a una posible metodología ágil de rediseño de data warehouse. El porqué me he decidido finalmente a hacer una metodología propia para este proyecto y no reutilizar ninguna de las existentes, es principalmente el hecho de que la casuística de un proyecto de rediseño no ha de ser la misma que la de un proyecto que empieza desde cero. También me da la oportunidad de probar una metodologia ágil en un proyecto de menor riesgo.

El esqueleto resultante es este que os comento a continuación, y que a partir de ahora voy a llamar Green Lantern Methods for Redesign o acronizando un poco GLMR.

GLMR será un conjunto de métodos que podrán aplicarse a cualquier proyecto de rediseño de aplicaciones, la primera versión, claro esta, será (porque aún no la tengo hecha) la versión para Data Warehousing (GLMR for Data Warehousing) pero animo a cualquiera a que realice su propia versión para proyectos de rediseño en otros ámbitos.

El esquema principal se compone de una primera fase lineal en la que nos haremos una idea de la vision global y de como la evolución del negocio ha hecho que nuestro sistema sea insuficiente para las necesidades de la organización, a esta fase le sigue un ciclo iterativo en el que se rediseñan los datamarts y en el que se obtiene check list de implementacion de funcionalidades y optimizaciones para cada datamart. El proceso finaliza con otra fase lineal en la que se ponen los cambios en marcha y se planifica los criterios que harán que en un futuro se desencadene de nuevo otra reingenieria.


Es una version muy simplificada sobre la que seguiré trabajando, los siguientes pasos que voy a dar implican la definicion de las tareas de cada fase, la documentación resultante (que será la mínima necesaria) , los roles que han de intervenir (donde el usuario final ha de formar parte del equipo con un papel destacado) y las reuniones e hitos de control.

Si, ya lo se, TODAVÍA ESTA MUY VERDE.... je je je (no he podido resistirlo), pero creo que va a dar un buen resultado.

Como siempre admito sugeriencias, aunque ya estoy perdiendo la esperanza :-(

¿Dynamic Systems Development Method para DWH?

Después de descartar SCRUM mi siguiente metodología candidata es DSDM, y creo firmemente que dentro de las metodologías ágiles puede ser la adecuada, a ello me ha llevado mi gran intuición y el white paper llamado "DSDM and Data Warehousing" que yo con pocas pistas enseguida pillo el concepto. ;-D

Veamos un poco de que se trata esto de DSDM

DSDM se ha desarrollado teniendo como ideas fundamentales:

· Nada es construido a la perfección a la primera.

· La vieja regla del 80-20 es cierta ( el 80% de las funcionalidades del proyecto se realizan con el 20% del tiempo, y el 20% restante, los detalles, consumen el 80% del tiempo restante)

· Es improbable que alguien conozca todos los requisitos del sistema desde el primer día.

De estas ideas nace una metodología cuyas principales características son:

· Un proceso iterativo e incremental

· Un equipo de desarrollo con el que el usuario final trabaja conjuntamente.

Este principio me puede ser util para la reingenieria de data warehouse que os comentaba en el anterior post. La idea dominante en DSDM es que tiempo y recursos se mantienen como constantes y se ajusta la funcionalidad de acuerdo con ello. Es decir, la idea no es “¿cuánto me va a costar desarrollar este sistema?” sino que mas bien es “Con este tiempo y estos recursos ¿cuántas de las funcionalidades del sistema puedo hacer. Si hablamos de reingeniria de Data warehousing, seguramente deberiamos preguntarnos: ¿Cuanto podemos optimizar y cuantos nuevos enfoques decisionales podemos añadir a los existentes?

Entiendo que la naturaleza de las preguntas necesariamenta ha de ser específica para el proyeco, pero las dos características princiapels encajan a la perfección en el proyecto que quiero desarrollar.

Sigamos pues por este camino.

DSMD propone cinco fases, las tres últimas son iterativas:

· Estudio de la viabilidad. Lo primero que se evalúa es si DSDM se puede o no aplicar al proyecto.

· Estudio del negocio. Se estudia el negocio, sus características y la tecnología. Debe crearse el Plan de Prototipado (base del DSDM).

· Modelado funcional. En cada iteración se planea se refinan los procesos funcionales del negocio sobre el prototipo

· Diseño y construcción. Aquí es donde se construye la mayor parte del sistema. El prototipo se vuelve apto para su utilización por parte de los usuarios

· Implementación. Pasamos de un prototipo a un sistema de producción. Se entrena a los usuarios para que lo usen..

En el gráfico queda mas claro (pulsad sobre el para ver mas grande)

Ahora el siguiente paso que tengo que dar es estructurar una metodología de reingenieria de DWH basada en DSDM y probarla.

¿Alguna sugerencia de por donde empezar?