Hacer visibles las deudas técnicas: un modelo de puntuación ligero para decisiones de portafolio

En muchas organizaciones de TI, la deuda técnica es ya un estado permanente: las aplicaciones funcionan, los procesos operan, y aun así cada cambio se vuelve más lento, cada release más arriesgado y cada incidente más costoso. El problema rara vez es que nadie vea los riesgos, sino que no son comparables. Si cinco sistemas son „críticos“ a la vez, al final ninguno puede priorizarse. Aquí es donde ayuda un modelo de puntuación de deuda técnica: un marco de evaluación ligero y repetible que representa los riesgos técnicos, el esfuerzo operativo y la presión de modernización de manera que las decisiones de portafolio sean sólidas.

Este artículo describe un modelo de puntuación que prescinde de un assessment mastodóntico, pero que funciona en el día a día de la dirección de TI, operación, administradores, responsables de proyecto y áreas de negocio. El foco no está en detalles internos del código, sino en los efectos sobre operaciones, seguridad, datos, interfaces, capacidad de entrega y mantenimiento. El objetivo es una lengua común que atenúe las discusiones sobre presupuesto y priorización y haga la modernización planificable.

Modelo de puntuación de deuda técnica en la práctica

La deuda técnica es un término paraguas para decisiones y cargas heredadas que ahorraron tiempo a corto plazo pero que generan costes de interés a largo plazo. Esos „intereses“ se manifiestan en la operación cotidiana de la empresa como tiempos de entrega más largos, más coordinación, mayores tasas de error, brechas de seguridad, conocimiento experto concentrado en pocas personas o dependencias de componentes fuera de soporte. El problema: muchos de estos efectos no aparecen como una partida de coste clara.

Razones típicas por las que la deuda técnica se pierde en las rondas de portafolio:

• Falta de comparabilidad: Un monolito antiguo pero estable, una herramienta SaaS con presión creciente de licencias y una vía de integración con jobs nocturnos son difíciles de ponderar entre sí sin un marco.
• Situación de datos inconsistente: Para el sistema A hay estadísticas de incidentes y monitorización, para el sistema B solo intuición, para el sistema C nada.
• Debates mezclados: El valor funcional, los riesgos técnicos y las preferencias personales (tecnología, deseos del equipo) acaban en la misma discusión.
• Modelos de evaluación demasiado grandes: Los modelos de madurez exhaustivos tienen sentido, pero con frecuencia no se mantienen regularmente. Para decisiones de portafolio cuenta la repetibilidad.

Un modelo de puntuación ligero no es la verdad perfecta. Es una herramienta para reducir la incertidumbre y hacer las decisiones trazables, incluyendo las suposiciones que hay detrás.

Principios para un modelo de puntuación ligero

Para que un modelo de puntuación no termine como un „ejercicio de Excel“, debería cumplir algunos principios básicos:

• Pocas dimensiones, definiciones claras: Mejor explicar con precisión 6–8 dimensiones de evaluación que recopilar 20 criterios a medias.
• Medible, pero no fijado exclusivamente a métricas: No todo está disponible en forma de número. Lo importante es que los criterios se apliquen de manera consistente.
• Apto para el portafolio: La evaluación debe funcionar de forma transversal entre sistemas —independientemente de si se trata de software empresarial a medida, productos estándar o componentes de integración.
• Perspectivas explícitas: Operaciones, seguridad, datos y el área de negocio deben figurar en el modelo, para que no se reduzca la discusión a «técnica contra negocio».

En la práctica ha demostrado su valor tratar el score como base para la conversación: proporciona una lista priorizada, pero no decisiones automáticas. Los comités de portfolio siguen siendo responsables — y documentan intencionadamente las desviaciones.

El modelo de scoring: 8 dimensiones que realmente importan en operación

La cuadrícula siguiente utiliza ocho dimensiones que pueden recogerse bien en paisajes empresariales típicos. Cada dimensión se valora en una escala de 1 a 5 (1 = no crítico/bien controlado, 5 = crítico/presión urgente para actuar). Lo importante no es la perfección matemática, sino la claridad de los criterios.

1) Estabilidad operativa y perfil de incidencias

