El primero es el artículo que os comenté que salia en el número 5
de la revista GdR, que ya esta disponible online para su descarga gratuita.Se trata de la primera versión divulgativa del concepto de Agile Business Intelligence Governance, son 7 páginas, así que mejor os lo leeis bajando su version en pdf.
Pero empieza así:
Cuando era adolescente, la gente me solía preguntar respecto a mis estudios si yo era de “ciencias” o de “letras”. Creo que actualmente pongo la misma cara de estupor cuando me preguntan si soy consultor de IT o de negocio. Tampoco veo la diferencia.
En el presente artículo realizaré una exploración de un nuevo concepto al que he bautizado como Agile Business Intelligence Governance, y con el que trataré de mostrar cómo podemos gobernar nuestros sistemas de ayuda a la toma de decisiones, rompiendo el gap IT/Negocio definitivamente a través del foco en el usuario de negocio y las Metodologías Ágiles.
2 comentarios:
Hola Jorge,
Me parece un artículo muy interesante, creo que en él se esconden algunas verdades muy incomodas para muchos departamentos de IT que abordan los proyectos de BI como proyectos estancos con un inicio y una finalización.
Otro de los aspectos que comentas, me ha llamado mucho la atención, ya que llevo mucho tiempo discutiendo con directores de IT sobre la importancia de la gestión de la información y las capacidades de acceso, disponibilidad y flexibilidad de la información que debemos disponer en un sistema decisional o BI.
Como bien comentas la tecnología y las aplicaciones son cambiantes, por lo tanto, partiendo de esta premisa no podemos diseñar nuestros sistemas decisionales pensando en nuestras aplicaciones, no podemos pensar en que a día de hoy utilizamos una base de datos de un fabricante x, un sistema de reporting de otro fabricante y un transaccional u operacional concreto, sino que tenemos que diseñar nuestros sistemas de BI pensando en todas las piezas (sistemas origen, sistemas de carga y sistemas de reporting) como elementos que pueden cambiar y que seguro que cambiaran durante la vida de nuestro BI y por lo tanto tenemos que adelantarnos a ese cambio, definiendo y estructurando cada una de las piezas de tal forma que el cambio en una de ellas no afecte al conjunto.
A día de hoy sigo viendo proyectos donde, por ejemplo, los procesos de carga (ETL) se definen como procesos programados (PL/SQL) que acceden a una BBDD concreta y cargan una tabla concreta, ¿Qué pasa cuando cambiamos uno de los campos de la tabla, o añadimos un nuevo campo?, ¿Qué pasa cuando consolidamos instancias o cambiamos la BBDD?, ¿somos capaces de realizar un análisis de impacto sobre un cambio en un componente de nuestro BI?, ¿y si cambiamos nuestro sistema de reporting?.
Todas estas preguntas son las que creo que se quedan en el tintero en muchas ocasiones por esa falta de una visión cambiante y flexible de los proyectos de BI, son muchos los que siguen viendo estos proyectos como un proyecto más de tecnología con unos requisitos y unos tiempos de diseño, implantación y puesta en producción.
Por último comentarte que para acabar de rematar esta visión son muchos los que aún defienden esa máxima que ha hecho tanto daño en los departamentos de IT, “si funciona, mejor no tocarlo”.
Un saludo.
David Soto
http://integracionycalidad.blogspot.com/
Gracias, David, estoy de acuerdo contigo, la idea de finalizar un proyecto de BI es un oxímoron.
La importancia del usuario en los sistemas de BI se está menospreciando en muchas ocasiones, y mientras mas grande es la empresa, mas grandes suelen ser sus "pecados" a pesar de que su dependencia de estos sistemas es mayor.
Muy de acuerdo con tu visión.
Un saludo
Publicar un comentario