Definición de requerimientos en un proyecto de Business Intelligence

Posted on by Àlex Caminals

 

En todo proyecto de Business Intelligence existe una fase inicial que proporciona la base sobre la que debe definirse el proyecto: La definición de requerimientos.

Se trata de la fase más importante de todo el proyecto. Una mala definición de requerimientos tendrá implicaciones negativas en el resto del proyecto. Y para eso, es crucial disponer de los conocimientos y la experiencia necesaria para abordar esta fase.

Hay que tener en cuenta que los proyectos de Business Intelligence tienen grandes peculiaridades que los hacen especiales, difíciles de gestionar. Es por eso que la gestión de proyectos llevada a cabo por personas sin experiencia previa en la gestión de proyectos de Business Intelligence conlleva un alto riesgo. Todo ello provoca que el índice de éxito de este tipo de proyectos sea, en comparación con proyectos de desarrollo de software, mucho menor.

Requerimientos genéricos y acordados

Obtener los requerimientos a partir de documentos generados por los usuarios puede, a primera vista, verse como algo altamente positivo, ya que permitiría cerrar la fase de obtención de requerimientos de manera simple. Sin embargo, utilizar esta metodología conlleva un gran riesgo: Obtener requerimientos demasiado específicos.

La obtención de requerimientos se debe realizar a partir de reuniones con los distintos usuarios del sistema. Durante estas reuniones, los usuarios deben exponer sus necesidades mientras que el encargado de obtener los requerimientos deberá interponer preguntas cuestionando estos requerimientos y dirigiendo a los usuarios a un punto de convergencia, a un acuerdo donde sus necesidades se vean cubiertas por los diferentes requerimientos definidos.

La documentación de los requerimientos por parte de los usuarios, previa a estas reuniones, es de gran ayuda para que los usuarios tengan claro qué necesitan de la solución de Business Intelligence. Sin embargo, esa información no debería pasar directamente a la lista de requerimientos del proyecto sin antes efectuar esta serie de reuniones con el objetivo de refinar y acordar esos requerimientos, para así amoldarlos a todos los usuarios.

A continuación se presentan un par de ejemplos sobre especificidad de requerimientos como muestra del riesgo que esto supone.

Sobrecoste del proyecto

El primer ejemplo trata del aumento de coste del proyecto a partir de una mala toma de requerimientos.

Imaginemos un usuario qué necesita disponer de un informe de ventas para el mes en curso para así poder monitorizar posibles desviaciones respecto a los objetivos definidos. El fin de este informe es el de poder disponer nuevas medidas para reconducir la situación en caso de desviaciones negativas.

Ahora imaginemos otro usuario que necesita información de las ventas del mes anterior para poder hacer el informe mensual de cierre de ventas.

La obtención de requerimientos directamente de los usuarios sin la posibilidad de modificación de aquellos, supone la definición de dos informes diferentes:

  • Ventas del mes actual
  • Ventas del mes anterior

Sin embargo, podría ser que estos dos informes pudieran ser fusionados en uno solo. En el caso en que ambos informes necesitaran diferentes columnas, es muy probable que podamos llegar a un acuerdo para fusionar ambos informes y generar uno solo con la fusión de ambos conjuntos de columnas. De esta manera, un solo informe sería suficiente para poder dar servicio a ambos usuarios. Esto significaría una reducción en la carga de trabajo en la fase de diseño y desarrollo, en la gestión del proyecto, en las pruebas y en la puesta en marcha del proyecto. Asimismo, también reduciría el coste de mantenimiento del proyecto una vez éste estuviera en producción.

El uso de personal con experiencia en proyectos de Business Intelligence durante la toma de requerimientos permitiría detectar escenarios como éste.

Mi experiencia personal me remite a casos en los que, a partir de una lista original de más de 200 informes, se pudo reducir el número de informes final a poco más del 50 (una reducción del 75%).

Gracias a esto se pudo llevar a cabo el proyecto. Si hubiésemos tenido que hacer una valoración del proyecto a partir de los requerimientos iniciales, se habría superado el presupuesto y por tanto el proyecto no se habría llevado a cabo.

Definición incompleta de dimensiones

El segundo ejemplo trata de la definición de dimensiones a partir de los informes específicos requeridos por los usuarios.

La definición de los informes basados en las necesidades de un usuario suele ser muy específica. Es decir, el usuario se concentra en las columnas necesarias únicamente para su informe. Por tanto, los requerimientos obtenidos a partir de informes de usuario suelen ser pobres, limitantes y poco generalistas.

El diseño de una solución a partir de estas especificidades supone tener una visión incompleta del ámbito global del sistema. Lo cual significa que definir los requerimientos de un sistema de Business Intelligence a partir de los informes de usuario o de la visión que los usuarios pueden tener de la solución a partir de los informes que necesitan, es un enfoque erróneo.

Volviendo al ejemplo de las ventas por mes, la toma de requerimientos realizada por una persona inexperta podría limitar la dimensión temporal a una granularidad a nivel de mes (y, otorgándole un voto de confianza, con agregaciones a nivel de trimestre, semestre y año).

Esta definición de la dimensión temporal es claramente limitante y erróneo, puesto que las transacciones de venta están definidas a un nivel más bajo (por supuesto a nivel de día, o quizá a nivel de hora, minuto y segundo).

Lo mismo puede suceder con cualquier otra dimensión asociada a una tabla de hechos. Si basamos los requerimientos en los informes o en lo que los usuarios creen que necesita el nuevo sistema de Business Intelligence, podemos caer en el error de definir dimensiones con una granularidad superior a la real, y podemos obviar información útil que podría proporcionar un análisis con un alto valor añadido en el futuro.

Conclusión

La obtención de requerimientos en un proyecto de Business Intelligence es una tarea clave para el éxito del proyecto.

Su ejecución requiere un alto nivel de experiencia en proyectos de Business Intelligence para poder llevarla a cabo con las máximas garantías de éxito. En caso contrario, estaremos poniendo trabas al proyecto, incrementando las posibilidades de fracaso.

El sobrecoste del proyecto y la definición errónea de dimensiones son dos de las consecuencias de una mala definición de los requerimientos. La primera puede ser la causa de cancelación del proyecto. La segunda supone un sobrecoste en las tareas de mantenimiento evolutivo y la pérdida de confianza en la solución de Business Intelligence.

