Un solo registro, no cinco sistemas

La primera tarea de la lista del artículo anterior era mantener un único registro de cada condición comercial. Su línea de ejemplo era una prueba sencilla: cuando un precio cambia a las 9:00, todos los que hacen un presupuesto, emiten una factura o pagan un rappel sobre ese precio verían la misma cifra a las 9:05, sin que nadie tuviera que reenviar un fichero.

Muy pocos fabricantes o distribuidores medianos superan hoy esa prueba, y la mayoría lo sabe. Haga una pregunta sencilla como «¿cuánto paga este cliente por este producto?» y la respuesta depende de a quién se lo pregunte. Ventas mira el fichero de precios. Atención al cliente mira el ERP. Finanzas mira el informe, que incluye los repartos de rappels, y quien negoció el último acuerdo se pone a buscar en su correo. Cada uno vuelve con lo que cree que es la respuesta, pero a menudo las respuestas no coinciden.

Este artículo trata de por qué ocurre y de qué hace falta para arreglarlo.

Dónde está hoy el registro

En la mayoría de las empresas con las que trabajamos, las condiciones comerciales están repartidas en unos cinco sitios.

1. El ERP (que a menudo se considera el sistema de referencia para los precios) guarda el precio que se factura, junto con la estructura de descuentos que alguien consiguió configurar cuando se implantó el sistema.
2. Una carpeta compartida guarda los ficheros de precios: precios de tarifa, hojas de precios por cliente y la hoja de cálculo «maestra» que contiene la lógica de fijación de precios.
3. Los contratos y los acuerdos de precio especial están en PDF, a veces en un CRM o una herramienta de contratos, a menudo en una carpeta con el nombre del cliente.
4. Las condiciones de rappels e incentivos viven en una hoja de cálculo de finanzas o contabilidad, porque ahí es donde se calculan las provisiones.
5. Las excepciones (aprobaciones puntuales, el correo de «iguala al competidor en esta obra», los portes que no se cobran a un buen cliente) viven en buzones de correo y conversaciones de chat.

Cada uno de estos sitios lo montó un equipo distinto con un propósito distinto, y cada uno hace razonablemente bien su propio trabajo. El problema es que ninguno está obligado a coincidir con los demás, y nada comprueba si coinciden. Cinco perspectivas distintas sobre el precio, que normalmente no coinciden ni cuentan la misma historia.

Cómo se separan cinco registros

La desviación rara vez es espectacular. Se va acumulando a través de huecos corrientes de los que nadie es responsable.

Los plazos son lo más habitual. Una actualización del precio de tarifa entra en vigor el día 1 del mes en el fichero de precios y el día 5 en el ERP, cuando alguien encuentra el momento de cargarla. El contrato que prometía mantener los precios hasta final de año puede que nunca se entere. Durante unas semanas, o de forma indefinida, la empresa tiene más de un precio válido para el mismo artículo.

Los identificadores vienen después. El ERP conoce al cliente por un número de cuenta de facturación, el contrato nombra a la empresa matriz y la hoja de rappels agrupa a los clientes por central de compras. El acuerdo de precio especial de un proveedor recoge la referencia del proveedor, que hay que asignar a su propio SKU antes de poder cruzar nada.

Las unidades de medida añaden otra capa. Un contrato con precio por caja y una factura por unidad parecen un descuento del 90 % hasta que alguien se da cuenta, y muchos informes se construyen antes de que nadie lo haga.

Luego están las condiciones que solo existen en un sitio. El precio especial financiado por el proveedor es un buen ejemplo en distribución. La factura muestra una venta a coste o por debajo, y el apoyo que hace rentable la línea llega más tarde como una reclamación al proveedor, registrada en otro lugar. En un proyecto reciente, las líneas de factura del ERP vendidas bajo acuerdos con proveedores mostraban un margen bruto negativo en los datos de facturación. Una vez que el apoyo del proveedor (rappels de SPA) se asignó a cada cliente y SKU, esas mismas líneas tenían un margen pocket superior al 11 %. Nadie se había equivocado; el precio no estaba «mal». Las dos mitades de cada operación estaban registradas en sistemas distintos, y nada las unía.

