De centro de costes a conversor de valor: la conversión del antivalor en el soporte técnico

Texto completo

1 Introducción

En la mayoría de las organizaciones de producto, el soporte técnico se contabiliza como un centro de costes. Su presupuesto es visible, su resultado se mide en tickets cerrados y la pregunta habitual es cómo abaratarlo. Este artículo sostiene que ese enfoque es incompleto y que lo que deja fuera es la parte del soporte que más importa para el producto.

El argumento utiliza el vocabulario de la Teoría de la Gestión del Valor (VMT) y de la metodología Æilus. El valor, el antivalor, el flujo de valor, el sistema de valor, el transformador de valor y el valor planificado, realizado y retrospectivo se emplean tal como se definen en el primer artículo de esta serie. El tratamiento formal de Æ, la moneda de valor, se expone en Bolshakov (2026) y no se repite.

La fuente principal es el artículo de Æilus "Technical Support Service - Anti-Value Conversion" (Bolshakov, 2025). Describe el soporte como una cadena de transformadores de valor que reciben antivalor del cliente y lo convierten en valor, con coeficientes que crecen en cada línea, y propone dos coeficientes que deben medirse en cada etapa. Este artículo reformula el modelo, hace operativos los coeficientes, establece de quién es el valor que miden y propone un protocolo de medición. No contiene datos de campo; todas las cifras del ejemplo práctico son ilustrativas.

El artículo se apoya en los axiomas de la VMT A1 (contextualidad), A2 (interpretaciones múltiples), A4 (asimetría entre plan y hecho), A5 (independencia del antivalor), A6 (realización en el consumo), A7 (transformación), A12 (no conservación del valor) y A13 (conmensurabilidad parcial), y en los teoremas T2 (inversión del flujo), T4 (acumulación de la resistencia), T5 (optimización local), T9 (flujos ocultos), T14 (el valor no interpretado se pierde), T15 (dependencia de la frontera) y T16 (escalado por interpretación sin realización).

2 Por qué el soporte se trata como un centro de costes y qué oculta eso

2.1 La visión de costes es una elección de frontera

La visión del centro de costes resulta de trazar la frontera del sistema de valor alrededor de los flujos financieros de la empresa. Dentro de esa frontera, el soporte consume salarios y herramientas y no produce ninguna línea de ingresos. Según A1, el valor existe solo dentro de un sistema de valor, y según T15, cambiar la frontera cambia la conclusión sin cambiar la realidad. La visión de costes es una lectura correcta de un sistema de valor, no una descripción de lo que hace el soporte.

T2 establece que un mismo flujo puede portar interpretaciones opuestas en distintos sistemas. Una interacción de soporte que la empresa contabiliza como coste es, para el cliente, la eliminación de antivalor: un fallo que deja de doler, una duda que deja de bloquear el trabajo. La fuente enumera diez tipos de valor para el cliente que aporta el soporte, desde la reducción del antivalor de los incidentes y el ahorro de tiempo hasta la reducción de riesgos y la confianza. Ninguno aparece en un informe de costes.

2.2 Qué oculta la visión de costes

• Valor del lado del cliente. El soporte restablece el flujo de valor del cliente. Si deja de hacerlo, la condición de participación (A8) del cliente corre peligro, y T7 predice que el cliente se va o cambia la forma de participación.
• Valor interno. La fuente nombra tres flujos internos: información sobre incidentes, solicitudes de funciones que tienen los competidores y sugerencias originales de los clientes. Según T9, una estructura sostenida por flujos que el modelo no muestra está mal modelada o mal delimitada. Un modelo de costes del soporte es un modelo así.
• Conversión. La fuente afirma que el soporte convierte antivalor en valor, y que el resultado puede superar el antivalor original en órdenes de magnitud cuando un problema llega a las líneas más profundas y al producto. A12 lo permite: una causa raíz corregida elimina antivalor para todos los clientes, no solo para quien lo notificó.

3 El soporte como punto de entrada del flujo de antivalor

Todo producto entrega tanto valor como antivalor. Según A5, el antivalor es una categoría independiente: un cliente puede recibir valor real de un producto y, en la misma semana, antivalor real por una caída del servicio. El soporte es el lugar donde la mayor parte de ese antivalor entra en la empresa como flujo observable. Este artículo lo agrupa en cuatro tipos, coherentes con la descripción que hace la fuente de la recepción en primera línea:

• Incidentes. Algo funcionaba y dejó de funcionar.
• Defectos. Algo nunca funcionó como se pretendía; el antivalor se hace visible cuando un cliente se topa con él.
• Confusión. El producto funciona, pero el cliente no consigue obtener valor de él.
• Expectativas rotas. El valor planificado y el realizado difieren. A4 establece que esto es normal; el soporte es donde se notifica la brecha.

Una quinta entrada es el valor potencial: solicitudes y sugerencias. La fuente la trata por separado y describe su volumen como no limitado. Comparte el canal, por lo que la medición debe mantenerla separada del antivalor para evitar mezclar dos denominadores.

El punto de entrada importa por T4: la resistencia se acumula. El antivalor que queda en una cola se compone en pérdida de confianza y, según T6, en una menor capacidad de realizar valor futuro. La dinámica de las colas en el desarrollo de productos está bien descrita (Reinertsen, 2009); la lectura de la VMT añade que lo que espera en una cola de soporte es antivalor que se acumula en el sistema de valor del cliente.

4 La cadena de conversión

Según A7, la transformación significa que un actor realiza valor entrante, o aquí absorbe antivalor entrante, y produce nuevo valor planificado. La fuente trata cada línea de soporte como un transformador de este tipo, cada uno con su propio Propietario del Transformador de Valor (VTO).

4.1 Primera línea

La fuente asigna a la primera línea la recepción del flujo de antivalor en tickets estructurados, la amortiguación rápida del antivalor en el primer contacto, el mantenimiento del flujo de valor continuo, el enrutamiento, la recogida de datos, la gestión de las expectativas del cliente y la evaluación de la profundidad del antivalor. Su papel es el de filtro, amortiguador y acelerador. Sobre todo restablece el estado previo del cliente, por lo que la fuente le asigna el coeficiente más bajo. La gestión de expectativas merece una mención: las actualizaciones de estado no arreglan nada, pero reducen el antivalor de la incertidumbre, un caso directo de A5.

4.2 Segunda línea

La segunda línea se ocupa del antivalor complejo: errores difíciles, integraciones, rendimiento. El cambio clave que señala la fuente es pasar de suprimir un problema a eliminar su causa raíz, y de un cliente a todos los clientes, ya que las correcciones y las instrucciones actualizadas se propagan por toda la base de clientes. La segunda línea también construye la base de conocimiento que aumenta la capacidad de la primera línea, incorpora al backlog los incidentes recurrentes y reduce el antivalor oculto, como la deuda técnica.

4.3 Tercera línea

La fuente llama a la tercera línea un transformador de nivel estratégico que trabaja sobre el antivalor arraigado en la arquitectura, el código, los protocolos y la lógica central. Sus resultados son cambios en la funcionalidad y la arquitectura, y nuevos transformadores: herramientas, scripts, monitorización y comprobaciones automatizadas que siguen convirtiendo antivalor. También establece las reglas para las líneas inferiores, incluido cómo se miden el valor y el antivalor en casos complejos. La fuente señala que el incremento es difícil de cuantificar hasta que los cambios llegan al cliente, lo que es A6 en términos operativos.

4.4 Product Owner

La fuente sitúa al equipo del Product Owner como el siguiente transformador y como sintetizador de valor. Prioriza el flujo procedente de todas las líneas, lo alinea con la estrategia, evalúa dónde es mayor el valor para el cliente con el menor antivalor en coste, tiempo y riesgo, y añade valor potencial a partir de las necesidades del mercado. El resultado es un plan de entrega que escala el valor existente y crea nuevo valor. La fuente lo vincula con PDCA: Plan a partir de los datos de soporte, Do por los equipos de entrega, Check sobre los incidentes y las métricas de valor, Act sobre la estrategia y el producto. El producto actualizado vuelve entonces a entregar valor, el soporte capta el siguiente flujo y el ciclo se cierra.

5 Los coeficientes propuestos en la fuente

5.1 Coeficientes nominales por línea

El resumen del ciclo cerrado que hace la fuente indica que el antivalor captado en la primera línea puede transformarse en valor con un coeficiente de x1 a x1,5; en la segunda línea, x10; en la tercera línea, x100. Las sugerencias de los clientes pasan a la segunda y la tercera línea con un volumen descrito como no limitado, y el valor que el Product Owner devuelve al cliente se describe como potencialmente casi ilimitado. El patrón: cuanto mayor es el problema, más alta es la línea a la que llega, y cuanto más alta es la línea, mayor es el coeficiente. La fuente los ofrece como órdenes de magnitud, no como mediciones. Este artículo los trata como hipótesis.

