Sistemas Decisionales, algo mas que Business Intelligence

Cerrando una etapa

noreply@blogger.com (Jorge Fernández González) — Fri, 31 Dec 2010 22:59:00 +0000

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

noreply@blogger.com (Jorge Fernández González) — Wed, 23 Dec 2009 23:57:00 +0000

4º evento BI Beers

noreply@blogger.com (Jorge Fernández González) — Mon, 23 Nov 2009 19:01:00 +0000

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) .

noreply@blogger.com (Jorge Fernández González) — Mon, 16 Nov 2009 18:00:00 +0000

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) .

noreply@blogger.com (Jorge Fernández González) — Wed, 28 Oct 2009 00:19:00 +0000

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

noreply@blogger.com (Jorge Fernández González) — Wed, 30 Sep 2009 16:23:00 +0000

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

noreply@blogger.com (Jorge Fernández González) — Tue, 29 Sep 2009 16:28:00 +0000

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

noreply@blogger.com (Jorge Fernández González) — Thu, 24 Sep 2009 08:14:00 +0000

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

noreply@blogger.com (Jorge Fernández González) — Wed, 10 Jun 2009 08:37:00 +0000

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

noreply@blogger.com (Jorge Fernández González) — Thu, 07 May 2009 12:31:00 +0000

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

noreply@blogger.com (Jorge Fernández González) — Wed, 15 Apr 2009 19:07:00 +0000

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

noreply@blogger.com (Jorge Fernández González) — Wed, 15 Apr 2009 18:00:00 +0000

¿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

noreply@blogger.com (Jorge Fernández González) — Tue, 10 Mar 2009 17:20:00 +0000

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

noreply@blogger.com (Jorge Fernández González) — Tue, 24 Feb 2009 20:00:00 +0000

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

noreply@blogger.com (Jorge Fernández González) — Sun, 15 Feb 2009 19:53:00 +0000

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

noreply@blogger.com (Jorge Fernández González) — Tue, 03 Feb 2009 17:27:00 +0000

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

noreply@blogger.com (Jorge Fernández González) — Wed, 17 Dec 2008 20:14:00 +0000

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

noreply@blogger.com (Jorge Fernández González) — Sun, 07 Dec 2008 20:40:00 +0000

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

noreply@blogger.com (Jorge Fernández González) — Wed, 26 Nov 2008 23:26:00 +0000

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

noreply@blogger.com (Jorge Fernández González) — Wed, 29 Oct 2008 21:38:00 +0000

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

noreply@blogger.com (Jorge Fernández González) — Sun, 26 Oct 2008 21:52:00 +0000

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

noreply@blogger.com (Jorge Fernández González) — Wed, 22 Oct 2008 20:55:00 +0000

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

noreply@blogger.com (Jorge Fernández González) — Tue, 21 Oct 2008 21:41:00 +0000

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

noreply@blogger.com (Jorge Fernández González) — Thu, 09 Oct 2008 20:20:00 +0000

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?

noreply@blogger.com (Jorge Fernández González) — Sun, 05 Oct 2008 22:00:00 +0000

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.