El consultor de BI: ese bicho raro

Con este post saldo una deuda historia que tenia con TOAD.

Son ya unos cuantos años los que llevo en el mundo del BI, y cada vez me doy cuenta de que necesito saber mas y mas y mas para poder hacer eficientemente mi trabajo.
Un consultor de Business Intelligence necesita aportar un valor diferencial que haga avanzar el proyecto en el que participa no solo desde el punto de vista tecnológico sino desde el punto de vista de analisis de negocio. Debe saber de tecnología y debe de saber de negocio, con lo que me recuerda un poco a la figura del CIO, podríamos decir que un consultor de BI experimentado es un CIO en potencia, pero un CIO con mayúsculas, de esos que hay pocos.

¿Cuales deberían ser las características de debe poseer un buen consultor de BI? Pues son muchos, aquí he hecho una lista al estilo de las listas de Josep Curto ).

1) Características Personales

• Comunicativo
• Proactivo
• Buen Mentor
• Saber escuchar
• SABER PREGUNTAR.
  

2) Conocimiento que debe poseer

• Conocimiento analítico de TODAS las áreas de negocio (aquí debe de saber que preguntas se hace el negocio y como se responden. Esta es la tarea de nunca acabar)
• Conocimientos de Diseño de Datawarehouse (modelos Inmon, Kimball, y variaciones)
• Conocimientos de Diseño ETL
• Conocimientos de SGBD (Sistemas Gestores de Bases de Datos) Relacionales, Multidimensionales y Asociativos
• Conocimientos de Plataformas de BI (Oracle, Cognos, Business Objects, MicroStategy, SaS, Microsoft, QlikView, etc...).
• Conocimiento de ERPs
  

3) Pragmaticidad para mezclar todo eso y dar una solución adecuada en costes y beneficios a los usuarios de negocio.

Una vez tenemos todas estas características en un consultor nos encontramos con un milagro de la naturaleza que al menos tiene que levitar dos palmos por encima del suelo y será facilmente reconocible por su brillo

El resto de los mortales nos dedicamos a PREGUNTAR CON MANO IZQUIERDA AL USUARIO y rezar para entender lo que necesita :-D

Como muestra os dejo esta grandísima tira de Dilbert que refleja la situación real en la que muchas veces nos encontramos los consultores de Business Intelligence.

¿Cómo creeis vosotros que debería ser un consultor de BI?.

Updated 24/06/2009.

Otro hecho que se nos olvidaba sobre el consultor de BI es que además el cliente cree que debe explicarle cuales son los mejores KPIs para controlar sus procesos, que debe asesorarle sobre como organizar su negocio y que debe "chivarle" los KPIs de la competencia.

Y yo pregunto
¿un consultor de BI ha de ser un consultor de negocio o son dos cosas distintas?
¡Y quiero que alguien me responda !
.......
(En el puesto instalado en el hall del teatro)

Dirección de proyectos BI: Conservar el conocimiento analítico

¿Como se gestiona el conocimiento si menganito/a se va de la empresa?

El punto que voy a aboradr hoy precisamente se encuentra en uno de los principales déficits organizativos en la gestión del conocimiento de los departamentos de Business Intelligence.

Uno de estos icebergs son los procesos de análisis personal, esos que solo Pepito o Juanita saben hacer. Esos que hacen los analistas que son brillantes y que de verdad nos aportan una ventaja competitiva. Esos que NADIE SE DEDICA A CAPTURAR.

Las necesidades analíticas siempre han existido dentro de las organizaciones, y los empleados han tenido que utilizar seguro su ingenio para sacar esa información de una manera u otra. Acceder a ese conocimiento, que no lo olvidemos ha necesitado de tiempo y dinero de la empresa para crearse, y que reside en una persona y que es de muy dificil reutilización, hace que un proyecto de BI se encuentre con dos tipos de barreras a solventar:

• Procesos de análisis desconocidos que se deben integrar en el sistema para que ese conocimiento no se pierda.
• Defensas de nichos de poder que dificulten la implantación del proyecto.
  

No os digo nada si lo juntamos con una alta rotación de empleados, las pérdidas de información y de control de procesos son considerables.