Aquí se trata de la pregunta: ¿Con qué frecuencia interrumpe el sistema la operación — y cuán costosas son estas interrupciones para la organización? La base son los incidents (fallos), tickets recurrentes, escaladas on-call y mantenimientos no planificados. También cuenta la inestabilidad „silenciosa“, por ejemplo cuando las ejecuciones nocturnas requieren con frecuencia trabajo posterior.

Puntos de referencia para la evaluación (ejemplos):

• 1: Incidencias raras, runbooks (manuales de operación) claros, procedimientos de reinicio ensayados.
• 3: Fallos regulares o problemas de rendimiento frecuentes, pero manejables.
• 5: Caídas recurrentes, alta carga de soporte, soluciones temporales en lugar de corrección de la causa.

2) Riesgo de seguridad y cumplimiento

Esta dimensión valora hasta qué punto el sistema está protegido frente a incidentes de seguridad y qué tan auditables son sus operaciones. Incluye la capacidad de aplicar parches, componentes soportados, autenticación (p. ej. SSO mediante SAML/OIDC — es decir, inicio de sesión centralizado), registro (audit-trail: cadena de eventos rastreable) y protección de datos sensibles.

• 1: Actualizaciones regulares, roles/permisos claros, logs auditables, sin componentes conocidos en fin de vida.
• 3: Componentes parcialmente obsoletos o lagunas en registro/recertificación, con medidas compensatorias.
• 5: Vestigios críticos, falta de parches, responsabilidades no aclaradas, riesgos en auditoría.

3) Cambiabilidad y capacidad de release

“¿Qué tan difícil es entregar cambios con seguridad?” Ese es el núcleo de muchas deudas técnicas. Se refiere a la testabilidad (regresión: pruebas repetibles), proceso de deploy, capacidad de rollback (opción de reversión clara), dependencia de personas concretas y el tiempo desde la solicitud hasta la puesta en producción.

• 1: Releases reproducibles, entornos definidos, ventanas de mantenimiento planificables.
• 3: Releases posibles pero con pasos manuales y mayor necesidad de coordinación.
• 5: Cada cambio implica riesgo, deploy solo “con las personas adecuadas”, rollback poco claro.

4) Complejidad de arquitectura e integración

Esta dimensión no mide si una arquitectura es „moderna“, sino si es manejable. Las integraciones suelen ser el factor que impulsa los costes: interfaces punto a punto, formatos de archivo especiales, procesamiento por lotes con restricciones temporales, falta de versionado de las APIs (contratos de interfaz) o acoplamiento estrecho a otros sistemas.

• 1: Interfaces claramente documentadas, pocos puntos de acoplamiento, los cambios tienen efecto local.
• 3: Varias dependencias, los cambios requieren releases coordinados.
• 5: Integraciones en „espagueti“, flujos de datos desconocidos, alto impacto ante pequeños cambios.

5) Datenqualität, Datenhoheit und Datenflüsse

Para decisiones de portafolio es decisivo que los datos estén gestionados de forma limpia y sean utilizables con fiabilidad. Soberanía de datos significa: está claro dónde reside la „fuente de la verdad“, cómo se generan los datos maestros (p. ej. clientes, artículos, proveedores) y cómo afectan los cambios a sistemas descendentes. Los flujos de datos incluyen también exportaciones, copias en sombra y correcciones manuales.

• 1: Responsabilidades claras, trazabilidad de los caminos de datos, interfaces definidas, claves consistentes.
• 3: Varias fuentes de datos o limpiezas periódicas, pero transparentes.
• 5: Verdad incierta, correcciones frecuentes, reporting posible solo con lógica especial.

6) Lifecycle-Risiko: Hersteller, Plattform, Skills

Las deudas técnicas también surgen por descontinuaciones: sistemas operativos, bases de datos, bibliotecas, soporte del fabricante o disponibilidad de conocimientos. Esta dimensión examina deliberadamente el aspecto organizativo: ¿hay suficientes personas que sostengan la operación y la evolución? ¿Existe una ruta de actualización fiable?

• 1: Ciclos de soporte activos, upgrade planificado, competencias ampliamente disponibles.
• 3: Upgrade próximo, escasez de competencias, dependencia de pocas personas clave.
• 5: End-of-Life, sin hoja de ruta, conocimiento concentrado, alto riesgo por el proveedor.