5.2 VAM y ACM

La fuente concluye que deben medirse dos parámetros en cada etapa:

• Value Amplification Multiplier (VAM), el coeficiente de transferencia de valor: "Cuánto valor se ha recibido y entregado al Cliente".
• Anti-Value Conversion Multiplier (ACM), el coeficiente de conversión de antivalor en valor: cuánto antivalor se ha recibido y cuánto de él se ha transformado en valor para el Cliente.

La fuente los enuncia con palabras y no da fórmulas. La lectura mínima como cociente que se propone aquí, para una etapa s (primera línea, segunda línea, tercera línea, Product Owner) durante un periodo de revisión, es:

VAM_s = V_delivered,s / V_received,s

ACM_s = V_converted,s / AV_received,s

V_received,s es el valor que entra en la etapa (sugerencias o valor potencial parcialmente transformado); V_delivered,s es el valor realizado para el cliente atribuible al resultado de la etapa; AV_received,s es el antivalor que entra en la etapa; V_converted,s es el valor realizado para el cliente producido a partir de él. Todos los términos están en Æ.

De la redacción de la fuente se derivan dos lecturas. Los numeradores son valor para el cliente, por lo que los planes, los tickets y los elementos del backlog solo cuentan una vez que el cliente los ha realizado (A6). Y los dos coeficientes tienen denominadores distintos: uno sigue la amplificación del valor, el otro la conversión del antivalor. Un coeficiente a nivel de cadena es ACM_chain = sum of V_converted,s / AV_received,1, con el antivalor de entrada como denominador y cada unidad de valor realizado atribuida a una sola etapa.

6 De quién es el valor que se mide

Según A1 y A2, un coeficiente sin un sistema de valor nombrado carece de sentido. La cadena toca cuatro sistemas de valor:

Este documento fija la medición de la siguiente manera. Los numeradores de VAM y ACM se miden en el sistema de valor del cliente, porque el valor realizado es la interpretación del receptor. Los denominadores se miden en la frontera entre cliente y soporte: el antivalor tal como el cliente lo experimenta y lo comunica, registrado por la primera línea. Los sistemas de soporte y de producto usan los coeficientes; el sistema de la empresa los pondera frente al coste. El VSO es responsable de la política de agregación para comparar estas lecturas, que solo son parcialmente conmensurables (A13). Si el soporte se midiera a sí mismo desde su propio sistema de valor, informaría de esfuerzo y de valor planificado. Las definiciones de la fuente apuntan hacia fuera, y el protocolo las mantiene ahí.

7 Un protocolo de medición

El protocolo siguiente es una propuesta, no probada en el terreno, diseñada para funcionar con las herramientas existentes de tickets y backlog.

7.1 Datos que se registran

• En la entrada: el cliente y el uso del producto; el tipo de entrada (incidente, defecto, confusión, expectativa incumplida, sugerencia); una estimación del antivalor en Æ en una escala compartida, confirmada con el cliente cuando sea posible; los dominios afectados.
• En cada traspaso: la etapa receptora y el motivo; el tipo de resolución (estado restablecido, corregido para este cliente, causa raíz eliminada, nuevo transformador creado, elemento de backlog creado); los vínculos de los tickets con los elementos del backlog y las versiones; el valor planificado de los cambios propuestos, mantenido separado del valor realizado.
• Tras la entrega: el valor realizado en Æ confirmado por el cliente o por un indicador sustitutivo acordado; el número de clientes alcanzados; una reevaluación retrospectiva posterior.

7.2 Quién valida el valor realizado

El transformador que reclama el mérito no valida su propio valor realizado. El cliente lo interpreta, mediante confirmación explícita o indicadores sustitutivos acordados de antemano (el incidente no se repite, la funcionalidad se usa). El VTO de cada línea propone estimaciones y es responsable de la calidad del registro. El VTO del producto confirma qué cambios entregados se remontan a qué entradas de soporte. El VSO resuelve las disputas de atribución. El valor planificado se registra, pero nunca entra en un numerador, conforme a A4 y T16: escalar una afirmación de valor solo mediante la interpretación es estructuralmente inestable. El x100 de la fuente para la tercera línea es una afirmación de ese tipo hasta que el cambio llegue a los clientes.