Así pues una de las manera de conservar este conocimiento es trabajar en lo que yo denomino "Libros de Petete". En estos documentos corporativos, deberemos plasmar las preguntas mas comunes que se hacen los analistas de cada departamento junto con la forma de resolverlas, los pasos a aseguir los informes a constrastar y el tipo de conclusiones.

Obviamente esto no se hace de la noche a la mañana y necesita de mantenimiento, y de ninguna manera capturará la genialidad de algunos analistas que ven correlaciones que solo ellos ven, pero si nos permitirá reducir el gap en la gestión del conocimiento analítico.

He decidido ser un Slowgger

Estaba yo meditando sobre lo que me cuesta poner entradas en este blog, y que la imposición que me hice a mi mismo de poner 2 post mensuales no la cumplo ni para atrás. Así que solo me quedaban dos soluciones.

a) Ser honesto y cerrar el blog.
b) Inventarme un concepto para que nadie me reprochase lo lento que escribo.

Por eso acabo de inventar

La iniciativa Slowgger, que engloba a aquellos blogger que tienen el espíritu del autentico blogger pero la pereza les invade o el tiempo les consume, y escriben sus post muy muy lentamente (slowly vamos).

Y como toda iniciativa debe de tener un buen logo pues aquí esta el nuevo logo que todos aquellos que os sintáis identificados por este manifiesto lo podéis lucir en vuestros blogs.

Ahora ya nadie me podrá echar en cara que escribo poco :-D

¡¡¡¡Tu también puedes ser un Slowgger!!!!!

Gran éxito del 2º evento de BI Beers

Hola esto es una entrada plagio, perdón inspirada en la de Josep Curto que es quien se ha currado el segundo evento, solo me he permitido añadir alguna cosa en rojo, que si quereis saber quien es se lo debes preguntar a Josep en el debate en su post

A modo de resumen como en el anterior evento. Estos son los números del mismo.

• 3 bloggers
• 3 no bloggers
• 1 comercial vendiendo servicios y repartiendo tarjetas :-D
  
• 1 pinta de Guiness
• 11 pintas de rubia
• 2 horas y media de agradable conversación.

(mas de un 50% de crecimiento si contamos los 15 minutos del repartidor de tarjetas)

¿Quienes fueron?

Los bloggers:

• Chema Arce de Business Intelligence Blog.
• Josep Curto de Information Management.
• Salvador Ramos de SQL Server Si!

Y: Álvaro Galán, Rafael Rojo y María Nilley.

¿De que se habló?

En un entorno hostil (lleno de hooligans del Liverpool preparándose seriamente para el partido), nos explicamos batallas de guerra. Criticamos la poca profesionalidad del sector. De la poca visión. De lo centrados en los colores y efectos y no en lo importante: analizar. Y en lo más importante aún: el modelo.Y nos repetimos: la basura sólo genera basura (garbage in, garbage out). No hablamos ahora de la siguiente convocatoria (pero no os preocupéis habrá más). Ni tampoco de muchachada nui. También se comento que “lo que fue escrito vuelve a serlo” está presente en los artículos de muchos blogs actuales.

En fin, justo lo que queríamos que fuera, una reunión de amiguetes tomando unas cervezas y hablando de Business Intelligence.

Dirección de proyectos BI: El éxito y el fracaso

No paguéis el rescate, pero la crisis me está matando a trabajar (por suerte).
Así que a pesar de ir muy desbordado, hoy os pongo una pequeña reflexión sobre dirección de proyectos BI.

¿Éxito y/o Fracaso? Son palabras que surgen muy a la ligera de la boca de muchos usuarios cuando quieren juzgar el resultado de un proyecto de Business Intelligence, pero... ¿a que nos estamos refiriendo? ¿Qué es éxito y qué es fracaso?. Y lo mas importante... ¿Cómo lo medimos?

Seguramente estáis pensando la respuesta es fácil, que con plazos de entrega, cumplimiento de funcionalidades, volumen de informes que se esperaban, métricas aportadas por el proyecto, cuadros de mando, etc.,

Pues estáis muy pero que muy equivocados. El éxito de una solución BI también tiene una parte puramente de carácter intangible que debe ser evaluada, especialmente cuando se trata de sistemas de información estratégicos. Evaluar los beneficios intangibles de los sistemas de Business Intelligence, es quizás la parte más difícil de todas, pero se tiene que hacer el ejercicio mental antes de empezar a desarrollar.

