English
El otro día vi un post en Linkedn que con cierta ironía decía que todo lo que veía en esta plataforma era wonderful. Y efectivamente, esa es la impresión que uno se lleva al cabo unos minutos de leer el time-line (y lo mismo si por ejemplo se va a cualquier presentación comercial sobre productos de TI)
Sin embargo, todos sabemos que el mundo no es tan bonito y que los proyectos no siempre salen como nos gustaría. Llevo ya algunos años en el mundo del Business Intelligence, y ese post me hizo pensar en aquellos proyectos que se torcieron pese a las maravillosas herramientas con las que contamos los consultores (si, eso último también es ironía).
Este post va de "lecciones aprendidas" con el que espero que os sirva para evitar errores en proyectos de Business Intelligence (algunos de ellos son específicos de SAP pero la mayoría valdrían para cualquier tecnología BI).
Éste punto sin duda es uno de los principales enemigos del BI. La desconfianza suele venir por alguno de estos dos motivos:
Si ocurre el primer punto, lo más probable es que el usuario abandone el BI y se quede con los listados más o menos octogenarios que le da el sistema fuente. Y si ocurre el segundo, pues bien, probablemente se pase el día hablando mal de IT y ensanchando el mito de que “todo es culpa de los informáticos”.
Cuadre respecto el sistema fuente
Obviamente hay que hacer un desarrollo que lo garantice, pero luego hay que hacer algún tipo de desarrollo para demostrar que es así. Pueden encontrarse sistemas más o menos automáticos de cruzar por ejemplo listados de totales en el sistema fuente con el BI (y ahora con S4/HANA se nos abren muchas posibilidades), el problema es que por lo general en el BI tendremos más dimensiones de análisis (por lo que probablemente habrá que cruzar con diferentes listados), y además suele conllevar un coste de mantenimiento que el cliente no siempre está dispuesto a asumir.
Trazabilidad del dato
Si nuestro proyecto tiene cálculos complejos o integra muchas fuentes, tengamos en cuenta al inicio del proyecto que tendremos que demostrar que el cálculo funciona bien.
Si una vez implantado no lo hemos tenido en cuenta, entonces suele ser necesaria una reingeniería que el cliente probablemente no quiera asumir.
Y eso se acentúa en entorno SAP y sus dichosos módulos. Hace unas pocas semanas por ejemplo, tuve en un cliente tres reuniones más o menos seguidas, una con usuarios financieros, otra con usuarios de compras, y otra con usuarios del módulo de Real Estate, y cada usuario, por supuesto, expertos en su materia. Y en cada reunión hablamos de cosas y problemáticas totalmente distintas.
El riesgo que corremos en estas situaciones es importante, ya que:
Para evitar este riesgo tenemos varias soluciones:
También suele resultar de gran ayuda identificar que transacciones o listados tenemos disponibles en el sistema fuente en los que podamos contrastar (aunque sea parcialmente), que nuestros desarrollos en BI tienen sentido y son correctos.
Por lo general, los proyectos de BI siguen una planificación tradicional: Definición del proyecto -> BBP -> diseño técnico –> extractores -> modelado -> reporting -> pruebas usuario
… y resulta que cuando empezamos con el reporting, tras dos meses del inicio del proyecto, nos damos cuenta que cierta funcionalidad pues… no funciona. Esto fácilmente puede ocurrir cuando tenemos un proyecto donde la arquitectura no es la habitual o tenemos algún requerimiento atípico.
En estos casos, hay que pensar en realizar un prototipado, prueba de concepto o recurrir a metodologías ágiles (aunque en BI no siempre es fácil hacerlas).
Tal y como comento en mi post sobre metodologías en proyectos de BI, los indicadores con el mismo conjunto de dimensiones deberían formar parte del mismo infoprovider, o lo que es lo mismo, intentar evitar que en un mismo infoprovider tengamos indicadores que tengan sentido solo para una parte de las dimensiones.
Recuerdo un proyecto, relativamente acotado, y con usuarios finales expertos. La dinámica del proyecto nos llevó a hacer una excepción a esta regla. Inicialmente no fue problema, los usuarios, que como digo eran expertos, y ayudaron a definir los requerimientos, entendían que en función de que indicadores y dimensiones pusieran en el informe, aparecieran valores nulos (el famoso “sin asignar”).
Ocurrió que al cabo de un par de años, el proyecto había crecido y los usuarios habían cambiado. El comportamiento de los informes no era entendido por los usuarios y acabaron abandonando el BI.
Ahora quizás voy a decir algo que sorprenda: en la etapa de pre-venta de un proyecto se suele hacer mucho énfasis en la arquitectura/herramientas de reporting que van a utilizarse.
Sinceramente, creo que siempre que se escojan herramientas que hayan demostrado que en el mercado son solventes, este punto es poco importante. Es decir, creo que el éxito de un proyecto no depende tanto de que herramientas se utilicen, como si del alcance y definición (y obviamente ejecución) del proyecto.
Dicho esto, hay una excepción: no podemos por ejemplo poner una herramienta de cuadro de mandos para hacer lo que en realidad un reporting operativo encubierto.
Recuerdo un proyecto donde era pre-requisto del cliente utilizar una herramienta determinada de cuadro de mando. El reporting consistía en un mapa geográfico inicial con valores de indicadores, pero posteriormente se requerían muchas pantallas de navegación drill-down para obtener el detalle. Ya en tiempo de preventa desaconsejamos dicha herramienta y ofrecimos una alternativa (a lo que el cliente se negó). Involucramos en el proyecto al propio fabricante y repercutimos al cliente el riesgo (en tiempo y en coste). Dimensionamos el proyecto de forma correcta, siempre teniendo en cuenta el riesgo que representaba la herramienta. Es decir, hicimos todo lo que a mi modo de ver podía hacerse, sin embargo el resultado quedó lejos de lograr satisfacer al cliente.
Un cliente nos solicitó ayuda en un proyecto de SAP BW que no funcionaba. El problema principal (que no el único) era que había que calcular muchos indicadores y se producían continuos errores.
La mayoría de indicadores llegaban a tener hasta dos páginas de explicación de cómo debía ser el cálculo (muy complejo en la mayoría de los casos) y consecuentemente centenares de líneas de código.
Un análisis pormenorizado de la problemática nos hizo llegar a varias conclusiones:
Particularmente tengo una norma de intentar no aceptar cálculos que no puedan hacerse en el sistema fuente (salvo lógicamente que sean cálculos que necesiten integrar datos de otros sistemas).
En definitiva, simplifica y serás feliz.
Tal y como comento en mi post sobre metodologías en proyectos de SAP BI, existe la técnica del "bottom-up" para generar los BBP. Típicamente la empleamos cuando no existen requerimientos claros, y ciertamente es más habitual realizarla en entornos SAP BW (en gran parte debido a la los extractores pre-existentes en el business content) que en otros entornos de BI.
Esta técnica puede servir para realizar informes operativos y también para traernos los datos que posteriormente nos servirán para realizar informes tácticos o estratégicos. El problema, es que si nos limitamos a "traer lo que hay en el ECC", sin una toma de requerimientos o un análisis claro de las necesidades, nos encontraremos con que habremos hecho informes muy bonitos pero sin valor añadido, y por tanto es mas que probable que para eso, el usuario se vaya directamente a la fuente del dato.
Revisemos bien los proyectos, contrastemos bien el BBP desde todos los puntos de vista (funcional y técnico), estemos permanente encima del usuario para entender lo que necesita y lo que hace, y sobretodo, no tropecemos dos veces con la misma piedra!
Te has encontrado con otras problemáticas? Por favor, coméntala!
El otro día vi un post en Linkedn que con cierta ironía decía que todo lo que veía en esta plataforma era wonderful. Y efectivamente, esa es la impresión que uno se lleva al cabo unos minutos de leer el time-line (y lo mismo si por ejemplo se va a cualquier presentación comercial sobre productos de TI)
Sin embargo, todos sabemos que el mundo no es tan bonito y que los proyectos no siempre salen como nos gustaría. Llevo ya algunos años en el mundo del Business Intelligence, y ese post me hizo pensar en aquellos proyectos que se torcieron pese a las maravillosas herramientas con las que contamos los consultores (si, eso último también es ironía).
Este post va de "lecciones aprendidas" con el que espero que os sirva para evitar errores en proyectos de Business Intelligence (algunos de ellos son específicos de SAP pero la mayoría valdrían para cualquier tecnología BI).
(1) EL USUARIO NO SE FÍA DE LOS DATOS
Éste punto sin duda es uno de los principales enemigos del BI. La desconfianza suele venir por alguno de estos dos motivos:
- El reporting en BI no cuadra (a veces) con el del sistema fuente.
- Los datos no permiten trazabilidad con lo que no hay manera de estar seguro que son correctos
Si ocurre el primer punto, lo más probable es que el usuario abandone el BI y se quede con los listados más o menos octogenarios que le da el sistema fuente. Y si ocurre el segundo, pues bien, probablemente se pase el día hablando mal de IT y ensanchando el mito de que “todo es culpa de los informáticos”.
Cuadre respecto el sistema fuente
Obviamente hay que hacer un desarrollo que lo garantice, pero luego hay que hacer algún tipo de desarrollo para demostrar que es así. Pueden encontrarse sistemas más o menos automáticos de cruzar por ejemplo listados de totales en el sistema fuente con el BI (y ahora con S4/HANA se nos abren muchas posibilidades), el problema es que por lo general en el BI tendremos más dimensiones de análisis (por lo que probablemente habrá que cruzar con diferentes listados), y además suele conllevar un coste de mantenimiento que el cliente no siempre está dispuesto a asumir.
Trazabilidad del dato
Si nuestro proyecto tiene cálculos complejos o integra muchas fuentes, tengamos en cuenta al inicio del proyecto que tendremos que demostrar que el cálculo funciona bien.
Si una vez implantado no lo hemos tenido en cuenta, entonces suele ser necesaria una reingeniería que el cliente probablemente no quiera asumir.
(2) EY!, QUE LOS CONSULTORES DE BI NO PODEMOS SABERLO TODO!
Y eso se acentúa en entorno SAP y sus dichosos módulos. Hace unas pocas semanas por ejemplo, tuve en un cliente tres reuniones más o menos seguidas, una con usuarios financieros, otra con usuarios de compras, y otra con usuarios del módulo de Real Estate, y cada usuario, por supuesto, expertos en su materia. Y en cada reunión hablamos de cosas y problemáticas totalmente distintas.
El riesgo que corremos en estas situaciones es importante, ya que:
- Podemos entender mal un requerimiento (o lo que es peor, directamente no entenderlo)
- Podemos no detectar que lo que nos están pidiendo es una tontería o que habría alternativas mucho mejores.
Para evitar este riesgo tenemos varias soluciones:
- Ponernos antes en contexto (hablando por ejemplo con los consultores del módulo correspondiente) y a poder ser llevar ya algunas iniciativas de antemano.
- Hacernos acompañar por el consultor experto en el módulo correspondiente
- En proyectos de envergadura: es imprescindible la participación a un determinado porcentaje de los consultores del sistema fuente.
También suele resultar de gran ayuda identificar que transacciones o listados tenemos disponibles en el sistema fuente en los que podamos contrastar (aunque sea parcialmente), que nuestros desarrollos en BI tienen sentido y son correctos.
(3) VAYA, PUES NO FUNCIONA
Por lo general, los proyectos de BI siguen una planificación tradicional: Definición del proyecto -> BBP -> diseño técnico –> extractores -> modelado -> reporting -> pruebas usuario
… y resulta que cuando empezamos con el reporting, tras dos meses del inicio del proyecto, nos damos cuenta que cierta funcionalidad pues… no funciona. Esto fácilmente puede ocurrir cuando tenemos un proyecto donde la arquitectura no es la habitual o tenemos algún requerimiento atípico.
En estos casos, hay que pensar en realizar un prototipado, prueba de concepto o recurrir a metodologías ágiles (aunque en BI no siempre es fácil hacerlas).
(4) INFOPROVIDERS (TABLAS DE HECHOS) CON DIMENSIONES DE GRANULARIDAD DIFERENTE
Tal y como comento en mi post sobre metodologías en proyectos de BI, los indicadores con el mismo conjunto de dimensiones deberían formar parte del mismo infoprovider, o lo que es lo mismo, intentar evitar que en un mismo infoprovider tengamos indicadores que tengan sentido solo para una parte de las dimensiones.
Recuerdo un proyecto, relativamente acotado, y con usuarios finales expertos. La dinámica del proyecto nos llevó a hacer una excepción a esta regla. Inicialmente no fue problema, los usuarios, que como digo eran expertos, y ayudaron a definir los requerimientos, entendían que en función de que indicadores y dimensiones pusieran en el informe, aparecieran valores nulos (el famoso “sin asignar”).
Ocurrió que al cabo de un par de años, el proyecto había crecido y los usuarios habían cambiado. El comportamiento de los informes no era entendido por los usuarios y acabaron abandonando el BI.
(5) NO UTILIZAMOS CADA HERRAMIENTA PARA LO QUE SIRVE
Ahora quizás voy a decir algo que sorprenda: en la etapa de pre-venta de un proyecto se suele hacer mucho énfasis en la arquitectura/herramientas de reporting que van a utilizarse.
Sinceramente, creo que siempre que se escojan herramientas que hayan demostrado que en el mercado son solventes, este punto es poco importante. Es decir, creo que el éxito de un proyecto no depende tanto de que herramientas se utilicen, como si del alcance y definición (y obviamente ejecución) del proyecto.
Dicho esto, hay una excepción: no podemos por ejemplo poner una herramienta de cuadro de mandos para hacer lo que en realidad un reporting operativo encubierto.
Recuerdo un proyecto donde era pre-requisto del cliente utilizar una herramienta determinada de cuadro de mando. El reporting consistía en un mapa geográfico inicial con valores de indicadores, pero posteriormente se requerían muchas pantallas de navegación drill-down para obtener el detalle. Ya en tiempo de preventa desaconsejamos dicha herramienta y ofrecimos una alternativa (a lo que el cliente se negó). Involucramos en el proyecto al propio fabricante y repercutimos al cliente el riesgo (en tiempo y en coste). Dimensionamos el proyecto de forma correcta, siempre teniendo en cuenta el riesgo que representaba la herramienta. Es decir, hicimos todo lo que a mi modo de ver podía hacerse, sin embargo el resultado quedó lejos de lograr satisfacer al cliente.
(6). NOS COMPLICAMOS. SIMPLIFICA Y SERÁS MÁS FELIZ
Un cliente nos solicitó ayuda en un proyecto de SAP BW que no funcionaba. El problema principal (que no el único) era que había que calcular muchos indicadores y se producían continuos errores.
La mayoría de indicadores llegaban a tener hasta dos páginas de explicación de cómo debía ser el cálculo (muy complejo en la mayoría de los casos) y consecuentemente centenares de líneas de código.
Un análisis pormenorizado de la problemática nos hizo llegar a varias conclusiones:
- El coste de calcular y verificar el indicador en muchos casos era superior al propio beneficio que suponía disponer de ese indicador. Con indicadores más sencillos se llegaba prácticamente al mismo objetivo.
- Muchos indicadores no podían calcularse en el sistema fuente (porqué necesitaban saber la situación en cierto momento), cosa que añadía complejidad a BW y impedía la trazabilidad del dato. Con ciertas modificaciones relativamente sencillas en el sistema fuente se corregía la situación.
Particularmente tengo una norma de intentar no aceptar cálculos que no puedan hacerse en el sistema fuente (salvo lógicamente que sean cálculos que necesiten integrar datos de otros sistemas).
En definitiva, simplifica y serás feliz.
(7) OJO CON LA METODOLOGÍA "BOTTOM-UP"
Tal y como comento en mi post sobre metodologías en proyectos de SAP BI, existe la técnica del "bottom-up" para generar los BBP. Típicamente la empleamos cuando no existen requerimientos claros, y ciertamente es más habitual realizarla en entornos SAP BW (en gran parte debido a la los extractores pre-existentes en el business content) que en otros entornos de BI.
Esta técnica puede servir para realizar informes operativos y también para traernos los datos que posteriormente nos servirán para realizar informes tácticos o estratégicos. El problema, es que si nos limitamos a "traer lo que hay en el ECC", sin una toma de requerimientos o un análisis claro de las necesidades, nos encontraremos con que habremos hecho informes muy bonitos pero sin valor añadido, y por tanto es mas que probable que para eso, el usuario se vaya directamente a la fuente del dato.
CONCLUSIÓN
Revisemos bien los proyectos, contrastemos bien el BBP desde todos los puntos de vista (funcional y técnico), estemos permanente encima del usuario para entender lo que necesita y lo que hace, y sobretodo, no tropecemos dos veces con la misma piedra!
Te has encontrado con otras problemáticas? Por favor, coméntala!
- SAP Managed Tags:
1 Comment