7.3 Cadencia de revisión

• Por ticket, al cierre: estimación de entrada, tipo de resolución, valor realizado de la primera línea.
• Por línea, en un ciclo regular corto: ACM y VAM de los elementos completados, antigüedad del antivalor abierto en las colas (T4), motivos de escalado.
• Por sistema, en un ciclo más largo: el VSO y el VTO del producto revisan los cambios entregados, las reevaluaciones retrospectivas, la entrada total de antivalor y si los coeficientes de cada línea siguen el orden que predice la fuente.

Como la realización se retrasa, los coeficientes deben informarse por cohorte, es decir, el periodo en que se recibió el antivalor.

7.4 Riesgos

Goodhart (1975) observó que una regularidad estadística tiende a desmoronarse cuando se usa para el control. En términos de VMT esto es T5: la optimización local no garantiza la mejora global.

• Manipulación del recuento de tickets. Dividir un problema en varios tickets infla el rendimiento. VAM y ACM son cocientes en Æ, no recuentos, pero el número de tickets no debería fijarse como objetivo junto a ellos.
• Reducción de la entrada. Subestimar el antivalor eleva el ACM. Las estimaciones de entrada necesitan una escala compartida y confirmación del cliente por muestreo.
• Escalado excesivo. Si las líneas superiores muestran coeficientes más altos, el escalado resulta tentador. Debe juzgarse según las reglas de escalado que fije la tercera línea.
• Doble recuento. El mismo valor realizado puede ser reclamado por varias etapas. Cada unidad se asigna una sola vez.
• Ocultación de la entrada. El mejor resultado es que llegue menos antivalor al soporte, algo que el ACM no puede ver. La entrada total debe informarse junto a los coeficientes, y una caída debe interpretarse como un resultado.
• Pérdida de señales. Según T14, el valor sin interpretación se pierde. El registro debería mostrar cuántas sugerencias y patrones llegaron a una decisión de producto.

8 Relación con los dominios de servicio

La metodología Æilus define un dominio como un contexto de interpretación de valor que impone requisitos a las prácticas y los resultados admisibles. Los dominios no crean valor; impiden el antivalor no admisible. El soporte toca varios dominios típicos:

• Disponibilidad y Continuidad. Un incidente es una violación de este contexto para el cliente. El deber de la primera línea de mantener un flujo de valor continuo es su lado operativo, y el enrutamiento debe seguir la política del dominio sobre criticidad.
• Seguridad. La metodología señala que el valor puede ser rechazado porque viola el contexto requerido para una participación segura. Una solución provisional que debilita la seguridad se registra como nuevo antivalor, no como conversión.
• Arquitectura. La fuente exige que las decisiones de la tercera línea se comprueben en cuanto a integridad arquitectónica, escalabilidad, rendimiento y seguridad.
• Gestión del Conocimiento y Mejora Continua. La base de conocimiento de la segunda línea y el ciclo PDCA son prácticas de estos dominios.

De ello se derivan dos consecuencias. El valor realizado que se cuenta en el ACM debe ser admisible en todos los dominios pertinentes. Y el ACM agrega valor entre dominios parcialmente conmensurables (A13), por lo que necesita la política de agregación explícita que la metodología asigna al VSO, con las políticas de dominio en manos de los Domain Owners. Sin ella, advierte la metodología, la optimización degenera en preferencia local o manipulación de métricas.

9 Ejemplo ilustrativo desarrollado

Este ejemplo es hipotético. El producto, los clientes y las cifras son inventados y deliberadamente redondos. No son hallazgos y no ponen a prueba los coeficientes de la fuente.

Un producto tiene un fallo recurrente en una integración de importación de datos. En un periodo, diez clientes lo comunican.