A la hora de definir un proyecto de Business Intelligence y definir los requerimientos de éste, vale la pena invertir en experiencia. En caso contrario, este error puede salir muy caro.

Business Intelligence para unificar criterios

Posted on by Àlex Caminals

 

El Business Intelligence no solo proporciona la capacidad de analizar datos. También nos permite disponer de una plataforma única de acceso a la información.

Esta fuente de información única y consolidada es la respuesta a las necesidades de la gran mayoría de organizaciones, que ven como el acceso a la información por parte de sus empleados acaba creando un sinfín de versiones de los mismos datos.

 

El riesgo de poder manipular los datos

Un escenario habitual en las organizaciones es el de permitir a los usuarios disponer de los datos para poder analizarlos por cuenta propia. Sin entrar para discutir sobre el riesgo que esto supone por la posibilidad de manipulación de esos datos y la consecuente falsificación de los resultados (hecho que he podido comprobar en varias ocasiones a lo largo de mi vida profesional como consultor), lo cierto es que permitir a los usuarios crear sus propios análisis (típicamente usando hojas de cálculo como Excel), supone un gran riesgo para las organizaciones.

Errar es humano. Los usuarios son humanos. Por tanto, existe un riesgo asociado al uso de Excel por parte de los empleados. En conclusión, a mayor el número de empleados creando fórmulas y cálculos (a veces muy complejos) en sus hojas de cálculo, mayor el riesgo de que se produzcan errores.

Un modelo de datos único

Disponer de una solución de Business Intelligence con un modelo de negocio único permite que los informes generados provengan todos de la misma fuente de datos y que utilicen los mismos cálculos para la elaboración de dichos informes.

Las métricas, los indicadores y los KPI pasan a ser homogeneizados en un sistema de Business Intelligence. Esto evita situaciones comprometidas y que ponen en riesgo la veracidad de la información

Procesos dirigidos por la toma de decisiones inteligente

Una vez disponemos de una solución que nos proporciona información consolidada bajo un único modelo de negocio, podemos dar un paso más y utilizar esta solución de Business Intelligence no solo para proporcionar información si no para ayudarnos a tomar decisiones acertadas en la ejecución de los procesos de negocio.

Usaré como ejemplo un cliente para el que estuve realizando un proyecto hace años. Se trataba de una organización con una fuerza de ventas de varios centenares de empleados en toda Europa.

Como es de imaginar, alinear todos los vendedores a unos criterios unificados para los procesos de venta es algo altamente complicado. La definición de procesos de venta y la priorización de las oportunidades de venta había sido siempre el talón de Aquiles de esta compañía. El seguimiento por parte de los jefes de venta de los diferentes países era muy complicado. Y aún lo era más en el nivel superior, a nivel de toda Europa.

La solución a este problema se obtuvo a partir de la propia herramienta de Business Intelligence que utilizaban para analizar los procesos de venta. La solución consistió en generar la lista de oportunidades de venta sobre las cuales los diferentes vendedores de priorizar sus esfuerzos. Y todo a partir de una lista de directrices definidas a nivel europeo.

Tomando como partida la información de las oportunidades de venta, los clientes los productos los vendedores y los objetivos, se crearon informes diarios de actividad para los distintos vendedores. De esta manera se consiguió unificar los criterios del proceso de ventas en toda la región.

Conclusión

La democratización del acceso a los datos permite un grado de libertad a los empleados no eximido de riesgos. Es muy importante que los informes corporativos sean validados si provienen de modelos de datos generados por empleados a título individual.

Para evitar el riesgo de usar modelos modificados por los usuarios, es conveniente usar un modelo de negocio único para la solución de Business Intelligence. Un modelo de datos único es la base que permite a los empleados extraer información homogénea.

Pero además, una solución de Business Intelligence con un modelo de negocio único puede proporcionar también información para mejorar y consolidar los procesos internos de la organización. De esta manera conseguiremos homogeneizar los procesos y ser más consistentes.

Data Analytics y definición de objetivos para mejorar la toma de decisiones

Posted on by Àlex Caminals

 

Para poder determinar el nivel de corrección de nuestras acciones, los seres humanos necesitamos saber como las hemos ejecutado. Esta medición de nuestros actos nos permite evaluar el grado de calidad de cada una de nuestras acciones.

Además, también solemos tener diferentes niveles de aceptación sobre la corrección de esas acciones, que nos permiten poner etiquetas a esas acciones (e.g. Muy deficiente, Insuficiente, Suficiente, Bien, Notable, Excelente). Esas etiquetas las podemos asignar al comparar un resultado con unos objetivos.

En términos de Data Analytics, el uso del análisis de datos para la medición de procesos y su comparación con unos objetivos previamente determinados es de vital importancia para poder determinar el éxito de los procesos de una organización y así poder mejorar la toma de decisiones.

Consulta vs. Análisis

Al efectuar una medición sobre un proceso, estamos almacenando datos sobre la medición y el contexto de ese proceso. Esos datos pueden ser consultados de manera individual. Es decir, podemos visualizar las métricas y el contexto asociado a esa medición en concreto. Pero pocas decisiones pueden tomarse en base a una única medición.

El análisis de miles o millones de mediciones, el hecho de tratar un gran volumen de datos para obtener una métrica agregada, supone una dificultad adicional que requiere la existencia de una solución de Business Intelligence para poder obtener las respuestas deseadas.

Cómo visualizar los datos, bien en bruto como en una medición individual, bien mediante su agregación al analizar un gran conjunto de datos, es la gran diferencia entre una simple consulta y el análisis de datos.

Realidad vs. Objetivos

El análisis de miles o millones de datos nos proporciona información sobre hechos acaecidos en el pasado. Esta información, nos permite saber que ha sucedido hasta el momento. Sin embargo, esa información, por sí sola, no nos permite saber la calidad de esos hechos.

En una gran cantidad de ocasiones el ser humano dispone en su mente de una vara de medir para evaluar la calidad de los procesos que han producido esas mediciones. Esa vara de medir es lo que denominamos «objetivos».

