Clientes exigentes: ¿Y si el cliente no tuviese siempre la razón?

Tras unas cuantas implantaciones de sistemas ERP en diversos clientes, me he encontrado con múltiples perfiles de clientes y muchos más de usuarios. Es evidente que en toda relación humana, hemos de disponer de la suficiente empatía para situarnos en la postura y visión de éstos, pero también en no dejarnos atropellar por peticiones demasiado personalistas, y al fin y al cabo, lograr salvar proyectos aunque sea con una escasa rentabilidad.

Los clientes se convierten en clientes exigentes por dos motivos fundamentalmente:

• Por su propia naturaleza. Son muy exigentes en cuanto al producto que se les entrega, pero también intransigentes en cuanto al servicio que dan. No ven al proveedor como un colaborador, sino todo lo contrario.
• Por fracasos anteriores. Su posición es defensiva en todo momento dada la desconfianza y recelo del nuevo sistema.

En todos los casos hay que tener mucho cuidado con conducir al cliente a una posición predominante y que piense que la única forma de «asegurar» el éxito para su organización (en ocasiones prevalece incluso el éxito de las necesidades personales) es con las concesiones del proveedor, sean razonables o no. Es por ello que hay que estar dispuesto a realizar concesiones a los usuarios, pero también a rechazar aquellas que desde nuestro punto de vista puedan alterar profundamente el core del producto o que supongan una desviación de los márgenes importantes.

En ocasiones se suele realizar muchas pequeñas concesiones (o quick wins), lo que de alguna forma te acerca a los usuarios, pero también hay que ser tajante en ciertos cambios de gran calado y que suponen importantes esfuerzos de desarrollo que no se encuentran previstos en el proyecto, sobre todo si no se ha destinado una partida o colchón económico (y de recursos) para este tipo de imprevistos. En cualquier caso no hay que cerrar las puertas a estos cambios, pero sí ofrecer alternativas o incluso la posibilidad de ampliar los requerimientos en el siguiente proyecto y bajo presupuesto. Se trata de «demostrar» al cliente y a los usuarios que no el sistema no está cerrado a los cambios, y de hecho múltiples aportaciones de éstos se recogen en su beneficio, pero aquellas que quedan fuera del alcance del proyecto, deben estar sujetas a revisión, cotización y demora del proyecto. En este aspecto, el cliente por tanto debe tener la percepción de que sus aportaciones y mejoras son recogidas.

Por otra parte, el cliente debe tener clara la percepción de que los defectos graves se priorizan, ofreciendo resolución tanto al propio defecto como a los efectos colaterales (por ejemplo mediante scripts de reconstrucción de datos). En cuanto a los leves, también, pero con fechas de compromiso y resolución. Si los desarrollos son nuevos, pasan a una cola con un compromiso de análisis y aprobación (o rechazo), pero con una fecha más abierta. Si además, se recoge así por contrato, tanto mejor.

Anécdota 1

Recuerdo un caso en el que tras varias reuniones con uno de los usuarios clave (no era reacio, sino recalcitrante al cambio) para analizar uno de los procesos clave, yo proponía una solución que entendía podía satisfacer sus necesidades y que además suponía un esfuerzo importante de desarrollo para nosotros, pero él no lo «veía» claro. El proceso era un proceso de compras de alto nivel, pero su no «visualización» terminó con una frase rotunda suya: ‘Tú desarrolla a ver si me gusta’. Por supuesto no lo hice hasta que no hubo un visto bueno por parte de su jefe de proyecto.

No se porqué, pero hay determinados clientes que poseen la visión de que su tiempo es mucho más importante que el de los demás.

Anécdota 2

Otro caso de alto impacto económico para mi empresa fue el siguiente. Cuando vendemos un ERP, incluimos la personalización de ciertos impresos (pedidos, albaranes, facturas, etiquetado, etc.). Para ello solicitamos siempre un ejemplo de cada uno de los distintos impresos y en base a ellos se hacen lo más parecido posible. Normalmente, estos impresos suelen ser unos 5-6 de media por cliente. Cuando desarrollamos los impresos que nos habían entregado, nos dieron alrededor de 20 más (cada tienda disponía de un formato totalmente distinto, algo que nunca surgió en ningún momento ni conversación). No solamente eso, sino que además el ajuste debía ser «calcado» a su formato anterior, es decir, respetando exactamente las fuentes de letra, sus tamaños, sus estilos, los «cajeados», etc, etc. El cliente superponía el impreso viejo y el nuevo a contraluz para asegurarse que todo cuadraba exactamente. En resumen, solo el ajuste de los impresos multiplicó por 8 el número de horas habituales. Su argumento fue que «distintos impresos» se entiende en el contexto de distintos tipos de documentos y no se concretaban.

Como estos podría contar cientos, donde la exigencia se convierte en una cuestión de orgullo y donde se termina por amenazar con paralizar el proyecto si el proveedor no cede a las pretensiones. También es cierto que el caso contrario también se ha dado, pero no es lo habitual.

(En el Master en Software Libre de Gestión: Open Source & ERP II, estamos analizando situaciones como la que aquí acabamos de mostrar).

Autor: Sergio Martínez

Recibe nuevos artículos mediante suscripción por e-mail, RSS o Feedly

Email