7) Kosten- und Aufwandstreiber im laufenden Betrieb

Aquí no se valoran solo los costes de infraestructura, sino sobre todo los costes variables: esfuerzo de soporte, tareas manuales, procesos especiales, crecimiento de licencias, dependencia de proveedores externos o ventanas de mantenimiento costosas. En el caso de software de negocio, estos costes indirectos suelen ser más determinantes que el precio de los servidores.

• 1: Operación estable, pocas tareas manuales, costes previsibles.
• 3: Aumento del esfuerzo operativo o de los costes de licencia, pero controlable.
• 5: La operación „se come“ la capacidad, muchas correcciones manuales, costes difícilmente previsibles.

8) Business-Kritikalität und Prozessabhängigkeit

Las deudas técnicas solo son relevantes para decisiones de portafolio cuando se combinan con riesgo de proceso. Esta dimensión evalúa cuánto sostiene el sistema procesos clave y cuál es el daño en caso de fallo o mal funcionamiento. Importante: la criticidad no es una licencia para „nunca tocar“, sino un argumento a favor de una estabilización y modernización cuidadosas.

• 1: Proceso de apoyo, fallo tolerable, existe un workaround.
• 3: Proceso importante, los fallos generan costes, pero limitables.
• 5: Proceso central, el fallo detiene la creación de valor o implica riesgos de cumplimiento.

Wie aus Scores Portfolio-Entscheidungen werden (ohne Scheingenauigkeit)

Un score solo es útil cuando prepara una decisión. Para ello hacen falta dos pasos: ponderación y categorías de decisión.

Gewichtung: nicht jedes Kriterium zählt gleich

Muchas organizaciones comienzan con ponderaciones iguales para evitar discusiones. Más adelante conviene una ponderación sencilla según el objetivo del portafolio, por ejemplo:

• Seguridad primero (p. ej. según hallazgos de auditoría): ponderar doble el riesgo de seguridad y cumplimiento.
• Aumentar la capacidad de entrega (p. ej. ante un alto backlog de cambios): ponderar más la modificabilidad/la capacidad de despliegue.
• Estabilizar costes (p. ej. con soporte en aumento): ponderar más los impulsores de esfuerzo en operación.

Es importante documentar la ponderación de forma transparente y cambiarla solo con poca frecuencia. De lo contrario, las variaciones en la puntuación parecen „políticas“ en lugar de una mejora real.

Categorías de decisión: cuatro opciones de actuación claras

De las dimensiones se pueden derivar cuatro categorías pragmáticas que se discuten bien en el Portfolio-Board:

• Estabilizar: Alto riesgo operativo/de seguridad, pero no es posible un reemplazo a corto plazo. Enfoque en runbooks, monitorización, rutas de parcheo, higiene técnica.
• Modernizar: Altos riesgos por cambios o por ciclo de vida con simultánea alta criticidad. Enfoque en renovación modular, desacoplar interfaces, consolidar modelos de datos.
• Consolidar/Reemplazar: Funciones duplicadas, alto esfuerzo, escasa diferenciación. Enfoque en desactivación, migración de datos, unificación de procesos.
• Aceptar conscientemente: Baja criticidad o vida residual previsible. Enfoque en controles de riesgo, mantenimiento mínimo, opción de salida clara.

Para que esto no quede en teoría, cada aplicación debe recibir además un siguiente paso útil —máximo 1–2 medidas concretas realistas en 4–12 semanas. Así, la gestión del portafolio se convierte en un proceso de mejora continuo en lugar de un taller anual.

Construir la base de datos de forma pragmática: qué fuentes suelen ser suficientes

Un modelo ligero requiere que la obtención de datos no sea más costosa que las primeras medidas. Para muchas empresas bastan cuatro fuentes de datos para asignar puntuaciones creíbles:

