Por qué el ERP oculta la rentabilidad real
Su ERP reporta el ingreso de cada cliente y el costo de la mercadería que compró, y se detiene ahí, en la línea del margen bruto. Todo lo que hace que un cliente sea más caro de atender que otro, la preparación de pedidos, las órdenes pequeñas y urgentes, los pedidos especiales, las devoluciones, las llamadas de soporte, queda en los gastos generales y se reparte por igual entre todos. Por eso un estado de resultados de aspecto sano puede ocultar, en silencio, relaciones que pierden dinero en cada pedido.
El ERP fue hecho para registrar transacciones, no para atribuir el costo de servir. Reporta con precisión el ingreso y el costo de la mercadería por cliente, y luego se detiene. El costo operativo que cambia de cliente a cliente queda dentro de los gastos generales y se asigna con una regla gruesa, como un porcentaje sobre las ventas. Por eso dos clientes con el mismo margen bruto parecen idénticos, aunque uno cueste tres veces más de atender. Un modelo de costo de servir, apoyado en el TDABC, se sienta encima del ERP y revela la rentabilidad real por cliente, producto y canal.
Lo que el ERP muestra bien
No hay nada malo en su ERP dentro de lo que se propone hacer. Como sistema de registro, es preciso y confiable en estos puntos:
- Ingreso por cliente, producto y pedido: quién compró qué, cuándo y por cuánto.
- Costo de la mercadería vendida: lo que usted pagó por lo que revendió o produjo.
- Margen bruto por línea: lo que queda después del costo del producto.
- Volúmenes, precios y descuentos: el historial comercial completo, transacción por transacción.
El problema no es la exactitud de esos números. El problema es que responden una pregunta distinta de la que la gestión necesita hacer: qué vendimos, y no cuánto nos costó servir.
Lo que reparte y oculta
El costo de servir a cada cliente es justamente lo que desaparece dentro de los gastos generales. Ahí es donde la rentabilidad real se esconde:
- Tiempo de preparación y empaque por pedido: cada orden consume atención de bodega y despacho, sin importar su valor.
- El costo verdadero de pedidos pequeños y urgentes: ocupan la misma operación que un pedido grande, por una fracción del ingreso.
- Devoluciones, reprocesos y notas de crédito: logística inversa y retrabajo que nadie contabiliza por cliente.
- Soporte, gestión de cuenta y pedidos especiales: horas de equipo que los clientes exigentes consumen mucho más que otros.
Ninguno de esos costos aparece atribuido a quien realmente los provoca. Todos quedan diluidos, y el cliente caro se vuelve invisible.
La trampa de la asignación de gastos generales
El ERP tiene que poner los gastos generales en algún lugar, así que usa una regla simple: los reparte como porcentaje de las ventas, o por unidad, o por línea de pedido. Esa regla es fácil de ejecutar y casi siempre está equivocada. Supone que un pedido grande y planificado y uno minúsculo y urgente consumen la operación en proporción a su ingreso. No lo hacen.
El pedido pequeño amarra la misma preparación, la misma verificación y el mismo despacho, a veces más, por una fracción del valor. Cuando usted promedia ese costo entre todos, hace dos cosas al mismo tiempo: cobra de más a los clientes eficientes y subsidia a los clientes caros, todo mientras el reporte parece perfectamente razonable. Es la asignación gruesa la que borra la diferencia entre quien da utilidad y quien la destruye.
Cómo el TDABC revela el margen oculto
La forma de sacar ese costo a la luz es el costeo basado en el tiempo (TDABC, Time-Driven Activity-Based Costing). En lugar de asignar gastos por porcentajes arbitrarios, el TDABC mide cuánto tiempo consume cada actividad y cuánto cuesta un minuto de capacidad. Así, cada pedido, cada visita y cada devolución reciben un costo realista según el tiempo que de verdad exigen, y la capacidad ociosa, aquello que usted paga pero no usa, aparece por separado.
Un modelo de costo de servir no reemplaza al ERP y no exige cambiar de sistema. Se sienta encima: toma el ingreso y el costo de la mercadería que el ERP ya registra, agrega los datos de actividad y tiempo que el ERP nunca guardó, y atribuye el costo operativo a los clientes y productos que en realidad lo causaron. Cuando usted ordena a los clientes por utilidad acumulada, aparece la curva de la ballena: las cuentas rentables suben sobre la línea y un grupo de clientes más pequeños cae por debajo, hacia la pérdida. Es el dibujo que el ERP no puede trazar.
Ejemplo ilustrativo con el dataset CaP
En la distribuidora ilustrativa CaP (datos ficticios), dos clientes facturan casi lo mismo y tienen un margen bruto parecido. En el ERP parecen idénticos: mismo ingreso, mismo costo de mercadería, misma línea de margen bruto.
Cuando se atribuye el costo de servir, la historia cambia. El primero hace pedidos grandes y planificados, con pocas devoluciones, y sigue siendo rentable. El segundo hace pedidos pequeños y urgentes, exige soporte constante y devuelve mercadería con frecuencia, lo suficiente para empujar su rentabilidad al rojo. Ese segundo cliente es exactamente el tipo que aparece en la cola de la curva de la ballena, ayudando a erosionar la utilidad que la cima de la curva había generado. El ERP no estaba equivocado. Solo respondía otra pregunta.
Señales de que su rentabilidad está oculta
Es probable que tenga margen oculto en el ERP si reconoce algunas de estas señales en su día a día:
- Usted gestiona el negocio mirando un solo número de margen, el de toda la empresa.
- Los clientes con ingreso parecido se tratan como igualmente valiosos, sin mirar el costo de atender.
- Los gastos generales se asignan por un porcentaje de las ventas o por línea de pedido.
- Nadie sabe decir, con un número, cuánto cuesta procesar un pedido pequeño y urgente.
- Las devoluciones, los pedidos especiales y las horas de soporte no se atribuyen a clientes específicos.
- El estado de resultados cierra en positivo, pero usted sospecha que algunos clientes grandes dan pérdida.
Cómo avanzar
Usted no necesita cambiar de sistema ni esperar un proyecto largo. El camino es montar un modelo de costo de servir sobre el ERP: exportar del sistema los datos financieros y operativos que ya produce, mapear las actividades de atención (preparación, pedidos, visitas, devoluciones, soporte), medir el tiempo de cada una y atribuir el costo a la cuenta que de verdad lo provocó. El resultado es el mismo estado de resultados, abierto lo suficiente para gestionarlo. A partir de ahí puede fijar un pedido mínimo, cobrar por urgencia, revisar las devoluciones y ajustar los precios al costo real de servir a cada cliente.
Preguntas frecuentes
¿Por qué el ERP no muestra la rentabilidad por cliente?
El ERP fue construido para registrar transacciones, no para atribuir el costo de servir. Reporta con precisión el ingreso y el costo de la mercadería por cliente y luego se detiene. El costo operativo que cambia de cliente a cliente, preparación, pedidos pequeños, pedidos especiales, devoluciones y soporte, queda en los gastos generales y se asigna con una regla gruesa, como un porcentaje sobre las ventas. Por eso dos clientes con el mismo margen bruto parecen idénticos aunque uno cueste tres veces más de atender.
¿Un modelo de costo de servir reemplaza al ERP?
No. Se sienta encima del ERP. El ERP sigue siendo el sistema de registro de las transacciones y del costo de la mercadería. El modelo de costo de servir toma esos datos, agrega la información de actividad y tiempo que el ERP no guarda, y atribuye el costo operativo a los clientes y productos que lo causaron. Los dos son complementarios, no competidores.
¿Con qué sistemas de ERP funciona esto?
Con todos. Trabajamos a partir de las exportaciones que su sistema ya produce, sean de ERP, WMS, CRM o de cualquier base de datos financieros y operativos. El modelo no se conecta ni depende de un ERP en particular, y por eso puede construirse rápido y actualizarse desde extractos mensuales.
¿No basta el margen bruto para gestionar la rentabilidad?
El margen bruto dice que el producto se vendió por encima del costo de la mercadería. No dice nada sobre cuán caro es atender a ese cliente. Un cliente con margen bruto sano todavía puede dar pérdida cuando entran a la cuenta los pedidos pequeños frecuentes, las devoluciones y el soporte. Gestionar solo por margen bruto protege, de forma sistemática, justamente las relaciones más caras.