El coste empresarial, antes y ahora

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.

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.

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».

Preguntas frecuentes

¿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. 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.