Por ejemplo, si un jugador de baloncesto lanza a canasta, el público (que mide como canasta o fallo ese lanzamiento) comparará a ese valor con el objetivo que no es otro que encestar el tiro. Sin embargo, el propio jugador puede medir lanzamiento de distintas maneras a partir de la dirección, el ángulo de tiro y la fuerza del lanzamiento. En su caso, el objetivo no es solamente encestar sino ejecutar el tiro con la dirección, el ángulo y la fuerza deseadas para poder encestar, ya que un lanzamiento podría acabar en canasta por mera suerte, pero no debería considerarse como un buen lanzamiento para un jugador que se precie.

Definición de objetivos

Con este ejemplo, vemos que para cada métrica y contexto podemos tener unos objetivos determinados. Es fácil imaginar que disponer de todos los objetivos para todas las metricas en todos los contextos posibles es algo muy complicado y aún más en la mente de un ser humano. Es por eso, que debemos almacenar esos objetivos para poder compararlos con los datos reales provenientes de esas mediciones que estamos efectuando.

Los objetivos suelen definirse a niveles superiores al nivel de detalle de las mediciones (e.g. Las ventas de una organización pueden estar definidas a nivel de trimestre y zona geográfica, mientras el proceso se produce en un contexto con más dimensiones y con un nivell de análisis más detallado). Esto permite una definición de objetivos relativamente sencilla que puede ser revisada por las personas responsables de su definición con relativa facilidad.

Conclusión

El análisis de datos nos proporciona la capacidad de mostrar datos agregados sobre mediciones de procesos individuales. Sin embargo, esta información carece de todo su valor si no somos capaces de comparar esos valores con los objetivos definidos para estos procesos.

La definición de objetivos para los diferentes procesos de una organización permite su comparación con los datos reales obtenidos mediante la medición de éstos.

Las herramientas de Data Analytics nos permiten comparar los objetivos con los datos acumulados de las mediciones realizadas en los diferentes procesos. Esta comparación proporciona un gran valor añadido a la organización, ya que permite etiquetar cada uno de las mediciones a partir de esa comparación con los objetivos. Esa comparación, esa visión de la realidad respecto a los objetivos esperados, es lo que permite la toma decisiones inteligente.

La importancia de una auditoría de BI

Posted on by Àlex Caminals

La construcción de una solución de Business Intelligence (BI), podría compararse a la construcción de un edificio. Necesitamos cimentar esta solución sobre una base sólida, que nos permita construir los diferentes proyectos, con la seguridad de estar aposentados sobre una estructura que nos permita crecer.

Pero, si todo el mundo acepta esto en la construcción, ¿porqué hay organizaciones que optan por otra estrategia a la hora de construir una solución de BI?

Una base poco sólida

Hace tiempo, realicé un proyecto para un cliente que cometió un grave error. A este proyecto lo bauticé como «La torre de Pisa».

Este cliente contactó conmigo porque en su organización tenían varios problemas con su solución de BI. El más importante de ellos era funcional. No conseguían obtener resultados correctos. Querían un servicio de consultoría experto, que les permitiese identificar y solucionar los errores existentes. Habían intentado solucionarlo con la consultora que les había construido la solución de BI, pero éstos fueron incapaces de hallar la solución a dichos problemas.

Dada la urgencia del cliente, mi objetivo se centró única y exclusivamente en la resolución de las incidencias detectadas. Por tanto, dejé de lado mi enfoque habitual (top-down), para focalizarme en los problemas identificados. Sin embargo, rápidamente pude observar que los problemas que causaban dichas incidencias, tenían su origen en fallos de diseño de la solución de BI existente.

Lo siguiente que hice, fue un informe detallando las implicaciones de estos errores de diseño dentro del sistema junto con un análisis de pros y contras del hecho de mantener o solucionar esos errores.

Pero también hice hincapié en el hecho de haber construido un sistema de BI sin ningún tipo de validación de la calidad de éste por parte de nadie. No habían hecho ningún tipo de indagación en clientes anteriores de esa consultora ni habían optado por la validación del diseño de un experto sobre el trabajo de su proveedor de servicios. Habían aceptado el proyecto con una fe ciega. Y se trataba de un proyecto con una visibilidad transversal en su organización, donde las repercusiones podían afectar a la toma de decisiones en todas las áreas y niveles de la organización.

Una decisión arriesgada

Estaban construyendo un gigante con pies de barro. En ese momento, les puse como ejemplo la torre de Pisa. Se encontraban en el punto en el que vieron como la torre estaba inclinada. Era el momento de decidir qué hacer. Si seguían adelante, corrían el riesgo de que la solución de BI fuera imposible de mantener en un futuro, teniendo que realizar una gran inversión para reconstruirla. Si decidían solucionar los problemas de base, tendrían un sobrecoste no presupuestado, pero a la larga, el coste sería mucho menor.

Mi cliente quería una solución rápida. Es por eso por lo que optó por seguir adelante con una resolución de las incidencias detectadas inicialmente, sin solventar los problemas de base en el diseño de su solución de BI. Así pues, me dediqué a solucionar las incidencias, no sin antes advertir del riesgo que ello podría suponer de cara al futuro, en el caso de que quisieran ampliar la solución de BI existente.

Una decisión errónea cae por su propio peso

Creo que fue al cabo de un par de meses de haber acabado el servicio por el que me contrataron, que recibí una llamada del mismo cliente. Estaban desesperados. Tenían un nuevo proyecto de BI en fase de desarrollo, pero no había manera de hacerlo funcionar. Ni su proveedor de servicios habitual ni su equipo interno eran capaces de seguir adelante con el proyecto. Cuando intentaban implementar una nueva funcionalidad, provocaban que otras funcionalidades ya existentes dejaran de funcionar. Se encontraban en un callejón sin salida. La torre de Pisa no podía crecer más.

Esta vez, mi cliente optó por un enfoque diferente. Me pidió que evaluara la posibilidad de finalizar el proyecto con el que estaban atascados, pero también una estimación del coste que supondría la reconstrucción de su solución de BI para poder disponer de un sistema escalable que pudiera crecer en el futuro de manera simple.

Al presentar mi propuesta, les indiqué la importancia de evaluar los costes a largo plazo. Ese había sido su gran error la primera de contactaron conmigo. En un proyecto de BI, es muy importante tener en cuenta los futuros proyectos a la hora de calcular el Retorno de Inversión (ROI). Así lo hicieron. Y llegaron a la conclusión más acertada en su situación. Decidieron reconstruir su solución de BI.