Ese ejemplo merece una segunda mirada, porque el coste de la desviación va en las dos direcciones. Los registros desconectados ocultan fugas, que es lo que la mayoría espera. También pueden hacer que un negocio sano parezca no rentable, y eso lleva a la conversación equivocada con el cliente equivocado. Las dos cosas son malas.

Qué exige de verdad un registro único

«Un solo registro» puede sonar a llamada para sustituir el ERP, y esa preocupación es una de las razones por las que muchas empresas nunca empiezan. No se preocupe, su director de sistemas puede respirar tranquilo: no hace falta sustituir el ERP. El ERP sigue facturando, y los contratos se siguen firmando en la herramienta que prefieran el departamento jurídico o Sales Ops. El cambio es que cada condición comercial se define una sola vez, en un único lugar gobernado, con una fecha de entrada en vigor y alguien que responde de ella. Todos los demás sistemas o bien leen de ese registro o bien se concilian con él.

En la práctica, se reduce a unos cuantos trabajos poco vistosos.

Clientes, productos y proveedores se asignan una sola vez, incluida la relación de la cuenta de facturación con la matriz, la pertenencia a centrales de compras, la referencia del proveedor con su SKU y las conversiones de unidades de medida. Así, todos los cruces posteriores usan las mismas claves en lugar de que cada analista las reconstruya.

Cada condición lleva una fecha de inicio y una fecha de fin, de modo que «¿cuál era el precio de este cliente el 3 de marzo?» tiene exactamente una respuesta, y un acuerdo que debía vencer vence de verdad.

Cada tipo de condición tiene un responsable con nombre autorizado a cambiarla, y cada cambio deja constancia de quién lo hizo, cuándo y por qué.

Las transacciones remiten a las condiciones que fijaron su precio, de modo que una línea de factura puede decirle qué precio y qué acuerdo o programa de rappels se le aplicó.

Es la parte de un proyecto de pricing que más tarda y la que menos tiempo ocupa en una demo, y por eso tan a menudo se le asigna menos alcance del que necesita. También es la parte que decide si todo lo que se construye encima es fiable.

Por qué tiene que ir primero

Todas las demás tareas del artículo anterior leen de este registro. El análisis de fugas de margen necesita la línea de factura vinculada al rappel y al acuerdo que hay detrás, o el margen pocket es simplemente erróneo. Dimensionar un cambio de costes exige saber qué clientes tienen protección de precio y hasta cuándo. Una recomendación es tan buena como las condiciones sobre las que se construyó, y una pista de auditoría solo puede remontarse a un registro que exista.

Las empresas que se saltan este paso y van directamente a la analítica acaban reconstruyendo el cruce a mano cada vez que surge una pregunta nueva. Es otra vez el problema de las hojas de cálculo, con una interfaz más bonita.

Por dónde empezar mañana

Puede medir en una tarde lo lejos que están sus registros unos de otros. Saque diez líneas de factura del mes pasado, de clientes distintos, e incluya al menos un par vendidas bajo (o con) un acuerdo especial o un programa de rappels. Para cada línea, anote el precio según el ERP, según el fichero de precios vigente, según el contrato o acuerdo, y las condiciones de rappel que deberían aplicarse. Después, apunte dónde no coinciden y qué fuente resultó ser la correcta.

Es habitual encontrar unas cuantas líneas en las que las fuentes no coinciden y nadie puede decir con seguridad cuál es la correcta. Esa lista corta es una forma sólida de abrir la conversación con finanzas y sistemas sobre dónde debe estar el registro y quién debe ser responsable de cada parte. También le da una referencia con la que medir una vez que empiece el trabajo.

En el próximo artículo de la serie: encontrar la fuga de margen antes de que el cierre trimestral la encuentre por usted.

En Revomo, este registro vive en Data & Context Studio, que forma parte de todas las suscripciones. Si hace la prueba de las diez líneas y quiere ayuda para interpretar los resultados, estaremos encantados de comparar notas. El primer vistazo corre de nuestra cuenta.