Implementar TBM exige más disciplina que la que promete el modelo

Qué problema resuelve TBM y qué no resuelve

Technology Business Management nació para responder una pregunta que la contabilidad tradicional de TI nunca contestó bien: de cada peso que se invierte en tecnología, qué recibe realmente cada área de la organización a cambio. No es un software ni una metodología de proyecto; es una forma de estructurar la información financiera de TI para que dos audiencias distintas —tecnología y negocio— puedan discutir sobre la misma base.

Lo que TBM no resuelve es la disciplina de gobierno que exige mantenerlo vivo. El marco ordena la información, pero no obliga a nadie a usarla para decidir. Una organización puede construir un modelo de asignación de costos impecable y seguir aprobando presupuestos por inercia, exactamente igual que antes, simplemente porque nadie convirtió esa transparencia en un ritual de decisión. Esta distinción es importante porque explica por qué implementaciones técnicamente correctas de TBM terminan sin impacto: el modelo funciona, pero la conversación directiva no cambió.

Las tres capas del modelo: de la cuenta contable al consumo de negocio

El recorrido de TBM se entiende mejor como una traducción en tres pasos. El primer paso toma el gasto tal como llega de contabilidad —nómina de TI, licencias, contratos de infraestructura, depreciación de equipos— y lo reagrupa en «torres de tecnología»: cómputo, almacenamiento, redes, aplicaciones, seguridad, soporte. Esta capa ya es útil para TI, porque permite comparar el costo de cada torre contra referencias de mercado, pero todavía habla en un idioma que el negocio no reconoce.

El segundo paso convierte esas torres en servicios de TI con nombre reconocible para cualquier persona fuera de tecnología: correo corporativo, plataforma de ventas, sistema de nómina, red de tiendas conectadas. Aquí es donde el modelo empieza a tener sentido para un gerente de área, porque un servicio se puede evaluar por su calidad y su costo, mientras que una torre de tecnología no significa nada para quien no trabaja en TI.

El tercer paso —el que con más frecuencia se omite— asigna el costo de cada servicio al consumo real de cada unidad de negocio: cuántas cuentas de correo usa cada área, cuántas transacciones procesa cada plataforma por unidad de negocio, cuántos usuarios activos tiene cada aplicación en cada división. Sin este último paso, TBM se queda en un ejercicio de clasificación técnica: ordenado, pero incapaz de decirle a un gerente cuánto le cuesta específicamente lo que usa su área.

Del reporte a la gobernanza: showback y chargeback

Una vez que el costo llega al nivel de consumo por unidad de negocio, la organización enfrenta una decisión de gobierno que suele subestimarse: si esa información se comparte solo para generar conciencia —lo que el marco llama showback— o si se traslada como cobro interno real a los presupuestos de cada área —chargeback—.

El showback es más fácil de implementar y genera menos resistencia, porque ninguna unidad de negocio ve afectado su presupuesto directamente; solo recibe visibilidad sobre lo que consume. Su limitación es que, al no tener consecuencia presupuestal, con frecuencia se ignora después de las primeras reuniones de presentación. El chargeback, en cambio, cambia el comportamiento de manera más rápida porque afecta el presupuesto de quien consume, pero exige un nivel de precisión y aceptación organizacional mucho mayor: si una unidad de negocio considera que el modelo de asignación es injusto o poco transparente, el chargeback se convierte en una fuente de conflicto en lugar de una herramienta de gestión.

La mayoría de las organizaciones que implementan TBM con éxito empiezan con showback durante uno o dos ciclos presupuestales, y solo avanzan a chargeback una vez que el modelo de asignación ha sido validado y aceptado por las áreas de negocio, no solo por TI.

Errores típicos al implementar TBM

El error más frecuente es tratar la implementación como un proyecto de TI con fecha de cierre, en lugar de una capacidad de gestión permanente. Un equipo de tecnología construye el modelo de asignación, lo presenta una vez al comité directivo, y luego lo deja de actualizar porque nadie lo reclama activamente. Sin actualización periódica, el modelo pierde precisión y con ella pierde credibilidad, lo que a su vez reduce el interés del negocio en usarlo.

Un segundo error es construir el modelo sin involucrar a los responsables de cada unidad de negocio en la definición de qué se mide y cómo se reparte el costo compartido. Cuando TI decide unilateralmente las reglas de asignación —por ejemplo, prorratear el costo de la infraestructura compartida por número de empleados en lugar de por consumo real— el negocio percibe el resultado como arbitrario, y esa percepción es suficiente para que ignore el reporte, sin importar cuán sofisticado sea el cálculo detrás.

Un tercer error, más sutil, es perseguir una precisión que el propio negocio no necesita. Algunos equipos de TI invierten meses en afinar la asignación de costos hasta el nivel de transacción individual, cuando el comité directivo solo necesita suficiente precisión para tomar decisiones de portafolio: qué servicios ampliar, cuáles mantener y cuáles descontinuar. Ese exceso de refinamiento retrasa la entrega de valor sin mejorar la calidad de las decisiones que realmente se toman con la información.

La madurez se construye por ciclos, no por proyecto

TBM se comporta como cualquier capacidad de gestión: mejora con ciclos sucesivos de uso, no con una implementación única. En el primer ciclo, es normal que la asignación de costos a nivel de consumo tenga imprecisiones, que algunos servicios queden mal clasificados y que el negocio cuestione ciertas cifras. Lo relevante no es llegar al primer reporte con precisión perfecta, sino tener el mecanismo para corregir, documentar el ajuste y presentar una versión más confiable en el siguiente ciclo presupuestal.

Esta lógica de maduración explica por qué las organizaciones que tratan TBM como un proyecto de una sola fase rara vez ven resultados sostenidos, mientras que las que lo tratan como una función permanente —con un responsable claro de mantener el modelo actualizado y de negociar los ajustes con el negocio— sí logran que la información se use año tras año como insumo real de la planeación presupuestal.

Qué decisiones cambia realmente

El resultado concreto de un modelo TBM maduro no es un reporte más detallado, es un cambio en el tipo de pregunta que se hace en el comité directivo. En lugar de discutir si el presupuesto de TI sube o baja un porcentaje frente al año anterior, la conversación pasa a evaluar si el costo de cada servicio sigue siendo razonable frente al valor que genera para el negocio, y si existen servicios que ya no justifican su nivel de inversión.

Ese cambio de pregunta es, en última instancia, el verdadero indicador de que la implementación de TBM funcionó. Un modelo de asignación de costos impecable que nunca modifica una decisión de inversión no cumplió su propósito; un modelo más simple que logra que el comité directivo descontinúe un servicio sobredimensionado o redirija presupuesto hacia una capacidad estratégica sí lo cumplió, independientemente de cuán elaborado fuera el cálculo detrás.