Tal fue la confianza que obtuve del cliente, que, en lugar de contratar los servicios de una consultora de más envergadura que StraBIA, decidieron encargarme el proyecto de reconstrucción de su solución de BI íntegramente. Aquello fue el principio de una satisfactoria relación profesional.

Conclusión

Una solución de BI es un sistema con una amplia visibilidad en una organización, ya que se utiliza para la toma de decisiones a todos los niveles y en todas las áreas de ésta. Al ser un sistema tan importante, es necesario estar plenamente convencido de que su construcción satisface los requerimientos de un sistema de BI. Esto goza aún de más importancia por el hecho de ser un tipo de proyecto con un número de expertos muy bajo si lo comparamos con proyectos de desarrollo de aplicaciones, por ejemplo.

Siempre que realizo un proyecto en un nuevo cliente con una solución existente de BI, intento dedicar un poco de tiempo a su análisis, identificando áreas de mejora. Sé que, haciendo esto, algunos de mis clientes han evitado situaciones desagradables en el futuro. Eso me anima a seguir haciéndolo, aunque no sea StraBIA quien acabe realizando el proyecto.

Afortunadamente, esto no es siempre así, y en ocasiones como la que os acabo de contar, sí que acabamos realizando el proyecto. Y en estos casos, una auditoría del nuevo sistema BI evaluaría la nueva solución con muy buena nota.

Quisiera finalizar con un par de preguntas:

  • ¿Crees que tu actual solución de BI está preparada para crecer manteniendo los niveles de rendimiento, efectividad y mantenibilidad requeridos por tu negocio?
  • ¿Crees que tu actual solución de BI superaría una auditoría?

Si has respondido «No» a alguna de estas preguntas, espero que este artículo te haga reflexionar sobre los riesgos a los que te puedes enfrentar en el futuro.

Generando confianza con el cliente

Posted on by Àlex Caminals

 

 

Una de las cosas que más me gusta de mi trabajo es el trato con el cliente. Conseguir una relación de confianza, ir más allá del mero trato profesional… realmente no tiene precio. Y eso se consigue con implicación y sinceridad, aunque a veces pueda ir en detrimento de la facturación.

Para ilustrar esto, voy a exponer una situación en la que se encontró un colega mío hace unos años.

Houston, tenemos un problema!

Todo empezó, como es habitual, con un correo electrónico (o una llamada). Un cliente de un partner de la consultora donde mi amigo estaba trabajando, tenía una necesidad urgente. Se trataba de un problema que el equipo de Business Intelligence (BI) del cliente era incapaz de resolver. La solución en ese momento fue la siguiente:

«Vamos a mandar a un consultor experto para que os ayude a resolver el problema!».

Lo cierto es que así fue. Mi amigo fue capaz de resolver el problema. Pero, ¿cuál fue el coste para el cliente? Lo cierto es que no lo sé, pero fueron cinco días en el Reino Unido (no sabían cuál era el problema y se contrató una semana de trabajo por lo que pudiera ser), incluyendo los vuelos, los taxis, el hotel, las dietas… Y a eso hubo que añadirle el margen del partner!!

El foco del problema

El coste puede ser lo de menos si el problema y su resolución lo justifican. Pero en este caso, el «gran» problema era que el cliente no sabía cómo visualizar una línea horizontal en un gráfico, para indicar una constante que venía a ser el límite entre un buen y un mal rendimiento de cierto proceso.

Es decir, que todo el coste del servicio (una semana de un consultor experto desplazado en el Reino Unido) vino por la visualización de una línea.

El cliente quedó contento (supongo que el dinero, al tratarse de una Administración Pública, no era un problema). El partner quedó contento. Y la consultora por la que trabajaba mi amigo también quedó contenta.

Nadie se planteó si era correcto o no lo que se hizo, puesto que se solucionó un problema y todas las partes quedaron satisfechas.

Hasta aquí hemos llegado

Es curioso pero esa fue la última vez que mi amigo trabajó para ese cliente. Había trabajado para ellos en el pasado, pero después de esa semana, nadie de su consultora volvió a trabajar para ellos. Podría ser que su equipo de BI no necesitara más soporte de ningún tipo? Podría ser. Pero también podría ser que, una vez analizado el proyecto, se hubieran dado cuenta del enorme coste que tuvo para ellos añadir una línea.

Por lo que me comentó mi amigo acerca del equipo de BI del cliente, me decanto más por la segunda opción y la consiguiente pérdida de confianza en su proveedor de servicios de BI (el partner de la consultora). O quizá fuera del partner con la consultora. ¿Quién lo sabe?

Porque tú, ¿cuánto pagarías por una línea?

Generando confianza

Afortunadamente para mí, soy yo quien gestiona mi cartera de proyectos. Y eso me permite tomar decisiones sin deberme a ninguna obligación contractual. Sin compromisos.

En un caso así, antes de cerrar un encargo de consultoría, me gusta saber exactamente cuál es el objeto del proyecto. Porque si no lo hago, corro un doble riesgo: Puedo cobrar por un servicio sobreestimado (como en el caso del escenario planteado) o puedo estar mandando a alguien de mi equipo a un campo de minas. Y ninguna de las dos situaciones es conveniente para generar una relación satisfactoria con un cliente.

Lo primero que hago es hablar con el cliente, entender cuál es el problema y analizarlo desde todos los puntos de vista. Y esto puede suponer tener que decirle al cliente que, bajo mi más humilde opinión (apoyada, eso sí, sobre muchos años de experiencia), lo que pretende hacer no es lo que más le conviene. Aunque esto signifique echar por la borda un contrato.

Es la diferencia entre querer obtener beneficios a corto plazo matando a la gallina de los huevos de oro (el cliente), o querer generar confianza con éste a partir de una ética profesional.

Cuidando las relaciones personales y profesionales

Mi opinión es que debo cuidar a mis clientes, tanto a los actuales como a los potenciales.

Con esta forma de actuar, consigo generar confianza y tener un trato más humano y personal con mis clientes. De esta manera, sé que cuando se acuerden de mí, lo harán en positivo. Ese es el legado que quiero dejar a mis clientes, junto con un buen servicio.

Con esta forma de actuar sé que pierdo contratos a corto plazo, pero gano algo mucho más valioso: La satisfacción personal de actuar de manera íntegra con respecto a los valores de StraBIA (que son los míos, claro está).

