Casi todos los modelos de costes empiezan en una hoja de cálculo, y ese es el sitio correcto para empezar. Es en la hoja de cálculo donde se descubre si la idea funciona siquiera, antes de que nadie haya comprado nada. El problema no es haber empezado ahí. El problema es seguir ahí tres años después, ya con once ficheros enlazados entre sí, y una sola persona del equipo financiero siendo la razón por la que aquello todavía se ejecuta.
¿Cómo se pasa de hojas de cálculo a un modelo de costes de verdad?
Migre la lógica, no el fichero. Empiece por escribir qué hace realmente la hoja de cálculo: qué costes recoge, cómo los reparte y qué supuestos están incrustados dentro de las fórmulas. Después reconstruya esa lógica donde viven los datos, de modo que agrupaciones de coste, inductores y capacidad queden guardados como registros estructurados y no como referencias a celdas. Mantenga la hoja funcionando en paralelo durante un período completo y concilie ambos resultados, línea a línea, antes de pasar el reporte de nadie al modelo nuevo.
Cuándo la hoja de cálculo deja de ser la herramienta adecuada
Las hojas de cálculo no fallan de golpe. Se degradan, y los síntomas son reconocibles mucho antes de que alguien los llame problema. El cierre de mes pasa a durar un día en lugar de una hora. Nadie puede decir con seguridad de dónde salió determinado porcentaje de imputación ni cuándo se revisó por última vez. Una pregunta como “qué pasaría si moviéramos este producto a la otra línea” no se responde sin romper algo.
La señal más clara es distinta de todas estas y conviene vigilarla: el modelo ya no se puede traspasar. Cuando la única forma segura de explicarlo es sentarse al lado de quien lo construyó, la organización no es dueña del modelo. Lo es un empleado. Eso es un problema de continuidad del negocio disfrazado de problema financiero, y suele ser lo que acaba forzando el cambio.
Qué es, en realidad, “un modelo de costes de verdad”
La expresión es lo bastante vaga como para venderse mal, así que conviene ser preciso. Un modelo de costes de verdad tiene cuatro propiedades que una hoja de cálculo casi nunca tiene, y ninguna de ellas tiene que ver con el software.
Los inputs están separados de la lógica. Costes, volúmenes y tiempos entran como datos y no como números escritos en la misma celda que una fórmula. La lógica es explícita y tiene nombre. Existe una lista definida de agrupaciones de coste, una lista definida de actividades y un inductor declarado que une cada una de ellas, en lugar de un porcentaje enterrado en un SI anidado. El resultado es trazable en ambos sentidos. Puede partir del coste de un cliente y llegar hasta la línea del mayor que lo originó, y partir de una línea del mayor y ver dónde acabó. Y el modelo tiene versión. Puede decir qué cambió entre marzo y abril y quién lo cambió.
La migración, en el orden que funciona
Empiece por documentar la hoja de cálculo en lugar de sustituirla. Ábrala y escriba, en lenguaje corriente, todos los puntos donde se tomó un juicio: cada porcentaje de imputación, cada tasa, cada excepción que alguien añadió para un producto y nunca retiró. Este paso es tedioso y es el que decide si el proyecto sale bien. La mayoría de los modelos en hoja de cálculo contienen media docena de decisiones que nadie de los que hoy están en la empresa recuerda haber tomado.
Después corrija la estructura de costes antes de tocar ningún sistema. Decida cuáles son las agrupaciones de coste, qué trabajo ejecuta de verdad la organización y qué hace variar cada agrupación. Si no consigue describir la imputación en una frase que un director de departamento acepte, pasarla a una base de datos solo hace más difícil discutirla. La lógica mala dentro de un modelo formal es peor que la lógica mala en una hoja de cálculo, porque pasa a parecer autorizada.
Solo entonces se decide dónde debe vivir el modelo. El requisito no tiene nada de glamuroso: tiene que traer sus inputs de los sistemas que ya los tienen, recalcular sin montaje manual, y permitir que alguien que no lo construyó cambie un supuesto y vea el efecto. La capacidad merece atención especial. Los modelos en hoja de cálculo empujan casi siempre todos los costes hacia la producción, lo que significa que la capacidad no utilizada acaba imputada a lo que por casualidad se produjo. Un modelo al que vale la pena migrar mantiene la capacidad no utilizada visible como número propio.
Un modelo que solo su autor sabe ejecutar no es un activo, es una dependencia.
Ejecutar los dos y después parar
Concilie un período completo en la hoja de cálculo y en el modelo nuevo, y explique cada diferencia antes de aceptarla. Algunas diferencias serán errores del modelo nuevo. Otras serán errores de la hoja de cálculo que nunca estuvieron visibles, y son esas las que construyen confianza, siempre que pueda mostrar por qué la respuesta nueva es la correcta.
Después desactive de verdad la hoja de cálculo. Dos modelos funcionando en paralelo indefinidamente es lo peor de los dos mundos: el doble de esfuerzo y un argumento siempre disponible para quien no le guste un número. Fije una fecha, acuerde cuál es el modelo de referencia y archive el fichero en lugar de dejarlo abierto en una carpeta compartida. El objetivo de la migración nunca fue la tecnología. Fue convertir el coste del trabajo en algo que la empresa pueda cuestionar, cambiar y usar sin depender de una sola persona en la sala.
La demostración de CostCTRL muestra un modelo por tiempo en funcionamiento, con agrupaciones de coste, inductores y capacidad en directo, para ver cómo se comporta la misma lógica una vez fuera de una hoja de cálculo.
Lectura relacionada: los datos necesarios para un modelo TDABC, costeo por actividad basado en el tiempo y software de costeo ABC.