Cerrando una etapa

Pues 2010 no nos ha traido mas que carbón a todos los españoles.
Esperemos que 2011 vaya un pelín mejor.

¿Que he estado haciendo yo durante este año?.

Pues a pesar de mi silencio de radio, he estado haciendo muchas cosas.

1) Ser padre (todo lo que puedo), de un bonito Calvin y una preciosa Hello Kitty, la imagen ilustra bastante bien una situación diaria con los niños.(a mi mujer la van a hacer santa en breve)



2) Trabajar (todo lo que me dejan). En Abast Solutions y en la UPC como ya sabeis.

3) Intentar doctorarme. En 2011 voy a publicar mi primer "chapter", en un libro de investigación. El titulo del chapter es "Agile approach to Business Intelligence: A way to success", 29 páginas a todo color y en ingles, que espero se conviertan en un referente en la investigación del Agile BI, porque como no sea así, me voy a cagxxxx en la pxxxxx de las horas que le he dedicado a la creación, y a las revisiones del mismo. El libro en el que saldrá publicado es " Business Intelligence and Agile Methodologies for Knowledge-Based Organizations : Cross-Disciplinary Applications. "

4) Ser editor . Pues si soy el editor invitado del número especial de Novatica dedicado al Busines Intelligence que saldrá en julio de 2011.

5) Director académico. Del postgrado de "Business Intelligence con SAP Business Objects Enterprise", de la Talent UPC. En el cual he invertido tiempo remodelandolo y en conseguir profesorado de gran nivel (publireportaje descarado)

Como veis parado no he estado, y el tema del blog, poco a poco lo he ido dejando de lado, al principio por falta de tiempo y al final por vagancia, de la buena.

Así que, aprovecho este bonito dia 31 de diciembre de 2010 para cerrar mi blog.
Muchas gracias a todos los que me habeis acompañado durante este periplo, y a aquellos que aún seguis visitando mis entradas antiguas. Intentaré responder a todos aquellos que tengais dudas, pero el ciclo se cierra hoy.

Gracias y hasta otra.
Jorge

Feliz Navidad y a ver que nos depara 2010

4º evento BI Beers

Esta vez iniciado por la gente de BI Facil. (ver detalles pulsando el link)
Lamentablemente yo no podré asistir aunque creo que ya ha confirmado su asistencia Kevin Bacon.

El papel del usuario de negocio en el BI Governance (2ª parte) .

Continuando con el papel del usuario de negocio dentro de la gestion y gobierno del Business Intelligence, otro de los puntos en los que su papel es muy, muy importante son:

3) Calidad y acceptación del dato.

Los usuarios deben definir las políticas y criterios ha establecer en lo referente a calidad del dato, así como desarrollar test de aceptación que permitan asegurar que los datos que agregamos y transformamos en información son coherentes y aceptados por laorganización. El peligro de poner en duda los datos se elimina si son los propios usuarios los encargados de definir los test de calidad y aceptación de los datos. Utilizando el símil del pastel, estamos cocinando un pastel con datos, nosotros somos los cocineros, pero es el dueño del local quiencomprará los huevos y la harina, y es él quien probará la primera versión que hagamos del pastel antes de ofrecérsela a los clientes. Si los huevosestan podridos y/o nos hemos pasado con él azúcar, afectará al negocio.

4) Usabilidad y aplicabilidad de la información.

Cada información es extraída para usarla en la toma de decisiones de uno o varios procesos, la forma de aplicarla en el día a día, es crucial para hacer que las herramientas de BI fructifiquen en nuestras organizaciones y maduren hacia organizaciones orientadas al valor.
Saber como aplicar las informaciones de los reports al día a día y conocer las necesidades surgidas en el transcurso de la jornada son cruciales para orientar los sistemas de BI hacia su máximo nivel de aprovechamiento, y eso solo lo saben hacer los usuarios de negocio.

5) Escenarios de recuperación.