El coste de no usar Business Intelligence

Posted on by Àlex Caminals

 

 

A la hora de abordar un nuevo proyecto siempre debemos tener en cuenta el Retorno de Inversión (ROI, en inglés). Un proyecto de Business Intelligence no debería ser menos.

Hoy quiero hablaros de un caso que me encontré hace unos años, que muestra una parte de la ecuación: la del coste asociado a no usar Business Intelligence.

El escenario

Hace unos años tuve un cliente que quería que le hiciese un estudio sobre la necesidad de introducir procesos de BI en su negocio. Como es habitual en este tipo de estudios, el proyecto fue corto pero muy intenso, lleno de reuniones con directivos y responsables de diferentes áreas de negocio.

En estas reuniones, mi objetivo era analizar sus procesos de obtención y explotación de la información, para su posterior aplicación a la toma de decisiones en todos los niveles de la empresa. Por tanto, las reuniones cubrían procesos de decisión tanto ejecutivos, como tácticos y operacionales.

El cliente fue exquisito desde el punto de vista de un consultor. Hubo una gran predisposición a la colaboración y los interlocutores vinieron muy preparados, cosa que facilitó mi trabajo. De hecho, hubo tanta apertura y sinceridad, que su Director de Finanzas (CFO) me explicó a qué se dedicaba cada día desde hacía más de 20 años.

Obteniendo información clave

Cada mañana, el CFO de la empresa obtenía de su equipo un listado con las órdenes de venta de los últimos tres meses. Ese listado contenía más de 100 páginas (lo pude sostener en mis manos y pesaba mucho, había muchas páginas).

Su tarea principal para empezar el día y poder asignar el trabajo a su equipo era el de revisar cada una de las órdenes de venta de ese informe. En concreto, marcando con un bolígrafo aquellas que requerían una atención especial (ya fuera por retrasos en el pago, por descuentos no aplicables, etc.), y pasando a su equipo la responsabilidad de hacer un seguimiento de éstas.

Un coste para la empresa

El hombre, un empleado con un alto nivel de seniority y muy respetado en la empresa, se mostraba orgulloso de poder realizar esta tarea cada día. Es más, creía que gracias a su trabajo revisando el informe, el departamento funcionaba con un alto nivel de calidad y eficiencia. Eso no se lo negué.

Pero lo que sí que hice fue preguntarle a qué dedicaría su tiempo si ese informe pudiera hacerse siguiendo exactamente sus criterios, sin necesidad de estar un par de horas cada día revisando todas esas líneas. Me contestó que tenía mucho trabajo y que siempre le faltaban horas para poder realizar todas sus tareas, con lo cual tenía que alargar su jornada laboral.

El coste de ese ejercicio diario era de 2 horas. Y esas horas eran contabilizadas y suponían un coste para la empresa.

Calculando el Retorno de Inversión

Al finalizar esa reunión, le comenté que esa tarea repetitiva que él se dedicaba a hacer cada mañana podía realizarse a partir del análisis de las órdenes de ventas. Que podía seleccionar el rango de fechas (incluso más allá de tres meses), y que podía filtrar por cualquier campo relativo a clientes, productos, descuentos, vendedores, etc., para así dirigir su atención allí donde más le interesase. Y que la lógica a aplicar para seleccionar las órdenes de venta sobre las que trabajar podía ser tan compleja como quisiera, incluso teniendo en cuenta información no disponible en ese informe.

Y lo mejor de todo, que una vez realizado ese análisis, podría planificarse para que se ejecutara periódicamente (por ejemplo, cada día antes de empezar la jornada laboral), y para que enviara ese informe a cada uno de los responsables de verificar esos datos y hacer un seguimiento de las órdenes de venta.

De esta manera, es cierto que habría un coste inicial de creación del análisis, pero se ahorraría las dos horas diarias para el resto de su vida laboral.

Pusimos unos números rápidos en una hoja de papel. Si en un año tenemos unos 220 días laborales, en 20 años obteníamos unos 4.000 días. A razón de 2 horas diarias, eso arrojaba una cifra de 8.800 horas. No me dijo su coste por hora, pero yo lo puse en 100 €, cantidad que no rebajó (seguramente era superior). El coste total era de 880.000 €. Y eso solo en un proceso de negocio.

Finalmente, el CFO vio que era una buena idea eso de introducir BI en la empresa.

Conclusión

Calcular el Retorno de Inversión no es una tarea fácil. A veces no es tanto cuestión de intentar poner números a los beneficios obtenidos (a menudo basados en una predicción sin una base objetiva), como de obtener la reducción de coste de los procesos actuales que serán obsoletos.

En la gran mayoría de organizaciones (por no decir todas), hay procesos de obtención manual de información. Si conseguimos eliminar ese tiempo mediante la explotación inteligente de la información, reduciremos ese coste.

Es más, podremos dedicar el tiempo de esos analistas de datos a pensar en cómo mejorar el negocio, haciendo que se incremente su satisfacción y su productividad.

El Business Intelligence nos ayuda a obtener conocimiento a partir de la explotación de los datos. Y ese conocimiento permite la toma de decisiones inteligentes para la mejora de los procesos de las organizaciones. Si a ello añadimos una reducción en los costes de obtención de la información, estamos haciendo que el ROI de los proyectos aumente, cosa que justifica la realización de esos proyectos de BI.

¿Hablamos el mismo idioma?

Posted on by Àlex Caminals

 

 

Una vez asistí a una reunión del consejo de dirección de una empresa con el objetivo de hacer una valoración de la salud de la empresa en términos de gestión y uso de la información.

Se trata de un caso típico que quiero compartir con vosotros.

 

La reunión

En la reunión había la Directora General y todo el conjunto de directores de área de la empresa: el Director Comercial, el Director de Operaciones, la Directora Financiera, etc.

Durante las reuniones individuales con los distintos directores de área que había tenido en los dos días previos a esta reunión, pude ver cómo se explotaban los datos en la compañía. Es por eso que realicé varias peticiones de información para que llevaran esos informes a la reunión.

Después de hacer una introducción sobre el porqué de mi presencia en la reunión, la Directora General me pidió que diera mi opinión del estado de madurez de la empresa respecto al uso de los datos. Tengo que adelantar que reinaba un aire de superioridad en el ambiente, con una gran autoconfianza entre los presentes, esperando una gran valoración por mi parte.