MUY IMPORTANTE: Es más fácil conseguir un quick win con un intangible, sobretodo si ese intangible es importante para algún alto cargo de la compañía que pueda ser reacio al proyecto.

Así pues debemos saber que se espera del proyecto ANTES de empezar, definir sus objetivos tangibles y especialmente los intangibles, que posiblemente nos generen más fácilmente un éxito en el proyecto, que luego nos permita trabajar con una mayor renta de confianza en el éxito.

Durante la ejecución del proyecto, en cada reunión de seguimiento se deben de poner encima de las mesas los objetivos que se han ido alcanzando para que veamos realmente la evolución del Sistema de Business Intelligence, así al final de proyecto podremos evaluar fácilmente si ha sido un éxito o si ha sido un fracaso.

Pensad que si usamos una metodología ágil en la que involucremos al usuario desde el inicio en el proyecto nos permitirá aumentar sustancialmente el éxito del proyecto, por dos razones, la primera es que conoceremos mejor las necesidades del usuario y como quiere utilizar la información, y la segunda es porque difícilmente el usuario dirá que ha sido un fracaso si él es parte del equipo :-D

Segundo evento oficioso BI Beers

Después de la primera edición que se realizó en Barcelona, esta vez el BIBeers se traslada a Madrid.

Ha sido una ardua votación. Ya os lo podéis imaginar. Primero la ciudad y después el día y el lugar. Agradezco a todos los que han participado en la misma. Si os preguntais dónde a sucedido todo eso ha sido en el grupo de LinkedIn llamado BIBeers (como no podía ser de otra manera).

¿De qué va el evento?

Nos reunimos para hablar de forma distendida, entre cerveza y cerveza, de Business Intelligence y claro de otras cosas.

¿Dónde se hace el evento?

Moore Irish Pub en C/ Felipe III 4, 28012 Madrid (cerca de plaza mayor). Metro más cercano: Opera y Sol (se debe caminar un poquito). Más pequeño, muy auténtico,…

Google Maps.

¿Cuándo se hace el evento?

23 de febrero de 2009 a las 18:00.

Aquellos que tengías la intención de asistir, por favor enviadle un mail a Josep (josep.curto@gmail.com), sobretodo por si superamos la convocatoria anterior (de cuatro personas) y tenemos de cambiar de lugar.

¡Os espero!

Un saludo.

Feliz Navidad y Merry Crisismas

Os deseo una Feliz Navidad y un prospero 2009 (si eso es posible).
Aqui os dejo con mi árbol de Navidad de este año (si, lo he decorado yo, ¿se nota?)
Nos vemos de nuevo en 2009.

Dirección de proyectos BI: Organización y Medición

Al fin voy a cumplir mi palabra, tras la encuesta que hice este verano, y voy a hablar sobre dirección de proyectos de Business Intelligence. Eso si, van a ser una serie de post de frecuencia indefinida y posiblemente no consecutivos.

Lo primero que hay que tener en cuenta a la hora de comenzar un proyecto de Business Intelligence es sin duda la organización en la que lo vamos a desarrollar.

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 . Crear y gestionar una cultura de la medición de indicadores necesita tiempo de maduración y no puede iniciarse de la noche a la mañana, así que tenemos que medir muy muy bien cuales serán nuestros pasos y la ambición de proyecto según el panorama con el que nos encontremos.

La pregunta principal que debemos responder es:

¿Existe una cultura de la medición?.

• Si no hay una cultura de la medición arraigada, deberemos orientar nuestro proyecto de business intelligence hacia el reporting operacional, el reporting táctico, y sentar las bases de unos incipientes modelos de análisis multidimensional.
• Si la cultura de la medición está presente pero no arraigada, eso nos dará la posibilidad de dar paso a los cuadros de mando tácticos, fomentando que los mandos intermedios, comiencen a utilizar métricas de control.
  
• Si hay una cultura de la medición, y está muy arraigada, centraremos nuestro proyecto en la gestión estratégica y en analisis de la competencia. Dando paso al reporting, el análisis y los cuadros de mando estratégicos, estableciendo roles y reponsables de métricas , madurando las simulaciones y los indicadores de causa-efecto, y desarrollando análisis de seguimiento de las acciones correctivas.

