Generando confianza con el cliente

 

 

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

 

 

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?

 

 

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

 

 

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.