Los proyectos de costes basados en actividades rara vez encallan en el método. Encallan en la tercera semana, cuando alguien pregunta qué datos va a necesitar el modelo y la respuesta llega en forma de una lista lo bastante larga como para justificar aplazarlo todo al año siguiente. Esa lista está casi siempre equivocada. Un primer modelo ABC necesita mucho menos de lo que cree quien la está elaborando, y prácticamente todo se encuentra ya en sistemas que la empresa utiliza cada día.
¿Qué datos hacen falta para empezar un modelo ABC?
Cuatro entradas. El mayor de costes de un período ya cerrado, una lista de las actividades que los equipos ejecutan realmente, una medida del tiempo o de la capacidad que consume cada actividad, y los volúmenes de los productos, servicios o clientes que quiere costear. La primera y la cuarta ya existen en su ERP y en su sistema de facturación. La segunda y la tercera vienen de sus propios responsables, no de software nuevo. Un primer modelo no exige un proyecto informático.
Empiece por el coste que ya reporta
El cálculo de costes por actividades no crea coste. Reencamina un coste que ya ha sido reconocido, de modo que el punto de partida es el mayor de un período cerrado, con el nivel de cuenta y de centro de coste que su ERP ya produce hoy. Resista la tentación de encargar una extracción especial. Si el equipo financiero tiene que construir algo nuevo antes de que el modelo pueda arrancar, el modelo ha adquirido una dependencia que no necesitaba y un retraso que no va a recuperar.
La única restricción que importa de verdad es la conciliación. Todo lo que el modelo asigne tiene que sumar de vuelta al mismo total que las cuentas reportan para ese período, hasta el céntimo. Un modelo que no cuadra con las cifras publicadas será discutido en lugar de utilizado, y todas las discusiones pasarán a ser sobre el cuadre en vez de sobre la decisión que el modelo se construyó para apoyar.
Las cuatro entradas, y dónde vive ya cada una
La primera entrada es el coste por cuenta y centro de coste, directamente del ERP. La segunda es la lista de las actividades que ejecuta cada departamento, y se obtiene en una sesión corta con quien hace el trabajo, no a partir de un sistema. La tercera es cuánto tiempo o capacidad consume cada actividad, construida a partir de plantilla, planes de turnos, horas-máquina y estimaciones de los responsables. La cuarta es el volumen por objeto de coste: pedidos, líneas, entregas, avisos de servicio, pacientes o tickets, tomados de la facturación, del CRM o del sistema de almacén.
Fíjese en cuáles son las dos que generan temor. Las entradas dos y tres son las que provocan la duda, y son exactamente las dos que nunca salen de un sistema, en ninguna empresa y con ningún grado de madurez. Esperar a que aparezcan en una base de datos es esperar algo que no ocurre.
El tiempo estimado también es dato. La precisión no es la restricción.
La variante orientada al tiempo del cálculo de costes por actividades, publicada por Robert Kaplan y Steven Anderson en 2004, se diseñó precisamente en torno a este problema: las estimaciones son entradas aceptables, siempre que se verifiquen. Un responsable que dice que preparar una línea de pedido lleva unos noventa segundos le ha dado una cifra utilizable, porque noventa segundos multiplicados por el volumen de líneas pueden contrastarse con las horas que el departamento trabajó realmente. El valor está en la verificación. Una estimación que la supera es evidencia; una estimación que falla acaba de indicarle dónde está equivocado el modelo.
El error caro va en sentido contrario: encargar un estudio de tiempos y métodos antes de que exista un primer modelo. Eso convierte un ejercicio de cuatro semanas en uno de seis meses y produce precisión sobre actividades que quizá consuman el dos por ciento de la base de costes. Construya el modelo aproximado, mire dónde se concentra el dinero, y gaste esfuerzo de medición solo ahí.
Qué detiene de verdad estos proyectos, y no es la calidad de los datos
Hay dos cosas que los detienen, y ninguna aparece en la lista de datos. La primera es que nadie ha decidido qué se está costeando. Si no se ha fijado si el modelo va a producir rentabilidad por producto, por cliente, por canal o por los tres, cualquier petición de datos parece no tener límite, porque genuinamente no lo tiene. Fije primero el objeto de coste y el requisito de datos se reduce a algo que una sola persona puede reunir.
La segunda es que la lista de actividades no tiene dueño y se desborda. Entre veinte y cuarenta actividades bastan para sostener un primer modelo en la mayoría de las organizaciones medianas. Una lista que llega a doscientas es señal de que la sesión bajó del nivel de actividad al nivel de tarea, y el detalle adicional no compra nada salvo una carga de mantenimiento que garantiza que el modelo nunca se actualizará. Para ver la forma que toma esto en la práctica, una lectura de coste de servir suele ser el primer corte más limpio.
La pregunta nunca es si sus datos son lo bastante buenos para modelar. Es si su asignación sería mejor que la media que está usando hoy.
Una prueba de una tarde antes de comprometerse
Elija un mes ya cerrado. Extraiga el mayor por cuenta y centro de coste. Extraiga los volúmenes del mismo mes por el objeto de coste que haya elegido. Pida a dos directores de departamento que enumeren qué hacen sus equipos y qué porcentaje de la semana ocupa aproximadamente cada actividad. Si consigue reunir esas cuatro cosas en una tarde, tiene lo suficiente para un modelo piloto y la discusión sobre la preparación de los datos queda cerrada.
Si no logra producir volúmenes por objeto de coste, ha encontrado la laguna real, y merece la pena nombrarla con precisión: es una laguna de reporte, no de costes. Bloqueará cualquier análisis de rentabilidad que intente hacer, esté basado en actividades o no, y suele resolverse en el sistema de origen en días y no en meses. Todo lo demás de la lista de deseos habitual de datos para el cálculo de costes por actividades puede esperar a la versión dos.
Nuestro taller práctico de TDABC le lleva de una extracción del mayor a un primer modelo de rentabilidad, usando las cuatro entradas de arriba y nada más.