Mide si la propiedad del código fue rentable

En tu empresa, decidir si mantener la propiedad del código o depender de un proveedor es una inversión que debe justificarse con resultados tangibles. En este artículo descubrirás qué indicadores observar, cómo establecer la línea de base, cuándo esperar los efectos y qué hacer si los números no confirman la hipótesis inicial.

Qué medir y qué no

No todas las cifras que aparecen en los reportes de proyecto son útiles para evaluar la rentabilidad de la propiedad del código. Distinguimos entre indicadores de valor (aquellos que explican el desempeño real) y métricas de vanidad (números que pueden verse bien pero no aportan información de decisión).

• Indicadores de valor

  • Tiempo de resolución de incidencias (TRI): promedio en horas que el equipo interno o el proveedor tarda en corregir un bug crítico.
  • Costo de mantenimiento mensual (CMM): suma de salarios internos, licencias y honorarios externos dedicados al soporte.
  • Velocidad de entrega de nuevas funcionalidades (VDF): número de story points entregados por sprint o por semana.
  • Independencia operativa (IO): porcentaje de cambios que puedes ejecutar sin necesidad de solicitar autorización al proveedor.
  • Cumplimiento regulatorio (CR): número de auditorías de SUNAT o de la normativa de facturación electrónica que se superan sin intervención externa.

• Métricas de vanidad

  • Número de líneas de código escritas: no indica calidad ni reutilización.
  • Cantidad de reuniones con el proveedor: más reuniones no significan mayor control.
  • Tasa de adopción de la herramienta: sin relacionarla con productividad es solo un número decorativo.

Enfócate en los indicadores de valor; los demás pueden servir para diagnóstico interno pero no para la evaluación final.

Cómo tomar la medida de partida

Sin una línea de base clara, cualquier comparación posterior carece de sentido. Registra los siguientes datos antes de iniciar el proyecto o de cambiar de modelo de propiedad:

1. Costos operativos actuales
   • Salario promedio del equipo de TI involucrado (incluye beneficios).
   • Gastos de licencias y suscripciones vinculadas al software existente.
2. Tiempo de respuesta a incidencias
   • Promedio de horas entre la apertura y el cierre de tickets críticos en los últimos 3 meses.
3. Frecuencia de cambios
   • Número de releases menores y mayores realizados en el último semestre.
4. Nivel de dependencia
   • % de funcionalidades que requieren acceso al código fuente del proveedor.
5. Cumplimiento regulatorio
   • Número de incidencias detectadas en auditorías de SUNAT en el último año.

Documenta todo en una hoja de cálculo o en un tablero de BI que permita comparaciones mes a mes. Esta base será el punto de referencia para medir la evolución.

Cuándo se nota el cambio

Los efectos de la propiedad del código no aparecen de inmediato. A continuación, los plazos típicos observados en empresas peruanas que han adoptado esta estrategia:

• Primeras 4‑6 semanas: reducción del TRI en un 10‑15 % gracias a que el equipo interno ya conoce la arquitectura y puede aplicar hot‑fixes sin esperar al proveedor.
• 8‑12 semanas: descenso del CMM en un 20‑30 % al eliminar honorarios de soporte externo y al optimizar procesos internos.
• 12‑20 semanas: incremento de la VDF de 0,8 a 1,2 story points por sprint, ya que los desarrolladores pueden priorizar directamente en el backlog.
• 6‑9 meses: mejora del IO, pasando de un 35 % de cambios dependientes a un 70 % de cambios autónomos.
• A partir del noveno mes: auditorías de SUNAT muestran cero incidencias relacionadas con la facturación electrónica, indicando que el control interno es suficiente.

Estos rangos son promedio; proyectos con equipos ya capacitados pueden experimentar mejoras antes, mientras que organizaciones con alta rotación pueden tardar más.

Qué hacer si los números no salen

Cuando los indicadores no reflejan la mejora esperada, es crucial diferenciar entre un proyecto mal ejecutado y una medición incorrecta.

1. Revisa la calidad de los datos
   • Verifica que los tickets de incidencia estén categorizados de forma consistente.
   • Asegúrate de que los costos contabilizados incluyan todos los rubros (por ejemplo, costos indirectos de infraestructura).
2. Analiza la causa raíz
   • ¿El equipo interno carece de conocimientos críticos? Considera una capacitación focalizada en la arquitectura del sistema.
   • ¿Existen cuellos de botella en los procesos de despliegue? Implementa pipelines de CI/CD para acelerar entregas.
3. Ajusta el alcance del proyecto
   • Si el objetivo era reducir el CMM en 30 % y solo lograste 10 %, revisa si el alcance original era realista dadas las capacidades del personal.
4. Define un nuevo horizonte de evaluación
   • Algunas mejoras, como la independencia operativa, requieren de 9‑12 meses para consolidarse. Extiende la ventana de medición antes de concluir.
5. Escala o pivota
   • Si tras 6 meses los indicadores siguen estancados, evalúa si mantener la propiedad del código sigue siendo la mejor opción o si conviene volver a un modelo de dependencia con cláusulas de salida más favorables.

En cualquier caso, documenta el proceso de revisión para que la alta dirección tenga claridad sobre los motivos del desempeño y pueda tomar decisiones informadas.

Conclusión

Medir la rentabilidad de la propiedad del código frente a la dependencia del proveedor no es cuestión de observar un solo número, sino de construir una línea de base sólida, seguir indicadores de valor y respetar plazos realistas. Si al cabo de ocho meses los indicadores de tiempo de resolución, costo de mantenimiento y velocidad de entrega no muestran la mejora esperada, es momento de revisar procesos, capacitar al equipo o replantear la estrategia. Con datos claros y plazos definidos, tu empresa podrá decidir con confianza si la inversión en código propio está generando el retorno esperado.