El coste empresarial, antes y ahora
Este es un escenario compuesto elaborado a partir de experiencia real de campo en implantaciones de modelos de coste; los detalles, el sector y las cifras son ilustrativos y no representan a ningún cliente concreto. Durante toda una generación, obtener un modelo de coste empresarial defendible significaba una construcción de varios años sobre una plataforma de gran envergadura, un presupuesto de siete cifras y una dependencia de especialistas escasos que a menudo dejaba el modelo muerto al año de su puesta en marcha. El stack moderno hace el mismo trabajo en días, lo mantiene vivo en manos del propio cliente y hace que cada cifra sea rastreable, y una vez que has visto ambos, el método antiguo resulta difícil de defender.
La era de las plataformas de gran envergadura en el coste empresarial no fue un error para su tiempo; era la única forma de imputar coste a escala antes de que las herramientas maduraran. Pero su economía era despiadada: una gran suite de coste empresarial, una firma consultora global para configurarla, entre dieciocho y treinta y seis meses de construcción y un modelo tan intrincado que solo un puñado de personas llegaba a entenderlo. Cuando esas personas rotaban a otro proyecto, el modelo se calcificaba: exacto el día en que se aprobó, y silenciosamente erróneo cada mes después. El enfoque moderno invierte cada una de esas restricciones. Un pequeño equipo especialista, un motor de costes desarrollado a propósito (CostCtrl) y la IA para acelerar el mapeo y la narrativa entregan un primer modelo funcional en días, no en trimestres, a una fracción del coste anterior, con una estructura que el propio equipo financiero del cliente puede mantener y una traza de auditoría completa detrás de cada euro imputado. La cuestión no es que el software se abaratara. Es que el cálculo de costes dejó de ser un proyecto de construcción y se convirtió en una capacidad viva. Esta página coloca las dos eras una junto a otra, con justicia, y muestra por qué gana la segunda.
Cómo solía construirse el coste empresarial
Imagine un gran operador de infraestructuras intensivo en capital hacia 2019 (un compuesto, no una única organización). El consejo quiere saber lo que cuesta realmente operar cada línea de servicio, activo y segmento de cliente. La respuesta al uso, entonces, era un programa: licenciar una plataforma de gestión de costes empresariales de gran envergadura, contratar a una firma de las grandes para configurarla y montar una oficina de proyecto que dirigiera la construcción. La plataforma era genuinamente potente, podía modelar decenas de miles de objetos y generadores de coste, y esa potencia era exactamente el problema. Cada fortaleza venía con un peso equivalente.
La construcción se desarrollaba a lo largo de trimestres, no de semanas. Talleres de requisitos, un diccionario de generadores, reglas de imputación codificadas por consultores, conciliación contra el libro mayor y después un ciclo de validación que por sí solo podía extenderse durante meses. Cifras representativas de un programa de este tamaño (ilustrativas): entre dieciocho y treinta y seis meses de tiempo transcurrido y un presupuesto bien entrado en las siete cifras una vez contabilizadas licencias, integración de sistemas y esfuerzo interno. Cuando el modelo por fin entraba en producción era, ese día, una pieza de trabajo seria, una respuesta defendible a una pregunta difícil. La dificultad era todo lo que llegaba después del primer día.
Exacto en la puesta en marcha, erróneo al trimestre siguiente
El fracaso rara vez era dramático. Un modelo de coste de gran envergadura no se cae; se desvía. La empresa se reorganiza, se renombra un centro de coste, se lanza un nuevo servicio, se retira un activo, y cada cambio necesita a un especialista para recodificar la lógica de imputación. Como el modelo se construyó para el cliente y no por el cliente, ese especialista solía ser externo, caro y ya no estaba en la casa. Así que los pequeños cambios se acumulaban en cola, los apaños se multiplicaban y, al cabo de un año, el modelo que costó una fortuna construir estaba siendo educadamente ignorado en favor de una hoja de cálculo en la que alguien confiaba. Este es el patrón que un reparto de costes defendible debe terminar, no repetir (véase CostCtrl frente a las hojas de cálculo).
Nada de esto es anecdótico. La longeva investigación CHAOS del Standish Group lleva años mostrando que los grandes programas habilitados por TI son los que tienen más probabilidades de verse comprometidos o de fracasar de plano, con tasas de éxito que caen a medida que aumenta el tamaño del proyecto. El Pulse of the Profession del Project Management Institute ha situado repetidamente en dos dígitos la proporción de presupuesto perdido por un mal desempeño de los proyectos. Y la investigación de analítica de Gartner lleva mucho tiempo informando de que una gran mayoría de los modelos analíticos sofisticados nunca llega a un uso sostenido en producción, no porque el análisis fuera erróneo, sino porque la adopción, la propiedad y el mantenimiento se trataron como una ocurrencia tardía. Un modelo de coste es exactamente esta clase de activo: su valor no está en la puesta en marcha, está en el quincuagésimo mes de uso fiable. El modelo de entrega antiguo optimizaba el lanzamiento y descuidaba la vida útil.
Un equipo especialista, un motor desarrollado a propósito y la IA
La respuesta moderna no es una plataforma más grande. Es una forma distinta de entrega, hecha de tres partes. Primero, un pequeño equipo especialista que vive en el trabajo de coste y rentabilidad y aporta el método en lugar de reinventarlo, el cálculo de costes basado en actividades y orientado por el tiempo bien hecho, de modo que la lógica de los generadores es transparente en lugar de estar enterrada (los cimientos residen en la gestión basada en actividades). Segundo, un motor de costes desarrollado a propósito, CostCtrl, diseñado exactamente para este trabajo: tiene criterio propio sobre cost pools, generadores y capacidad, de modo que la estructura que a una suite de gran envergadura le llevaba meses configurar está en gran parte ahí desde el primer momento. Tercero, la IA para hacer las partes lentas y mecánicas, mapear un plan de cuentas a cost pools, redactar ecuaciones de tiempo a partir de descripciones de procesos, conciliar con el libro mayor y escribir la narrativa de primer borrador que un equipo financiero puede revisar en lugar de redactar.
El efecto acumulado es un primer modelo funcional en días. No un juguete: un modelo que cuadra con el libro mayor, respeta el coste de la capacidad no utilizada (véase coste de la capacidad no utilizada) y produce una visión de rentabilidad sobre la que la dirección puede actuar en el primer taller y no en el cuarto trimestre. Como CostCtrl está desarrollado a propósito y la lógica es explícita, el mismo equipo que vio construir el modelo puede mantenerlo. El especialista configura la primera versión y enseña el patrón; los propios analistas del cliente lo llevan hacia adelante. El cálculo de costes deja de ser algo que se entrega a la empresa y se convierte en algo que la empresa posee.
Las dos eras, una junto a otra
La tabla enfrenta la era de las plataformas de gran envergadura con el stack moderno a lo largo de las dimensiones que de verdad deciden si un modelo de coste se gana su sitio. Las cifras son ilustrativas y representativas de programas de este tipo, no resultados verificados de ningún cliente concreto.
| Dimensión | Antes: era de la plataforma de gran envergadura | Ahora: equipo especialista + CostCtrl + IA |
|---|---|---|
| Tiempo hasta el primer modelo | 18-36 meses de construcción y validación antes de que la dirección vea una visión utilizable (ilustrativo) | Un primer modelo funcional en días; una versión refinada y cuadrada con el libro mayor en semanas (ilustrativo) |
| Coste total | Siete cifras una vez contabilizadas licencias, integración y esfuerzo interno (ilustrativo) | Una fracción del coste anterior, un pequeño encargo de alcance fijo más un motor por suscripción (ilustrativo) |
| Mantenibilidad | Los cambios necesitan a un especialista escaso, normalmente externo; las ediciones pequeñas esperan en cola durante semanas | El propio equipo financiero del cliente mantiene el modelo; los cambios se hacen en el taller, no en una petición de cambio |
| Trazabilidad | Potente pero opaca; lógica de imputación comprendida por un puñado de personas | Cada euro imputado se rastrea a través del generador y el cost pool hasta la línea de origen del libro mayor |
| Riesgo de persona clave | Alto; el modelo vive y muere con especialistas concretos que rotan a otro proyecto tras la puesta en marcha | Bajo; el método es explícito y se enseña, de modo que ninguna persona por sí sola es el modelo |
| Probabilidad de sobrevivir a la puesta en marcha | Baja; a menudo abandonado en silencio en un año a medida que se desactualiza | Alta; diseñado para ser actualizado mensualmente por quienes lo usan |
Recorra hacia abajo la última columna y emerge un patrón: cada ventaja del stack moderno es en realidad la misma ventaja con ropa distinta, la propiedad. Velocidad, coste, mantenibilidad, trazabilidad y supervivencia se derivan todas de un modelo que el cliente puede sostener de verdad. El mundo antiguo externalizaba la comprensión; el mundo nuevo la incorpora.
Lo que la era de gran envergadura hizo bien
Sería un hombre de paja fingir que el enfoque antiguo era una insensatez. Era la respuesta racional a una restricción real. Antes de los motores desarrollados a propósito y de una IA capaz, imputar coste a lo largo de decenas de miles de objetos exigía genuinamente una plataforma industrial y manos especialistas, y las suites de gran envergadura hacían cosas que las herramientas más pequeñas de la época no podían. La disciplina que aquellos programas imponían, un diccionario de generadores, una conciliación formal, una traza de auditoría validada, es exactamente la disciplina que el stack moderno conserva. El propio cálculo de costes basado en actividades y orientado por el tiempo, el método que subyace a todo esto, fue formalizado por Kaplan y Anderson precisamente para domar la complejidad bajo la que colapsó el primer cálculo de costes basado en actividades. El enfoque moderno no rechaza ese linaje; lo hereda y se despoja del peso.
Lo que cambió no es la ambición sino el coste de lograrla. El modelo antiguo pagaba su rigor con tiempo, dinero y fragilidad. El modelo moderno conserva el rigor y deja de pagar esos tres precios, lo cual solo es posible porque el motor está desarrollado a propósito y el trabajo mecánico está automatizado. Cuando una gran suite de coste empresarial es genuinamente la herramienta adecuada, un puñado de los entornos más grandes e idiosincráticos, sigue siéndolo. Para la abrumadora mayoría de las organizaciones que en su día suponían que necesitaban una, ya no la necesitan. La comparación honesta no es «lo viejo malo, lo nuevo bueno»; es «la restricción que justificaba el método antiguo se ha levantado».
Dónde el enfoque moderno todavía puede fallar
La velocidad es una tentación además de una virtud. Un primer modelo en días solo es valioso si las entradas que lo sustentan son reales, y el modo de fallo del nuevo stack es la imagen especular del antiguo: en lugar de sobreconstruir, los equipos subvalidan. Reaparecen algunos escollos. Confundir rápido con terminado: el modelo del primer día es una hipótesis de partida, no una respuesta aprobada, y todavía necesita conciliación con el libro mayor y una comprobación de sensatez frente a cómo se comporta realmente el negocio. Dejar que la IA codifique un generador plausible pero erróneo: un modelo de lenguaje redactará gustosamente una ecuación de tiempo que se lee bien e imputa mal, así que el especialista tiene que hacerse dueño de la lógica, no darle el visto bueno sin más. Saltarse la cuestión de la capacidad: un modelo que ignora la capacidad no utilizada halaga los periodos de mucha actividad y castiga los tranquilos, razón por la cual el coste de la capacidad no utilizada tiene que ser explícito desde el principio.
Hay también una trampa de adopción que el mundo antiguo conocía bien y en la que el mundo nuevo todavía puede caer. Un modelo que el cliente no puede mantener morirá sea lo que sea que lo construyó, de modo que el traspaso no es una fase al final, es el principio de diseño desde el comienzo. Si el equipo especialista se marcha y la función financiera no puede hacer el cambio del mes que viene sin ayuda, el encargo ha fracasado por muy rápido que apareciera el primer modelo. Juzgado del modo correcto, el stack moderno no se mide por el tiempo hasta el primer modelo, sino por si el modelo sigue siendo confiable y vigente un año después. Esa es la misma prueba que la era de gran envergadura tantas veces suspendía, y es la que merece la pena exigir al nuevo enfoque. Es también por lo que el trabajo de rentabilidad debería estar ligado a las métricas que la dirección ya vigila (véase KPI de rentabilidad) y, para los inversores, a los diagnósticos que revelan dónde reside realmente el valor de la cartera (véase diagnósticos de rentabilidad de carteras de capital privado).
Preguntas habituales sobre el coste empresarial, antes y ahora
- ¿Por qué fracasaban los modelos de coste empresarial tradicionales tras la puesta en marcha?
- No por caerse, sino por desviarse. Los modelos de coste de gran envergadura los construían para el cliente especialistas externos, así que cada cambio en el negocio, una reorganización, un nuevo servicio, un activo retirado, necesitaba a uno de esos especialistas para recodificar la lógica de imputación. Tras la puesta en marcha los especialistas rotaban a otro proyecto, los cambios se acumulaban en cola y el modelo divergía gradualmente de la realidad hasta que la gente dejaba de confiar en él. La investigación sobre grandes programas apunta en la misma dirección: los estudios CHAOS del Standish muestran que las grandes construcciones habilitadas por TI son las que más probabilidades tienen de verse comprometidas, y Gartner lleva mucho tiempo informando de que la mayoría de los modelos analíticos nunca llega a un uso sostenido en producción. El valor de un modelo de coste está en su quincuagésimo mes de uso, y el enfoque de entrega antiguo optimizaba el lanzamiento en lugar de la vida útil.
- ¿Cómo puede construirse un modelo de coste creíble en días en lugar de meses?
- Porque las partes lentas se han eliminado, no saltado. Un motor de costes desarrollado a propósito como CostCtrl ya codifica la estructura, cost pools, generadores, capacidad, que a una suite empresarial de propósito general le llevaba meses configurar. La IA se encarga del trabajo mecánico de mapear el plan de cuentas a cost pools, redactar ecuaciones de tiempo a partir de descripciones de procesos y conciliar con el libro mayor. Un equipo especialista aporta el método en lugar de inventarlo. Lo que queda es criterio, que es donde se concentra el esfuerzo humano. El resultado es un primer modelo funcional en días que cuadra con el libro mayor, una hipótesis que refinar, no una auditoría terminada, pero sí una genuina.
- ¿Sigue siendo alguna vez la opción correcta una plataforma de gestión de costes empresariales de gran envergadura?
- Ocasionalmente, sí. Un pequeño número de los entornos más grandes e idiosincráticos tienen necesidades de modelización que justifican genuinamente una plataforma industrial, y donde eso es cierto sigue siendo la herramienta adecuada. Pero para la abrumadora mayoría de las organizaciones que en su día suponían que necesitaban una, la restricción que la justificaba se ha levantado. Un motor desarrollado a propósito más un equipo especialista más la IA entregan ahora el mismo rigor, conciliación, una traza de auditoría, generadores defendibles, sin la construcción de varios años, el presupuesto de siete cifras o la fragilidad. La prueba honesta es si el peso extra de la plataforma compra algo que el stack moderno no pueda; normalmente no lo hace.
- ¿Cómo se evita que un modelo construido rápido sea rápido pero erróneo?
- Tratando el modelo del primer día como una hipótesis de partida y validándolo deliberadamente. Las tres comprobaciones que más importan: conciliar cada imputación con el libro mayor de origen para que nada se invente; que el especialista se haga dueño de cada generador y ecuación de tiempo en lugar de dar el visto bueno a un borrador de IA que se lee bien pero imputa mal; y hacer explícito el coste de la capacidad no utilizada para que los periodos de mucha y de poca actividad se traten con justicia. La velocidad viene de eliminar trabajo mecánico, no de eliminar escrutinio. Hecho así, rápido y correcto no están en tensión.
- ¿Qué significa que el cliente sea dueño del modelo, y por qué importa?
- La propiedad significa que el propio equipo financiero del cliente puede hacer el cambio del mes que viene sin llamar a nadie. Como CostCtrl está desarrollado a propósito y la lógica es explícita en lugar de estar enterrada en una configuración a medida, el especialista configura la primera versión y enseña el patrón, y los analistas internos lo llevan hacia adelante. Esto importa porque es el único factor que más separa a los modelos que sobreviven de los modelos que mueren. Un modelo de coste que el negocio no puede mantener será abandonado sea lo que sea que lo construyó; un modelo que sí puede mantener se mantiene vigente, se mantiene confiable y sigue ganándose su sitio mucho después de que el encargo termine.
Referencias
The Standish Group, CHAOS Report (tasas de éxito, dificultad y fracaso de los proyectos habilitados por TI, y cómo empeoran con el tamaño del proyecto). · Project Management Institute, Pulse of the Profession (proporción de la inversión perdida por un mal desempeño de los proyectos). · Gartner, investigación sobre adopción de analítica y ciencia de datos (la mayoría de los modelos analíticos avanzados nunca llega a un uso sostenido en producción). · Kaplan, R. S. & Anderson, S. R. Time-Driven Activity-Based Costing (Harvard Business Review, 2004; libro, Harvard Business Press, 2007, el método que sustenta modelos de coste transparentes y mantenibles). · Kaplan, R. S. & Cooper, R. Cost & Effect (diseño y ciclo de vida de los sistemas de coste basados en actividades). Para lecturas relacionadas véase valor económico añadido (EVA).