Había llegado mi turno. Pero en vez de arrancar con mi análisis de la situación, le pedí a la Directora General que, antes de exponer mi valoración, pidiera a sus directores de área los ingresos del mes anterior, uno de los informes que había pedido en los días anteriores.

Cuando la Directora General preguntó quién podía darle esos números, hubo tres personas que se ofrecieron a hacerlo: los mencionados anteriormente Director Comercial, Director de Operaciones y Directora Financiera. Hubo una sonrisa de satisfacción en la sala. Tres directores de área tenían los números. Eso significaba que la información de la compañía fluía entre departamentos, que no se trataba de una organización con silos de información departamentales… Pero, ¿era realmente así?

La gran sorpresa

Arrancó el Director Comercial con su cifra de ingresos del mes anterior: 150M €. Un gran resultado. Hubo sonrisas y aplausos de todos los asistentes a la reunión… excepto de un par de ellos: El Director de Operaciones y la Directora Financiera.

Cuando la euforia empezó a bajar de tono, el Director de Operaciones comentó que sus números era algo distintos, bajando la cifra hasta los 135M €. En ese momento, las sonrisas se volvieron muecas de extrañez. ¿Quién estaba dando unos números equivocados?

Pero al momento arrancó la Directora Financiera dando su cifra: 125M €. Silencio. Incredulidad. Miradas a un lado y a otro de la mesa.

En ese momento, decidí romper la tensa situación.

«Miembros de la junta, no se preocupen. No hay nada que no pueda solucionarse.»

Me miraron con expectación.

Un doble problema

Se trataba de un doble problema: Los datos habían sido obtenidos de diferentes bases de datos y la definición de «Ingresos» era diferente para cada una de las áreas de negocio que habían extraido la información.

El primer problema, el uso de información contenida en diferentes sistemas y aplicativos, no tiene porqué serlo si la información fluye ágilmente en una organización. Sin embargo, mi experiencia me decía que esa era la excepción. Y con un par de preguntas en las reuniones iniciales pude comprobar que esta compañía no era una excepción.

Pero el segundo problema es mucho más grave. Una organización necesita que los indicadores de rendimiento sean comunes, que tengan la misma definición y que la manera de obtenerlos sean estándares. Si esto no ocurre, el significado de los números obtenidos será totalmente diferente, creando una gran confusión y desconfianza en los sistemas de información.

En este caso, el indicador era «Ingresos» («Revenue» en inglés). Pero este indicador en teoría común, significaba en realidad diferentes cosas para cada una de las áreas de negocio en cuestión:

• Área Comercial: Importe de las oportunidades ganadas durante un periodo.
• Área de Operaciones: Importe de las órdenes de compra entradas en el sistema que debían ser procesadas y enviadas a los clientes.
• Área Financiera: Importe de las órdenes de compra cobrado y no retornado en un periodo de 15 días.

Al exponer los motivos de estas diferencias, todos los miembros presentes se dieron cuenta de que la explotación de la información en la organización necesitaba cambios muy importantes.

La solución

Al salir de la reunión, la Directora General me preguntó cuál era el camino a seguir para revertir esa situación. Le comenté, que una opción era realizar una integración de datos en un repositorio común y crear un conjunto de métricas e indicadores común para toda la empresa. Al hacer esto, todos los miembros de la organización utilizarían el mismo lenguaje para referirse a conceptos del negocio, y obtendrían la información de una manera común e inequívoca.

Sin embargo, le recomendé hacer algo aún mejor: Definir una estrategia de Business Intelligence alineada a la visión de la empresa, con fases y objetivos claramente definidos. De esta manera, los esfuerzos realizados en esta área tendrían sentido a medio y largo plazo, evitando la creación de parches con beneficios a corto plazo, pero sin un sentido de futuro.

La Directora General dijo que tenía que pensarlo y discutirlo con el resto de la junta.

No tardaron más de tres días en darme una respuesta: Apostaron por definir su Estrategia de Business Intelligence.

En Business Intelligence, reciclar no siempre es bueno

Posted on by Àlex Caminals

 

 

Hoy quiero hablaros de cómo en el mundo del Business Intelligence, es importante tener en cuenta siempre los requerimientos iniciales, y no caer en el error de querer reaprovechar soluciones anteriores que, aunque brillantes en su escenario de partida, pueden llegar a ser desastrosas en un escenario distinto.

 

Una buena solución…

Hace años trabajé para un cliente que necesitaba una integración de datos para un proyecto en uno de sus clientes.

Al empezar el proyecto, les pedí que me hiciesen una descripción del escenario. La descripción fue clara y concisa. Un buen comienzo.

Seguimos con reuniones con las diferentes personas involucradas en el proyecto. Hablé con el jefe de proyecto, con los usuarios, con el departamento de sistemas, etc.

A partir de ahí, diseñé una carga de datos que satisfacía todos los requerimientos de su cliente. Tenía en cuenta tanto los requerimientos funcionales como técnicos, incluyendo los de rendimiento y seguridad.

El proyecto fue todo un éxito.

… no lo será para todos los posibles escenarios

Meses después, mi cliente contactó conmigo de nuevo para ver si podían reutilizar esa carga de datos para otro cliente suyo, con un proyecto, en principio, muy similar.

Mi respuesta inicial fue que la carga de datos posiblemente podía reutilizarse, ya que se trataba del mismo sistema origen y del mismo sistema final, pero matizando que se debían analizar los detalles del nuevo proyecto.

Mi cliente decidió no hacer ese análisis, asumiendo que las diferencias eran mínimas, obviando así los detalles del nuevo proyecto.

Para sorpresa de mi cliente, a medida que se acercaba la fecha de arranque del proyecto, empezaron a aflorar las sorpresas.

Se pasó de un requerimiento de carga diaria, a un requerimiento de carga de datos bajo demanda. Es decir, unas cargas de datos prácticamente en tiempo real. Eso supuso tener que modificar la carga de datos añadiendo una capa previa que pudiese detectar las peticiones de carga de los usuarios en tiempo real.