¿Que pasa si el sistema cae?. ¿Qué pasa si la plataforma de BI o el Data Warehouse dejan de funcionar?. El diseño de escenarios de recuperación, de como manejar los procesos que tenemos controlados con el BI sin utilizar el BI, de como sacar datos de control de los sistemas operacionales son ejercicios altamente recomendables. Por una parte ayudan a comprender mejor el control de los procesos, por otra tenemos unmapeo directo entre fuentes de datos operacionales e información reportada, y por último nos permite hacer conscientes a los usuarios de la importancia de introducir los datos de forma correcta en los sistemas operacionales.

6) Selección de herramientas de BI.

La llamada "experiencia de usuario" es fundamental si queremos que seleccionar herramientas de BI.


Seguro que se os ocurren muchas mas pero.... a mi ya no, asi que espero sugerencias :-D.

P.S: Tras las críticas de Marc sobre la última imagen espero que esta sea mas de tu agrado, así tambien hago un homenaje a los 40 años de los Teleñecos.

El papel del usuario de negocio en el BI Governance (1ª parte) .

En muchos de mis anteriores post he comentando la importancia de que el proyecto de BI Governance, su ejecución y su mantenimiento sean propiedad conjunta de los usuarios de negocio y de IT. Pero ¿qué es lo que deben hacer?. ¿Cuál es su papel en los diferentes órganos de gobierno del BI?. ¿Qué grado de implicación necesitamos para garantizar el éxito?.
De todas estas interesantísimas preguntas hoy solo responderé una, bueno de hecho solo media ya que este post lo he partido en dos partes porque sino es muy largo. y así me va bien para generar suspense, a ver si así comentáis algo.

Funciones a desarrollar por los usuarios en el BI Governance.

1) Modelo de datos: El papel de los usuarios en esta fase del diseño de los sistemas BI y en su posterior implantación, es fundamental, explicar las preguntas del negocio a los Arquitectos de Datawarehouse y revisar conjuntamente si el modelo ayuda a responderlas es una de las misiones clave de los usuarios de negocio. No solamente se trata de decir cosas a ver si los consultores por un casual entendemos lo mismo, sino que se trata de enunciar las preguntas clave de los procesos de negocio y definir su aplicabilidad al día a día del control de los procesos. El usuario no debe ser simplemente un "emisor de requisitos funcionales", sino un transmisor de la usabilidad del modelo en el trabajo diario del resto de compañeros de área. Es el propietario del modelo de datos que ha encargado a un sastre, pero de él es la responsabilidad de detectar si el modelo sigue adapatándose en el transcurso del tiempo o si por el contrario hay que hacer reajustes que se adapten a las necesidades cambiante


2) Definición de estándares: El conocimiento colectivo del control de un área funcional de cualquier organización se basa en los indicadores sobre los que reporta su actividad, los informes que maneja y los análisis que realiza cuando algún indicador va mal. Alguna otra vez he hablado sobre la importancia de tener registrados los análisis particulares de cada persona, la forma en la que accede a la información y los caminos analíticos que crea en la ejecución de su labor. Documentar y estandarizar cada una de estas partes nos permitirá hacer crecer el nivel de madurez de los sistemas decisionales de nuestra organización.
Así la segunda de las funciones a desarrollar por el usuario de negocio es definir estandarizaciones en el acceso a la información y en las formas de analizar, creando estándares para:

• Categorizaciones de conceptos.
• Definiciones de indicadores, métricas, índices, etc...
• Estructuras de carpetas.
• Caminos analíticos.
• Reporting corporativo por área de negocio.
• Nomenclatura.

En definitiva, estandarizar el uso y distribución de la información .

En el siguiente post hablaré de la importancia del usuario de negocio en la integración y la calidad del dato.

Y para aquellos que estes atentos como podeis ver un papel tan relevante del usuario nos acerca cada vez mas al Agile BI Governance.

Post 100: Intentan patentar los modelos organizacionales de BI

Pues voy a gastar mi post nº 100 en enfadarme por la jeta que tienen algunos, en concreto estos cuatro individuos de Bangalore .