Una vez respondida esta pregunta, ya tendremos claro cual es el tipo de proyecto de BI que podremos abordar con mayores garantias.
Si por ejemplo estas en una organización sin cultura de la medición y te encargan implantar un Balanced Scorecard, pues sal corriendo de allí que ese proyecto va directo al fracaso.

¿Os habeis encontrado en situaciones similares?

Crystal Methodologies y los equipos de desarrollo

Hacia mucho tiempo que no revisaba Crystal Methodologies, no se trataba de una única metodología sino de un conjunto de ellas centradas en las personas que tienen que desarrollar el software, el equipo es la base de estas metodologías creadas por Alistair Cockburn.

La idea de este planteamiento creo que es muy acertada, no es lo mismo cocinar para cuatro personas que para veinte, no es lo mismo planificar un fin de semana para dos personas que para cuarenta, entonces ¿porque utilizamos la misma metodología para un grupo de tres desarrolladores que para un grupo de quince?. Desarrollar aplicativos ha de ser como un juego en el que todos cooperan, aportan su parte de invención y se comunican, ¿porqué olvidamos esta parte en las metodologías de desarrollo?.

El equipo de desarrollo es el factor clave y solo está limitado por los recursos a utilizar. Mientras mejor sea su comunicación e inventiva, mejor aprovecharán estos recursos. Crystal establece una serie de políticas de trabajo en equipo (Methods) orientadas a fomentar la mejora de estas habilidades. Dependiendo del tamaño del equipo se establecía una metodología u otra designadas por color. Crystal Clear para 3-8 personas, Crystal Yellow para 10-20 personas, Crystal Orange para 25-50,…)Como todas las metodologías ágiles, se basa en ciclos iterativos de desarrollo incremental (de 1 a 4 meses máximo), a lo que añade una reunión previa y posterior al ciclo, en la que reflexiona sobre el proyecto y sobre como ha ido ese ciclo. Antes de comenzar el siguiente ciclo al menos dos usuarios finales deben revisar, de forma independiente, lo desarrollado y validarlo.

De este planteamiento inicial, de Alistair con el tiempo solo se ha desarrollado en profundidad Crystal Clear, de la que recientemente se ha publicado un libro; Crystal Clear: A Human-Powered Methodology for Small Teams

Pero realmente es un lástima, porque la idea de una metodologia adaptativa por tamaño y experiencia del equipo no creo que sea una nada mala solución para los sistemas de Business Intelligence.

Dos nuevos blogs

Hoy me gustaria presentaros dos nuevos proyectos que empiezan estos dias sus singladuras por la web y que tienen pinta de que van a dar mucho de que hablar en los próximos meses.



El primero es Caribis, Inteligencia de negocio y pensamiento sistemico, el blog que ha comenzado mi amigo Carlos Luis y que espero que se lance a compartir todo el conocimiento que posee con todos nosotros.

El segundo me llega a traves Xavier Albadalejo, se trata de un proyecto de mas recorrido, no tanto un blog como un portal de conocimiento basado y centrado en enseñar y aprender SCRUM. Se trata de Proyectos ágiles una web que acaba de nacer y que creo que puede ser una referencia de las metodologías ágiles en España y Latinoamerica.

A ambas iniciativas les deseo mucha mucha suerte.

Mi primer paper chispas

Despues de algún tiempo ya esta disponible mi primer paper científico para un congreso.
He escrito multitud de articulos divulgativos, pero este es mi primer paper científico.

Agile Business Intelligence Governance: Su justificación y presentación

Gracias a Enric Mayol y Joan Antoni Pastor por su inestimable ayuda, me queda mucho que aprender de ellos.

Agile Dashboard Governance

Brillante, brillante el planteamiento de William Laurent en su artículo titulado "Corporate Dashboard Governance".
Hacia tiempo que alguien no leia un articulo tan clarividente y con el que estoy tan de acuerdo.