• Datos de tickets/incidentes: frecuencia, repeticiones, tiempos de resolución, escaladas. Si no existe una categorización limpia, al principio basta una asignación grosera (incidencia, solicitud, cambio).
• Monitorización/disponibilidad: no solo tiempo de actividad, sino también picos de rendimiento, tiempos de ejecución de jobs, tasas de error, crecimiento de memoria/disco.
• Información de seguridad y ciclo de vida: estado de parches, fechas de fin de vida (End-of-Life), dependencias (p. ej. versión de base de datos, sistema operativo, autenticación), excepciones conocidas.
• Resumen de arquitectura/integración: un mapa de aplicaciones simple (mapa del sistema) con flujos de datos e interfaces. La completitud es secundaria; lo que cuenta es la actualidad.

Si faltan cifras, eso debe reflejarse en la puntuación: „Evaluación 4 por falta de evidencias“ es más honesto que una media aleatoria. Lo desconocido suele ser en operación más arriesgado que algo malo que al menos se conoce.

Taller de scoring en 90 minutos: procedimiento, roles, artefactos de resultado

Un error frecuente es realizar el scoring de forma individual. Entonces se vuelve o bien demasiado técnico o bien demasiado político. Es mejor un taller corto por sistema, moderado y con roles claros. 90 minutos son suficientes para una primera evaluación fiable, si los datos base están disponibles.

Participantes (reducido, pero completo)

• Responsable de TI del sistema: conoce la hoja de ruta, los cambios, los cuellos de botella técnicos.
• Operaciones/Administración: conoce las incidencias, ventanas de mantenimiento, monitorización, copias de seguridad/recuperación.
• Responsable funcional o usuario clave: conoce la criticidad de los procesos, soluciones alternativas, aceptación, horas pico.
• Moderación: asegura la fidelidad a las definiciones y documenta las suposiciones.

Proceso (compacto, repetible)

1. Contexto (10 min.): propósito del sistema, grupos de usuarios, interfaces principales, modelo operativo (On-Prem/Cloud/Híbrido).
2. Puntuación por dimensión (45 min.): por criterio 3–5 minutos, con evidencias breves (número de tickets, estado de parches, dependencias conocidas).
3. Identificar puntos críticos (15 min.): ¿Qué 2 dimensiones impulsan más el riesgo/costo?
4. Definir acciones (15 min.): 1–2 pasos concretos siguientes, además de responsable y fecha objetivo.
5. Etiqueta del portafolio (5 min.): Estabilizar / Modernizar / Consolidar / Aceptar.

Como resultado son suficientes tres artefactos: tabla de puntuaciones, breve justificación por dimensión y un extracto de medidas. Todo lo demás es opcional.

Trampas típicas – y cómo mitigarlas en el modelo

Un modelo de puntuación puede generar incentivos equivocados si no está bien enmarcado. Según la experiencia en proyectos, estos son los tropiezos más comunes:

Trampa 1: «Castigar a los equipos por la transparencia»

Si los equipos con buena documentación obtienen peores puntuaciones porque hacen visibles los problemas, el modelo está roto. Contramedida: tratar lo desconocido (datos ausentes) como un riesgo propio y reconocer expresamente la transparencia como un punto a favor, p. ej. en el criterio de capacidad de cambio (reversiones, runbooks, monitorización).

Trampa 2: La puntuación se convierte en instrumento para recortar presupuestos

Si las puntuaciones altas conducen automáticamente a un „paro del proyecto“, el modelo se politiza. Mejor: las puntuaciones altas generan un documento para la toma de decisiones con opciones (p. ej. estabilizar vs. modernizar) y consecuencias claras. El presupuesto sigue a la decisión — no a la puntuación por sí sola.

Trampa 3: Mezcla de beneficio y riesgo

El beneficio funcional (p. ej. potencial de ingresos) es importante, pero es otra dimensión. Un enfoque probado: evaluar el beneficio en una matriz separada y luego integrarlo en una matriz de portafolio (beneficio alto/bajo vs. riesgo/deuda alto/bajo). Así no se discute si un riesgo de seguridad está „compensado por ingresos“.

Trampa 4: «Modernización» se entiende como un gran proyecto

Las decisiones de portafolio a menudo fracasan por la suposición implícita de que la modernización solo puede realizarse como un Big Bang. En la realidad, con frecuencia conviene una modernización modular: estabilizar interfaces, estandarizar los accesos a datos, desacoplar procesos parciales individuales y gestionar con claridad el funcionamiento en paralelo. Una puntuación ayuda a encontrar el orden, no a imponer el estado final.