• Sunil Senan.
• Nitin G. Metri.
• Varun Babbar
• Gaonkar K.P

Estos 4 han "inventado" un BI Framework que engloba todos los ámbitos del Business Intelligence, han hecho unos bonitos dibujitos (como el que os muestro) y han solicitado una patente US que podéis ver aquí.





Imaginaos que tienen éxito, entonces cualquier organización de BI tendrá que pagar a estos jetas unos dineritos por nada. Me los veo demandando a diestro y siniestro. Imaginaos que ponéis un servicio de calidad del dato, pues es parte de su patente así que a pagar, o si tenéis un servicio de ETL pues lo mismo a pasar por caja. Y ni se os ocurra alinearos con el negocio que infringiréis el modulo 614 de su patente.

Si se empiezan a patentar MODELOS ORGANIZATIVOS entonces que nos cojan a todos confesados.

Voy a ver si patento la cadena de montaje que me forro.

IT y Negocio: Seamos amiguitos

Interesantísimo articulo de Maria C. Villar, Theresa C. Kushner, titulado "4 Steps to Create an Effective IT and Business Partnership" que podéis consultar aquí.

Me ha encantado el hecho de olvidarse del término alineación de IT con el Negocio, nada de alinearse, lo mejor es ser amigos de los usuarios de negocio, comprenderles, y formar un equipo. Muchas veces os he hablado del BI governance como vehículo catalizador que reducirá el gap IT/Business con lo que el planteamiento de Maria y Theresa me ha encantado.

Parten de la siguiente premisa: La identificación y definición de los datos críticos de negocio requiere de una fuerte alianza entre el negocio y las IT. Ambas organizaciones deben ponerse de acuerdo sobre cómo los datos se crean, se actualizan, se controlan, se informan, se eliminan y se archivan. Hay por tanto que establecer una relación de éxito entre ambas partes.










Son 4 los pasos que hay que seguir para conseguirlo.

• Paso 1. Conocerse mutuamente.
• Paso 2. Desarrollar una relación.
• Paso 3. Definir roles y responsabilidades
• Paso 4. Establecer comunicación regularmente y de forma abierta, sincera.

El artículo se basa sobretodo en la gestión y la calidad del dato, pero es perfectamente extrapolable a la gestión de indicadores analíticos.

Uno de los puntos en los que estoy mas de acuerdo es a la hora de establecer comunicación de forma abierta con los usuarios de negocio:

• Soñando el mismo sueño, todos tenemos que tener los mismo objetivos, remar en la misma dirección
• Eliminando las capas de interferencia, muchas veces se ponen "personas intermedias" que trasladan las necesidades de negocio a los de IT. Esto hay que eliminarlo, se necesita un contacto directo para que ambos mundos se pongan a trabajar como partners, se necesita incentivar el contacto entre ellos, se necesita hacer sesiones de "un día en la vida del comercial" o "un día en la vida del analista de Business Intelligence" para que nosotros veamos lo difícil que es vender y que ellos vean lo difícil que es transformar datos en información y en indicadores.
• Confiando en que cada uno hará bien su tarea "confía en que el cocinero cocine", que nadie este constantemente metiendo las narices en el trabajo del otro.

La verdad es que me ha gustado mucho el enfoque que le han dado a la alineación y creo que esta muy en linea con las metodologías ágiles y la vuelta a la confianza en las personas para llevar al éxito a las organizaciones.

Dirección de proyectos BI: El sentido común

Empezaré mi regreso a la actividad citando a un señor bajito.

" Para triunfar es necesario, más que nada, tener sentido común. "

Napoleón I (1769-1821) Napoleón Bonaparte. Emperador francés.

Esta cita es muy aplicable a la dirección de proyectos de BI, un buen director acumula sus experiencias profesionales como un punto de referencia importante para no equivocarse. La experiencia y el sentido común nos pueden llevar al éxito. Pedersen en su artículo "How is BI Used in Industry?" nos habla de las lecciones aprendidas , el sentido común de los profesionales del Business Intelligence.