Si recordais cuando hablabamos de Agile BI Governance, una de las premisas que utilizaba era que se trataba como de un embrión, un caballo de Troya que hiciera que la alineación de IT y negocio se fuera produciendo por pura inercia de los usuarios de negocio y los de TI. Para ello el framework de Agile BI governance deberia ser propiedad conjunta de ambos mundos. La idea es que el uso conjunto hiciera que la empresa madurase conjuntamente. (ver post relacionados)

Pues bien, William va un paso mas allá, dice que esta bien que queramos hacer frameworks de BI/IT/Data/Performance Governance, pero que eso se encuentra en la vida real con muchas ,muchas dificultades, asi que lo mejor es empezar por gobernar los cuadros de mando.

Y para ello se basa en tres argumentos aplastantes y simples.
1) Los usuarios de cuadros de mando son los que realmente controlan y gestionan los procesos.
2) Aplicar una metodologia de Corporate Governance Dashboard nos garantiza que los indicadores y metricas principales del negocio estarán controlado.
3) Una vez fijada esta metodología en los cuadros de mando podemos empezar a descender por el BI Governance, el Data Governance, el IT Governance, etc...

Es simplemente una idea genial, nos centramos en controlar los cuadros de mando y en hacer un framework de governance sobre ellos, ademas si hacemos esto garantizamos que el mejor usuario de negocio, el mas alto jerarquicamente, estará involucrado de inicio en las políticas de governance de la organización, y garantiza que IT se alinee con sus necesidades.

¡¡¡Es brillante!!!!.

Asi que me voy a poner de lleno a desarrollar el Agile Dashboard Governance como primer estado hacia el Agile BI Governance.

P.S: Ahora me surge una duda, debemos governar los dashboards o solo los KPI, ¿seria mejor una Agile KPI Governance?. Vaya duda, ahora no dormiré dandole vueltas.

Cambio de fechas para la Conferencia de Business Intelligence y Data Warehousing

Finalmente por peticion de la mayoria de patrocinadores, la Conferencia de Business Intelligence y Data Warehousing cambia de fechas a unas mas propicias: 11 y 12 de Febrero de 2009.

Seguro que estas nuevas fechas nos permitiran ver muchas mas caras conocidas.

OFFTOPIC: LAS SUBPRIME EXPLICADAS

Este es mi primer offtopic, pero es que no lo he podido remediar, es tan brillante, al fin entendereis la actual crisis, no tiene desperdicio los 7 minutos que vais a dedicar. Genial el final

The Last Laugh - George Parr - Subprime - subtitulos
Cargado por erioluk

¿Improvisar en Business Intelligence?

Esta es la pregunta que me hago tras leer el curioso articulo de Jørgen P. Bansler y Erling C. Havn de la Technical University of Denmark, titulado "IMPROVISATION IN INFORMATION
SYSTEMS DEVELOPMENT".

Lo mejor de los conciertos de Jazz se da en el momento en que los músicos deciden improvisar sobre las piezas de música que estaban interpretando, dando lugar a una nueva composición que generalmente es lo mejor de la noche. ¿Por que no improvisar entonces?.

Para ello revisan lo que debería ser el concepto de improvisación aplicado a las organizaciones, entendiendo que


1) La improvisación ha de ser deliberada, entendiendo que es el resultado de esfuerzos intencionados en nombre de la organización o de sus miembros.
2) La improvisación ha de ser extemporanea, es decir ha de funcionar sin un plan preestablacido, sin guias y sin métodos.
3) La improvisación ocurre durante la acción, igual que en el jazz, se actua sobre el problema tal cual surje sin analizar previamente.
4) La improvisación requiere de la preexistencia de un conjunto de recursos, puestos por la organización para un plan de acción sobre el que surge la improvisación consumiendolos a modo de bricolage (como McGyver).

El caso de estudio es sobre un proyecto web, pero mi pregunta es... ¿lo podemos aplicar al BI?.

¿Podemos añadir la improvisación a nuestros proyectos sin sentir un poco de vergüenza a la hora de decirlo?, Por que estoy seguro que muchos habeis improvisado sobre la marcha en algún proyecto según aparecían los problemas.

¿Y las metodologías ágiles? ¿Son mas proclives a incluir la improvisación?.

Ahí os dejo el guante.

De vuelta de vacaciones

