Published 17 years ago
(updated 14 years ago)
Profundizando en la Perspectiva de Análisis
Muchos proyectos de BI que se terminan correctamente desde el punto de vista tecnológico no cumplen sus expectativas de retorno de inversión. Creemos que uno de los factores que lo impiden es que no se tomaron en cuenta los impactos en la cultura y en la organización que supone el disponer de una nueva plataforma para organizar, hacer disponible y analizar la información.Hace no mucho tiempo participamos en la implementación de un proyecto de BI para una empresa del sector financiero. Desde el punto de vista de ejecución del proyecto, los resultados fueron satisfactorios en tiempo, costo y funcionalidad, sin embargo, tras seis meses de operación, tuvimos que hacer una revisión del proyecto, dado que existía un bajo nivel de satisfacción en el principal patrocinador del proyecto en cuanto al cumplimiento de sus expectativas de resultados.
En un principio no se encontró ningún problema significativo ni en la operación, ni en el hardware, ni en las herramientas: la información estaba al día y “cuadraba”, el performance era adecuado, los usuarios conocían las herramientas: ¿Cómo es que tenemos un solución que “funciona” desde los puntos de vista técnico y operativo, pero que desde la perspectiva del usuario principal no cumple con sus expectativas?
Analizamos con detalle el caso de un reporte trimestral de ventas que se consideraba crítico, ya que era usado por la alta dirección, y que es un caso representativo de lo que . Esto es lo que encontramos:
Al estudiar las causas que provocaron que se lograra un proyecto técnicamente adecuado, pero que presenta dificultades para cumplir con las expectativas de uso son:
Un enfoque tecnológico del proyecto. El líder del proyecto tenía una formación y experiencia dentro de las tecnologías de información, el presupuesto provenía del área de sistemas, prácticamente todos los miembros del equipo tenían la misma orientación técnica que el líder, el proveedor de la tecnología aportó metodología y expertise de desarrollo.
95% del esfuerzo y de los recursos se dedicaron a la tecnología: selección y puesta a punto del hardware, a la selección del proveedor de la tecnología, a los procesos de ETL.
La capacitación se enfocó exclusivamente al uso de las herramientas de explotación.
El involucramiento de usuarios se enfocó en resolver las necesidades y los problemas de desarrollo del proyecto, por lo que los temas asociados al uso no fueron evidentes en las fases de desarrollo.
El enfoque metodológico se basó en determinar y resolver las necesidades de información, y se estudió muy poco el contexto de toma de decisiones.
Expectativas de resultados asociadas a la calidad y disponibilidad de los datos. Los usuarios y los miembros del equipo del proyecto pusieron muy poco énfasis en el uso de los datos, ya que el problema que se definió era la disponibilidad y oportunidad de los mismos. Se supuso que no habría problema en el “uso” de los mismos.
No se tomaron en cuenta los cambios organizacionales que necesariamente provocaría la implementación del proyecto. El más importante de todos ellos consiste en que se trataba de una organización altamente “jerárquica”, y la disponibilidad generalizada de la información, suponía cambios en la estructura de poder que implicaba una redefinición de roles y responsabilidades.
En muchos casos, las personas tenían la información, y por lo tanto la capacidad para tomar una decisión, pero al final tenían que ir “a tocar base con su jefe”, perdiéndose en el camino la posibilidad de aprovechar la capacidad plena de las herramientas.
Se dió prioridad a resolver las necesidades de los analistas. El esfuerzo de análisis y de definición de requerimientos se realizó fundamentalmente desde la perspectiva de analistas y procesadores de información; la visión del alto directivo quedó únicamente reflejada en un conjunto de reportes, que si bien basados en las necesidades declaradas por los directores, no tomó en cuenta sus “usos y costumbres” del proceso real para tomar decisiones.
Para elevar el nivel de uso, y por lo tanto de éxito del proyecto, recomendamos lo siguiente:
Ampliar la perspectiva de análisis al considerar el contexto de toma de decisiones. El alcance del proyecto debe considerar aspectos de cambio organizacional, de forma que se puedan hacer ajustes en roles, responsabilidades y procesos de toma de decisiones.
• Definir los cambios en las estructuras formales e informales de toma de decisiones que permitirán aprovechar las ventajas del proyecto. Algunas de estas ventajas tienen carácter estratégico.
• Definir quiénes pueden tomar decisiones y diseñar esquemas de incentivos que alienten la toma de decisiones.
• Demostrar que tomar decisiones basadas en hechos, reduce la incertidumbre en base a experiencias exitosas.
Alinear expectativas de los usuarios finales en cuanto al uso de las herramientas. No es posible tener un Ferrari y manejarlo como si tuviéramos un “vochito”, debemos hacer ajustes en los hábitos de conducción si se desea maximizar la experiencia de conducir un Ferrari.
• Mejorar las competencias estadísticas y matemáticas.
• Mejorar la capacidad de hacer preguntas y plantear hipótesis.
• Mejorar la capacidad para “explorar” en los datos.
Entrenar a alta dirección en los procesos de toma de decisiones utilizando las herramientas. Tradicionalmente los resultados se muestran en “powerpoints”, pero ahora se puede presentar y analizar mediante la herramienta OLAP.
• Capacitar en el proceso de sesiones de análisis en tiempo real.
• Capacitar en el uso de las funciones y capacidades de análisis visual que muchas herramientas ofrecen (colores, tamaños, formas, tipos de gráficas).
• Capacitar en procesos formales de análisis y toma de decisiones.
Buscar pequeños éxitos y difundirlos ampliamente. Tenemos que demostrar cómo las nuevas herramientas agregan valor a la empresa, y que la “forma tradicional” es mucho menos efectiva que la “nueva forma” de tomar decisiones; que no es más compleja sino más simple, que no lleva más tiempo sino menos. Muchas personas que tengan una postura de escepticismo frente a la solución, pueden cambiarla al ver a otros tener éxito. Tratamos de publicar casos que tengan alguna característica de estas:
• Se redujo el tiempo para tomar la decisión porque fue más simple.
• Se incrementa la satisfacción del cliente debido a que el método de tomar decisiones es más efectivo (tomó menos tiempo, el diagnóstico fue más preciso).
• Se optimiza un proceso debido a que se pudo analizar desde diversos puntos de vista.
Referencias
[ Adelman, Sid. 2003. Impossible Data
Warehouse Situations. Addison-Wesley. ]
[ Biere, Mike. 2003. Business Intelligence
for the enterprise. IBM Press. ]
[ Davenport, Thomas, Jeanne Harris,
David DeLong y Alvin Jacobson. 2001.
Data to knowledge to results. California
Management Review. ]
Acerca del Autor
Francisco Vaca Gómez es socio director de TEDE de 2006 a la fecha. Ha realizado diseño e implementación de proyectos de educación basados en competencias, instrucción de programas educativos, investigación y promoción de la educación basada en competencias
Muchos proyectos de BI que se terminan correctamente desde el punto de vista tecnológico no cumplen sus expectativas de retorno de inversión. Creemos que uno de los factores que lo impiden es que no se tomaron en cuenta los impactos en la cultura y en la organización que supone el disponer de una nueva plataforma para organizar, hacer disponible y analizar la información.Hace no mucho tiempo participamos en la implementación de un proyecto de BI para una empresa del sector financiero. Desde el punto de vista de ejecución del proyecto, los resultados fueron satisfactorios en tiempo, costo y funcionalidad, sin embargo, tras seis meses de operación, tuvimos que hacer una revisión del proyecto, dado que existía un bajo nivel de satisfacción en el principal patrocinador del proyecto en cuanto al cumplimiento de sus expectativas de resultados.
En un principio no se encontró ningún problema significativo ni en la operación, ni en el hardware, ni en las herramientas: la información estaba al día y “cuadraba”, el performance era adecuado, los usuarios conocían las herramientas: ¿Cómo es que tenemos un solución que “funciona” desde los puntos de vista técnico y operativo, pero que desde la perspectiva del usuario principal no cumple con sus expectativas?
Analizamos con detalle el caso de un reporte trimestral de ventas que se consideraba crítico, ya que era usado por la alta dirección, y que es un caso representativo de lo que . Esto es lo que encontramos:
Al estudiar las causas que provocaron que se lograra un proyecto técnicamente adecuado, pero que presenta dificultades para cumplir con las expectativas de uso son:
Un enfoque tecnológico del proyecto. El líder del proyecto tenía una formación y experiencia dentro de las tecnologías de información, el presupuesto provenía del área de sistemas, prácticamente todos los miembros del equipo tenían la misma orientación técnica que el líder, el proveedor de la tecnología aportó metodología y expertise de desarrollo.
95% del esfuerzo y de los recursos se dedicaron a la tecnología: selección y puesta a punto del hardware, a la selección del proveedor de la tecnología, a los procesos de ETL.
La capacitación se enfocó exclusivamente al uso de las herramientas de explotación.
El involucramiento de usuarios se enfocó en resolver las necesidades y los problemas de desarrollo del proyecto, por lo que los temas asociados al uso no fueron evidentes en las fases de desarrollo.
El enfoque metodológico se basó en determinar y resolver las necesidades de información, y se estudió muy poco el contexto de toma de decisiones.
Expectativas de resultados asociadas a la calidad y disponibilidad de los datos. Los usuarios y los miembros del equipo del proyecto pusieron muy poco énfasis en el uso de los datos, ya que el problema que se definió era la disponibilidad y oportunidad de los mismos. Se supuso que no habría problema en el “uso” de los mismos.
No se tomaron en cuenta los cambios organizacionales que necesariamente provocaría la implementación del proyecto. El más importante de todos ellos consiste en que se trataba de una organización altamente “jerárquica”, y la disponibilidad generalizada de la información, suponía cambios en la estructura de poder que implicaba una redefinición de roles y responsabilidades.
En muchos casos, las personas tenían la información, y por lo tanto la capacidad para tomar una decisión, pero al final tenían que ir “a tocar base con su jefe”, perdiéndose en el camino la posibilidad de aprovechar la capacidad plena de las herramientas.
Se dió prioridad a resolver las necesidades de los analistas. El esfuerzo de análisis y de definición de requerimientos se realizó fundamentalmente desde la perspectiva de analistas y procesadores de información; la visión del alto directivo quedó únicamente reflejada en un conjunto de reportes, que si bien basados en las necesidades declaradas por los directores, no tomó en cuenta sus “usos y costumbres” del proceso real para tomar decisiones.
Para elevar el nivel de uso, y por lo tanto de éxito del proyecto, recomendamos lo siguiente:
Ampliar la perspectiva de análisis al considerar el contexto de toma de decisiones. El alcance del proyecto debe considerar aspectos de cambio organizacional, de forma que se puedan hacer ajustes en roles, responsabilidades y procesos de toma de decisiones.
• Definir los cambios en las estructuras formales e informales de toma de decisiones que permitirán aprovechar las ventajas del proyecto. Algunas de estas ventajas tienen carácter estratégico.
• Definir quiénes pueden tomar decisiones y diseñar esquemas de incentivos que alienten la toma de decisiones.
• Demostrar que tomar decisiones basadas en hechos, reduce la incertidumbre en base a experiencias exitosas.
Alinear expectativas de los usuarios finales en cuanto al uso de las herramientas. No es posible tener un Ferrari y manejarlo como si tuviéramos un “vochito”, debemos hacer ajustes en los hábitos de conducción si se desea maximizar la experiencia de conducir un Ferrari.
• Mejorar las competencias estadísticas y matemáticas.
• Mejorar la capacidad de hacer preguntas y plantear hipótesis.
• Mejorar la capacidad para “explorar” en los datos.
Entrenar a alta dirección en los procesos de toma de decisiones utilizando las herramientas. Tradicionalmente los resultados se muestran en “powerpoints”, pero ahora se puede presentar y analizar mediante la herramienta OLAP.
• Capacitar en el proceso de sesiones de análisis en tiempo real.
• Capacitar en el uso de las funciones y capacidades de análisis visual que muchas herramientas ofrecen (colores, tamaños, formas, tipos de gráficas).
• Capacitar en procesos formales de análisis y toma de decisiones.
Buscar pequeños éxitos y difundirlos ampliamente. Tenemos que demostrar cómo las nuevas herramientas agregan valor a la empresa, y que la “forma tradicional” es mucho menos efectiva que la “nueva forma” de tomar decisiones; que no es más compleja sino más simple, que no lleva más tiempo sino menos. Muchas personas que tengan una postura de escepticismo frente a la solución, pueden cambiarla al ver a otros tener éxito. Tratamos de publicar casos que tengan alguna característica de estas:
• Se redujo el tiempo para tomar la decisión porque fue más simple.
• Se incrementa la satisfacción del cliente debido a que el método de tomar decisiones es más efectivo (tomó menos tiempo, el diagnóstico fue más preciso).
• Se optimiza un proceso debido a que se pudo analizar desde diversos puntos de vista.
Referencias
[ Adelman, Sid. 2003. Impossible Data
Warehouse Situations. Addison-Wesley. ]
[ Biere, Mike. 2003. Business Intelligence
for the enterprise. IBM Press. ]
[ Davenport, Thomas, Jeanne Harris,
David DeLong y Alvin Jacobson. 2001.
Data to knowledge to results. California
Management Review. ]
Acerca del Autor
Francisco Vaca Gómez es socio director de TEDE de 2006 a la fecha. Ha realizado diseño e implementación de proyectos de educación basados en competencias, instrucción de programas educativos, investigación y promoción de la educación basada en competencias
- Log in to post comments