Una vez la solución estuvo en producción, afloró otro problema. El rendimiento de la carga de datos no era el esperado. El motivo es que los usuarios hacían un uso del sistema inicial de una manera completamente diferente a lo esperado. Por poner un ejemplo, observamos que los usuarios en vez de modificar unos pocos datos, recargaban los datos de todo el año en curso en cada ocasión. De esta manera el sistema debía eliminar todos los datos existentes de ese año y acto seguido, reinsertar todas esas filas que los usuarios habían generado desde el inicio del año. Y esta situación se podía dar simplemente por el hecho de modificar un solo registro de su base de datos. Por tanto, la carga de datos tenía que realizar un gran trabajo para poder hacer lo que en principio debían ser modificaciones simples, rápidas y eficientes durante las cargas de datos. Esto supuso la necesidad de crear una carga de datos totalmente diferente y adaptada a los nuevos requerimientos del sistema.

En este caso la reutilización del código fue un error. De hecho el error vino dado por no tener en cuenta los requerimientos iniciales de este segundo proyecto.

Conclusión

Al cambiar el escenario inicial, debemos plantearnos si la reutilización de una solución es correcta o no. Y para hacer esto es necesario realizar un análisis inicial.

Si asumimos que los escenarios son idénticos o que sus diferencias son mínimas, estaremos corriendo un riesgo que puede acabar en un sobrecoste para el proyecto.

Mi cliente aprendió la lección. Cuándo tuvieron que desplegar esa carga de datos en un tercer cliente, lo primero que hicieron fue tener reuniones con este cliente, para ver como utilizaban el sistema e identificar sus particularidades.

En ese caso, sí que acabaron reciclando o reutilizando una de las cargas de datos existentes. Y con éxito.

¿Porqué conformarse con la mediocridad?

Posted on by Àlex Caminals

 

 

«Estoy hundiendo a mi organización en la miseria y no pienso hacer nada para remediarlo.»

Cargo Directivo de una organización cualquiera

 

Esta afirmación no ha sido citada textualmente por ningún directivo con quien haya hablado nunca. Sin embargo, en muchas de estas conversaciones, el mensaje que se podía extraer era exactamente éste.

Anclados en el pasado

Una gran mayoría de las organizaciones siguen ancladas en el pasado y en procesos de obtención de información arcaicos, lentos e ineficientes. Y esto se traduce en una pérdida de oportunidades.

Esta pérdida de oportunidades se transforma en una toma de decisiones con una alta probabilidad de ser de mala calidad. Cuando una persona no dispone de toda la información necesaria, el riesgo de tomar una mala decisión aumenta considerablemente. Y esto es precisamente lo que sucede cuando los trabajadores de una organización no disponen de la información necesaria en el momento adecuado.

Podemos llegar a pensar que estas decisiones tan solo se toman a nivel estratégico (alta dirección) o táctico (jefes de equipo), pero la realidad es que afectan a todos los niveles de las organizaciones, incluyendo el operacional (el nivel más bajo de una organización). Por tanto, no estar correctamente informado aumenta el número de malas decisiones en todas las posiciones de una organización.

La inacción en la introducción de Business Intelligence (BI) y Analytics en los procesos de obtención de información en una organización es un lastre que acaba por afectar a los resultados de ésta.

Buscando excusas

¿Porqué muchos altos cargos de estas organizaciones no deciden apostar por estos cambios?

La respuesta a esta pregunta es compleja y depende de cada organización, ya que los motivos por los cuales las organizaciones están ancladas en el pasado pueden ser diversas. Una causa de esta inacción es la falta de conocimiento por parte de los responsables de las organizaciones de la existencia de un más allá en la toma de decisiones.  En otros casos el problema radica en la falta de herramientas y presupuesto para empezar un proyecto como éste.

En mi opinión, tener el conocimiento de la necesidad y no iniciar un proyecto de BI y Analytics es como ver venir el precipicio y no pisar el freno. Podemos intentar justificar que no lo hagamos, pero todo serán meras excusas. Es un escenario que encaja perfectamente con la cita inicial de este artículo.

Primera decisión inteligente: Acudir a un experto

Si no sabes como iniciar un proyecto de BI, busca a alguien con experiencia y que te dé confianza.

El grupo de consultores expertos de StraBIA cuenta con una amplia experiencia en el mundo del Business Intelligence. Esto nos permite transformar la mentalidad de las organizaciones a partir de la evangelización del BI, cuando hay una resistencia por parte de los empleados. Además, te ayudamos a definir la estrategia de BI que se adapte a tus necesidades de información, y te acompañamos durante la ejecución de los proyectos marcados en la hoja de ruta definida.

En StraBIA ayudamos a las organizaciones a superar esas barreras que hacen que se vean ancladas en el pasado, con un modelo de toma de decisiones arcaico e ineficiente.

Si deseas más información, no dudes en contactar con nosotros.

5 razones por las que necesitas una auditoría de tu sistema de BI

Posted on by Àlex Caminals

 

El éxito de un proyecto de Business Intelligence (BI) suele medirse en función de las funcionalidades del sistema. Si el producto final cumple los requerimientos funcionales y técnicos, el proyecto es un éxito. Sin embargo, el éxito real de un proyecto dista bastante de esto.

En este artículo, puedes encontrar los 5 factores más importantes que considero que un sistema debe cumplir aparte del cumplimiento obligado de los requerimientos funcionales y técnicos del proyecto, para ser considerado un éxito.

1. Grado de implantación del sistema BI actual y de satisfacción del usuario final

Un proyecto cuyo uso esté por debajo de unos mínimos concretos no puede considerarse un éxito. Por tanto, hay que plantearse preguntas cómo:

  • Cuántos usuarios utilizan el sistema de BI para la toma de decisiones inteligente?
  • Cuántas decisiones toman los usuarios ahora que no podían tomar con anterioridad a la implantación del sistema?
  • Qué impacto económico tienen esas decisiones?

Si los usuarios mayoritariamente no usan el sistema, lo usan a medias o no están contentos con las funcionalidades de éste, ya podemos haber creado una solución que cumpla el 100% de las especificaciones iniciales, que el proyecto no puede ser considerado un éxito.

Una auditoría permite tener visibilidad de estos indicadores de uso y satisfacción de los usuarios.

2. Uso de mejores prácticas para la facilitación del mantenimiento