Bueno, he vuelto de vacaciones (tranquilo Toad no paques el rescate que me he escapao) pero el aterrizaje ha sido de 0 a 100 en 2 segundos, en temas profesionales. Pero en este periodo de ausencia no he estado ocioso, he estado trabajando en varios temas.

1) Planificar mis post según lo que me habeis indicado en la encuesta de antes de verano. Muchas gracias a todos.

2) Una conferencia-formación de BeyeNetwork en Madrid de la que esta misma semana os daré la agenda definitiva y que me va a quitar mucho tiempo en los proximos dos meses, ya que soy el Director Académico de la misma.

3) Mi canal de BI Governance en BeyeNetwork, en el que ya llevo publicados tres artículos

• Guía de éxito para El Director proyectos de Business Intelligence.
• Business Intelligence Governance: El concepto
• Valores básicos de BI Governance

4) Mis articulos de la revista GdR, que podeis descargar entera desde estos link que os adjunto.




Ya estoy de vuelta :-D

Agile BI Governance (la conferencia)

Si, estaba de vacaciones de blog, pero me ha llegado por fin el DVD de la conferencia que hice dentro del ITSMF , en la UC3, y no he podido resistirlo.
Ademas es mi primer y seguramente mi ultimo post multimedia, pero creo que no ha quedado tan mal. Son 17 minutos, lo he subido a google video por que en youtube no me dejan mas de 10 minutos, espero que la calidad no sea del todo mala.



Y yo vuelvo a las vacaciones del blog.

Vacaciones de verano

Bueno como ya es habitual en mi le voy a dar vacaciones a este blog hasta mediados de septiembre. Necesito recargar pilas, pero volveré con mucha mas fuerza y hablando de los temas que me habeis dicho. Así que en septiembre me volveis a ver por aquí..... podeis tomaroslo como una amenaza. :-D

Otras voces en Business Intelligence y Metodologías ágiles

Al final en la encuesta ha habido un empate entre este tema y el de consejos de dirección de BI, pero por alguno hay que empezar.

Como todos sabeis desde hace tiempo estoy investigando esta relación desde el punto de vista de académico en mi tesis doctoral. Siempre he creido que existe una relación clara entre las necesidades del BI y el enfoque de esta metodología de gestión de proyectos. Hace tiempo la gente me miraba mal por decirlo, pero ultimamente estan saliendo otras voces que también abogan por este enfoque. Uno de ellos es Karthikeyan Sankaran, que tiene un blog que os recomiendo en la versión en ingles del B-Eye Network. Recientemente Karthikeyan ha presentado un excelente paper (agradezco que me lo haya remitido tras solicitarselo) titulado "Agile Framework for Business Intelligence". Y del que podeis ver aquí un resumen.

Me encanta que otras voces empiecen a hablar de esta relación, y felicitar a Karthikeyan por su aportación. Al menos ya no estoy solo. :-D

¡¡¡¡¡¡Estoy debajo de Inmon!!!!!!!!

Mientras espero el fin de las votaciones al post, os comunico que...
Me he convertido en el BI Governance Channel Expert para B·Eye Network Spain.

Para lo que no lo sepais Business Intelligence Network™ proporciona contenidos relacionados con el área de Business Intelligence proveído por expertos y líderes del sector, abarca todas las áreas de BI con los líderes más acreditados de los sectores de Business Intelligence, Business Performance Management, Data Warehousing y Calidad de Datos y proporciona una cobertura única del sector y recursos a esas comunidades, vamos que son muy buenos.

Para que os hagais una idea, comparto cartel con Bill Inmon el padre del Datawarehouse, estoy justo debajo, lo veo y no me lo creo,

¡¡¡¡¡¡Inmon y yo en una misma lista!!!!!!.

Y como veis, estoy debajo de él :-D

Me acompañan en la lista mi gran amigo Josep Curto y Remi Grossat.

Podeis leer el primero de mis artículos allí.

Guía de éxito para El Director proyectos de Business Intelligence.
by Jorge Fernández González
Muchos proyectos de Business Intelligence han fracasado en conseguir sus objetivos iniciales. Son tres los pilares sobre los que se sustenta el éxito o el fracaso de los sistemas de BI: Usuario, Organización y Metodología.

Pues eso, que me hace ilusión estar debajo de Inmon.