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.

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