Cuando se entrega el proyecto estamos tan solo en el principio de la vida de éste. En ese punto empieza una etapa en la que necesitaremos evolucionar la solución inicial. Ese mantenimiento puede ser de dos tipos:

  • Evolutivo: Se añaden nuevas funcionalidades a la solución inicial debido a nuevas necesidades de los usuarios.
  • Correctivo: Se corrigen incidencias detectadas en la versión actual.

Sea cual sea el motivo de este mantenimiento, un objetivo es que el coste de modificar el sistema sea bajo. Y esto tiene una especial relevancia en el caso del mantenimiento correctivo, ya que los usuarios no pueden utilizar ciertas funcionalidades del sistema que deberían estar disponibles.

El uso de mejores prácticas y estándares de BI en el diseño y desarrollo de la solución, facilitará la comprensión de ésta por parte del equipo de mantenimiento, reduciendo el tiempo dedicado a generar una nueva versión. Esta reducción de tiempo tiene una serie de implicaciones:

  • Aumento de la aceptación del trabajo realizado por el equipo de mantenimiento por parte de los usuarios.
  • Reducción de costes.
  • Disminución de la frustración del equipo al no encontrarse con un diseño y un código difícil de entender.

Una auditoría permite identificar el uso de mejores prácticas y estándares de BI en el desarrollo de una aplicación. De hecho, una auditoría en una fase inicial como la de diseño y previa al desarrollo permitiría prevenir situaciones no deseadas de antemano.

3. Optimización de recursos del sistema que aseguren un mínimo TCO

En un post anterior titulado «Calidad en un sistema de BI – Un beneficio para todos«, ya os hablé de la efectividad como uso inteligente de los recursos para obtener el máximo rendimiento de los componentes del sistema.

Mi experiencia me dice que este concepto es a menudo obviado en los proyectos, que basan el éxito en términos de rendimiento en el sobredimensionamiento del hardware. Si bien es cierto que esta estrategia es efectiva, no es la que más interesa al cliente, ya que éste estará incrementando sus costes cuando hay otras alternativas para obtener un buen rendimiento.

Pongamos como ejemplo la transferencia de datos entre dos sistemas informáticos situados en dos ciudades distintas. Si el consumo de datos debe realizarse una vez al día (e.g. carga de datos nocturna), el volúmen no excede los 100 MB y hay la opción de transferir los datos mediante un FTP a través de una red pública de datos como Internet, es realmente necesario tener una conexión punto a punto entre los dos sistemas? No hay duda de que hay beneficios con esta opción, pero realmente vale la pena pagar un sobrecoste adicional?

Una auditoría permite analizar los componentes del sistema BI y su uso, para poder detectar sobredimensionamientos e infrautilizaciones de éstos que podrían significar un aumento indeseado del TCO.

4. Revisión de documentación técnica y de usuario

Partamos de la base de que hay cierta documentación. Cualquier proyecto sin documentación no debería ser aceptado.

La documentación es el legado que el equipo de trabajo que ha desarrollado una solución de BI deja al equipo de mantenimiento y a los usuarios. Si la calidad de la documentación es pobre o poco detallada, es solo cuestión de tiempo para que los problemas empiecen a surgir.

El equipo de mantenimiento necesita no solo tener acceso a la documentación sino a los motivos que llevaron al equipo de proyecto a tomar ciertas decisiones. Si ese conocimiento no está documentando, el equipo de mantenimiento posiblemente no entienda porqué las cosas se hicieron de una manera concreta, a priori mejor que la utilizada, en su momento. Y esto puede suponer avanzar por un callejón sin salida para finalmente ver el motivo por el cual algo se hizo en su día de una manera concreta, con la pérdida de tiempo que ello supone.

Por su parte, tanto el equipo de soporte como los mismos usuarios, se enfrentarán a dudas frente a una nueva solución. Y es obvio pensar que buscarán en la documentación la respuesta a estas dudas. Por tanto, la documentación de usuario debería estar escrita pensando en esas dudas, basándose en el perfil del lector (el usuario) y su capacidad de comprensión y asimilación. El lenguaje utilizado por personas técnicas y de negocio suele ser diferente, el nivel de detalle requerido para poder comprender ciertos conceptos, también. Si no se tienen en cuenta estos conceptos, la documentación puede llegar a ser críptica para los usuarios.

Una auditoría permite identificar situaciones en las que la documentación no aporta información útil al equipo de mantenimiento, carece de información clave y no se adapta al perfil del lector.

5. Valoración independiente del trabajo realizado por el equipo de BI

Uno de los mayores riesgos a la hora de realizar un proyecto informático, es el exceso de confianza. El hecho de tener un diseñador experto no implica que sus decisiones vayan a ser las más apropiadas. Hasta los más grandes genios se equivocan. Por tanto, porqué correr ese riesgo dejando toda la responsabilidad del diseño de un componente a una sola persona? La respuesta está en la reducción de costes para el implementador de la solución. Sin embargo, un fallo en el diseño puede tener grandes implicaciones a nivel de costes en el futuro (e.g. aumento de costes en el mantenimiento evolutivo).

Mi recomendación es que, especialmente en la fase de diseño, las decisiones deberían ir acompañadas de una lista de alternativas y un análisis de puntos a favor y en contra (por obvias que sean), para poder decidir de manera objetiva qué interesa más al proyecto. Este análisis nos permitirá ver opciones que de otro modo quedarían escondidas y que podrían aportar nuevas ideas y mejoras a una solución única.

Una auditoría independiente y libre de intereses permite analizar los requerimientos y la solución propuesta, identificando alternativas y planteando preguntas cuyas respuestas no estén documentadas, para así poder enriquecer el diseño de la solución final, cosa que revertirá en beneficios a medio y largo plazo.

Conclusión

Además de las funcionalidades del sistema y el cumplimiento de los requerimientos, existen otros factores que son decisivos a la hora de evaluar el éxito de un proyecto y que suelen pasar desapercibidos por la presión para cerrar y entregar los proyectos.

Una auditoría del sistema BI permite comprobar el grado de cumplimiento de estos factores, para asegurar el éxito del proyecto antes de darlo por concluido.

Si consideras que estos puntos son importantes y que tu solución de BI actual podría no tenerlos en cuenta, o si estás pensando en implementar o estás implementando en estos momentos una solución de BI y necesitas un experto que audite el trabajo realizado por el equipo de proyecto antes de que sea demasiado tarde, contacta conmigo para pedir una auditoría de tu sistema BI.