• Primera Lección: " Los reports estándar son suficientes para la gran mayoría de los usuarios que necesitan información, solo los mas avanzados se embarcarán en análisis de tipo OLAP".
• Segunda Lección: Todas las plataformas de BI actuales pueden hacer el 90% de la funcionalidad requerida por los usuarios de cualquier organización. Siempre hay una parte que quizás necesite de herramientas específicas.
• Tercera Lección: Al migrar a una nueva plataforma de BI se deben migrar nunca los viejos reports 1-1, la nueva plataforma puede tener nuevas funcionalidades de gestión, acceso y clasificación de la información que se estén menospreciando.
• Cuarta Lección: Muy pocas sistemas BI utilizan Datamining, con excepción de la previsión de la demanda realizada en un par de semanas al año.
• Quinta Lección: BI se conecta siempre con información de los sistemas heredados (legancy) deberíamos tenerlo en cuenta a la hora de elegir nuestra arquitectura de BI y nuestra herramienta ETL.
• Sexta Lección: La información en tiempo real es crucial, el uso de Business Activity Monitoring esta presente en casi todas las implantaciones.
• Séptima Lección: Los procesos ETL consumen casi todo el tiempo de la implantación, se estima que de media se emplean en ellos el 80% del esfuerzo.
• Octava Lección: Lo organizacional y lo "social" importa. Por ejemplo, es importante tener definido como formaremos a un nuevo usuario en el uso del sistema BI.

Si bien al leer estas 8 lecciones podéis pensar que son muy obvias, reflexionad cuantas veces las ponéis en practica, solo aplicando las tres primeras veréis como los proyectos de BI pueden reducir su coste y complejidad de forma espectacular.
A mi la que mas beneficios me ha dado en mi carrera profesional es aplicar la lección octava, la gran olvidada por la mayoría de grandes consultoras centradas solo en funcionalidad y coste.

2º Intermedio por paternidad y tres añitos de blog

El pasado lunes el blog hizo tres añitos, pero se me pasó por alto porque estaba muy liado de nuevo con pañales, ya que mañana hace un mes que soy papi por segunda vez.

Esta vez se trata de una bonita niña, que se parece a su madre (gracias a Dios), así que ya tenemos la parejita y una habitacion llena de Hellos Kittys.

Ahora estoy intentando gestionar el proyecto familia con agilidad y poniendo prioridades a las tareas pero no se como se lo hacen pero los hermanos se sincronizan para que siempre haya uno despierto. De momento ganan los niños por goleada. :-D

Asi que mi rol slowgger seguirá durante un tiempo.

3er evento oficioso BI Beers esta vez en Chile

Si amigos, hemos traspasado el Atlantico y nos vamos a Santiago de Chile a tomar cervezas.

El autor de la iniciatica es Diego Arenas del blog Analisis BI, gran conocedor de los temas de BI y que se lanza con esta iniciativa loca.

Os copi0 el post porque soy un Slowgger.

Estimados seguidores del BI,

Habrá el primer BI Beers en Santiago en Chile para pasar un rato conversando de Inteligencia de Negocios y compartir un momento agradable acompañado de unas buenas cervezas, ¿te animas?.

Siguiendo la tradición del Grupo BI BEERS de LinkedIn y tal como el primer y segundo evento realizados en España anteriormente, queremos continuar la tradición en Chile.




¿Quieres conversar sobre BI, BA, DWH, SaaS, ETL, BSC, OS, OSBI, Agile BI, Project Management BI, casos de éxito, mejores prácticas, Vendedores, Soluciones y Suites BI, etc. y temas relacionados además de disfrutar unas buenas cervezas?

Jueves 14 de Mayo de 2009 a partir de las 18:30 horas, visita el grupo de BI BEERS en LinkedIn o escribe un mail a darenasc (at) gmail (dot) com para conocer el lugar del evento.

Propuestas y comentarios son bienvenidos,

Interesados en temas de BI son bienvenidos.

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.