De la puntuación a la hoja de ruta: cómo se ajustan adecuadamente los paquetes de medidas

Cuando el modelo está establecido, viene el trabajo real: recortar las medidas de modo que funcionen en el día a día junto al negocio de proyectos. Tres reglas ayudan a convertir el «deberíamos» en elementos concretos de la hoja de ruta:

1) Primero mitigar los riesgos más costosos

En muchos portafolios, los riesgos de seguridad y de operación son las palancas más relevantes, porque implican plazos externos (auditoría, fin de vida) y altos costes posteriores. Las mitigaciones típicas son: establecer una ruta de actualización, complementar el registro/log de auditoría, probar copias de seguridad/RESTauración, reducir puntos únicos de fallo, validar la coherencia de los permisos.

2) Estabilizar los nodos de integración antes de ampliar funcionalidades

Los sistemas con muchas interfaces multiplican los costes de cambio. Aquí suele convenir primero: definir contratos de interfaz (versionado, formatos de datos, manejo de errores), añadir monitorización de flujos de datos, desacoplar cadenas de trabajos, introducir estrategias de reintento (reintentos ante errores). Esto rara vez es «visible» para el área de negocio, pero reduce de forma medible los tiempos de inactividad y el estrés en los releases.

3) Planificar las medidas como «mejora operativa»

Muchas deudas técnicas se pueden implementar como mejoras operativas en pequeños paquetes: runbooks, reglas de alarma, planificación de capacidad, estandarización de entornos, ventanas regulares de parcheo. No son proyectos llamativos, pero aumentan la fiabilidad y crean ventanas temporales para pasos de modernización mayores.

Así se mantiene la puntuación de forma permanente: gobernanza sin burocracia

Un modelo solo tiene valor si no cae en letargo tras dos trimestres. Para ello necesita un proceso sencillo que encaje con la operación y el día a día del proyecto:

• Responsable por aplicación: Una persona designada que mantiene la puntuación y el estado de las medidas (no las ejecuta sola).
• Desencadenantes en lugar de obligación de calendario: Revisión de la puntuación tras un clúster de incidentes, un release mayor, un hallazgo de auditoría o una actualización de plataforma.
• Ritmo del portafolio: Mensual/bimestral: 60 minutos para los riesgos principales, no para todos los sistemas.
• Registro de decisiones: Breve documentación sobre por qué un riesgo fue aceptado o aplazado. Esto previene asignaciones de culpa posteriores y hace visibles las suposiciones.

Es crucial la vinculación con una gobernanza real: al menos una parte de la capacidad (presupuesto o tiempo del equipo) debe reservarse explícitamente para estabilización/modernización. De lo contrario, el modelo solo produce conocimientos sin impacto.

Conclusión: Hacer visibles las deudas técnicas sin sobrecargar a la organización

Un modelo de puntuación de deuda técnica ligero no sustituye el trabajo de arquitectura detallado, pero aporta algo que suele faltar en los portfolios: comparabilidad. Con ocho dimensiones claras, anclajes de evaluación trazables y un formato de taller breve, es posible representar riesgos, esfuerzo operativo y presión de modernización de forma que TI, el área de negocio y la dirección mantengan la misma discusión.

El efecto más importante rara vez es el valor numérico exacto. Es la transparencia sobre dónde se generan las deudas técnicas, cómo afectan al funcionamiento operativo y qué pasos siguientes son realistas. Si las puntuaciones se revisan regularmente y se vinculan a medidas pequeñas y concretas, surge una hoja de ruta de modernización que no queda en el papel, sino que se sostiene en el día a día operativo.

Si desea implantar el modelo de puntuación para su cartera de aplicaciones o realizar las primeras valoraciones en un formato moderado, aquí encontrará el punto de partida adecuado: Póngase en contacto.

Para este tema también son relevantes Evaluar deudas técnicas y Decisiones de cartera de TI. El artículo ordena estos aspectos de forma comprensible y muestra qué importa en la práctica diaria.

Discutir un proyecto o iniciativa de modernización con Net-Base.