• Recepción. Se estima que el antivalor de cada cliente es de 10 Æ, de modo que AV_received,1 = 100 Æ.
• Primera línea. Una solución provisional conocida y las actualizaciones de estado restablecen el trabajo; los clientes confirman 120 Æ de valor realizado. ACM_1 = 120 / 100 = 1.2, dentro del rango nominal de la fuente.
• Segunda línea. Se encuentra una causa raíz de configuración; un valor por defecto corregido y un artículo de la base de conocimiento llegan a los clientes que reportaron el problema y a otros. Valor realizado confirmado: 400 Æ. ACM_2 = 400 / 100 = 4, por debajo del x10 nominal. En el protocolo esto es un resultado que hay que examinar, no un error que corregir.
• Tercera línea y producto. Se descubre que el protocolo de importación es frágil; un rediseño y una verificación automatizada pasan a la hoja de ruta con un valor planificado de 5,000 Æ. No se ha entregado nada, por lo que ACM_3 = 0 para esta cohorte. Los 5,000 Æ se registran y se excluyen.
• Sugerencias. Dos clientes piden importaciones programadas. Esto es valor potencial en la vía VAM y no entra en ACM.

En esta revisión ACM_chain = (120 + 400 + 0) / 100 = 5.2. Si más adelante se entrega el rediseño y los clientes confirman valor, la cohorte de tercera línea se actualiza retrospectivamente; si provoca una regresión, ese antivalor se registra en la tercera línea. El ejemplo muestra lo que debe observar un piloto: la brecha entre plan y hecho en la etapa más profunda (A4, A6), el retraso de realización y la posible divergencia respecto de los coeficientes nominales.

10 Limitaciones

No hay datos de campo ni aquí ni en la fuente. Los coeficientes x1 a x1.5, x10 y x100 son órdenes de magnitud propuestos, plausibles según el mecanismo descrito (una corrección escalada a muchos clientes, creación de nuevos transformadores) pero no medidos. Las fórmulas son la lectura que hace este artículo de definiciones verbales; son posibles otras lecturas. Las estimaciones en Æ dependen de la interpretación, lo cual, según A2, es una propiedad del valor, pero la comparación entre equipos sigue necesitando una escala común calibrada que este artículo no proporciona. La atribución entre etapas se asigna al VSO sin una regla.

Un piloto que pudiera respaldar o debilitar el modelo tendría que demostrar:

• que distintas personas hacen estimaciones en Æ coherentes para los mismos tickets;
• que el ACM de cohorte a lo largo de varios ciclos de revisión sigue el orden previsto por línea, sean cuales sean los valores absolutos;
• que el valor realizado fue confirmado por los clientes o por proxies acordados, y no por las propias líneas que lo reclaman;
• que el uso de los coeficientes fue seguido por una menor entrada total de antivalor, sin la manipulación enumerada en la sección 7.4;
• que los coeficientes aportan información más allá de las medidas convencionales, como el tiempo de restablecimiento del servicio (Forsgren, Humble y Kim, 2018).

11 Conclusión

Tratar el soporte solo como un centro de costes es una elección de frontera. En el sistema financiero de la empresa el soporte es un coste; en el sistema del cliente es la eliminación de antivalor; en el sistema del producto es la información más directa sobre dónde falla el producto. El modelo de la fuente describe una cadena de transformadores cuyo apalancamiento crece desde la primera línea hasta la tercera y hacia el equipo del Product Owner, cerrando un ciclo PDCA de vuelta al cliente, y propone VAM y ACM para medirlo. Este artículo ha dado a los coeficientes fórmulas mínimas, ha fijado sus numeradores en el sistema de valor del cliente, ha contado únicamente el valor realizado y admisible en el dominio, y ha propuesto un protocolo de registro, validación, revisión y protección contra la manipulación. Si los órdenes de magnitud de la fuente se sostienen es una pregunta que solo un piloto puede responder.

Referencias

• Bolshakov, V. Technical Support Service - Anti-Value Conversion. aeilus.tech, 2025.
• Bolshakov, V. Domains and Policies. Æilus methodology, aeilus.tech, 2026.
• Bolshakov, V. Roles. Æilus methodology, aeilus.tech, 2026.
• Bolshakov, V. Value Management Theory and Employee-Centric Competitive Advantage: A System-Level Perspective. ÆVRI, 2026.
• Bolshakov, V. Value, Anti-Value and Value Flows: A Working Vocabulary for Practitioners. ÆVRI, 2026.
• Forsgren, N., Humble, J. and Kim, G. Accelerate: The Science of Lean Software and DevOps. 2018.
• Goodhart, C. A. E. Problems of Monetary Management: The U.K. Experience. 1975.
• Reinertsen, D. G. The Principles of Product Development Flow. 2009.