¿Cómo medir si el soporte y mantenimiento

En tu empresa ya has elegido a un proveedor de software y ahora te preguntas si el soporte y mantenimiento de software está entregando los resultados esperados. En este artículo encontrarás los indicadores que realmente importan, cómo establecer la línea de base, en qué momento observar los cambios y qué hacer cuando los números no coinciden con lo planeado.

Qué medir y qué no

• Indicadores de valor real

  • Tiempo medio de resolución (TMR): minutos o horas que tarda el equipo de soporte en cerrar un ticket crítico. Un TMR de 4 h o menos es habitual en proyectos críticos; si supera 12 h, el servicio está bajo el umbral aceptable.
  • Disponibilidad del sistema (Uptime): porcentaje de tiempo que la aplicación está operativa. En entornos de facturación electrónica y SUNAT, el objetivo es ≥ 99,5 % mensual.
  • Número de incidencias recurrentes: tickets que se repiten con la misma causa raíz. Un 10 % del total indica que el problema no se está corrigiendo de forma estructural.
  • Cumplimiento de SLA de actualizaciones: porcentaje de entregas de parches o mejoras dentro del plazo acordado (por ejemplo, 2 semanas). Un cumplimiento ≥ 95 % muestra disciplina del proveedor.

• Métricas de vanidad

  • Cantidad de tickets abiertos sin diferenciar severidad. Un alto número de tickets menores puede inflar la percepción de problemas sin impactar el negocio.
  • Horas de soporte facturadas. No indica eficiencia; solo refleja cuánto se está cobrando.
  • Número de funcionalidades entregadas en el periodo de mantenimiento. Sin correlacionar con la utilidad real, es solo ruido.

Dato: Lo que realmente refleja la calidad del soporte es la combinación de TMR, uptime y reducción de incidencias recurrentes.

Cómo tomar la medida de partida

Antes de firmar el contrato, registra los siguientes datos para tener una referencia clara:

• Estado actual del uptime: revisa los logs de los últimos 30 días y calcula el porcentaje de disponibilidad.
• Volumen de tickets: clasifica los últimos 60 días por severidad (crítica, alta, media, baja) y anota el tiempo promedio de cierre.
• Costos de interrupción: cuantifica en minutos el tiempo que cada parada de sistema le cuesta a tu operación (por ejemplo, retraso en la emisión de comprobantes electrónicos).
• Nivel de documentación: verifica que el proveedor haya entregado manuales, diagramas de arquitectura y registro de versiones. Sin esta base, cualquier comparación será imprecisa.

Guarda esta información en una hoja de cálculo o herramienta de gestión de incidencias; será la línea de base contra la que medirás la evolución.

Cuándo se nota el cambio

Los efectos del soporte y mantenimiento no aparecen de inmediato. Aquí tienes los plazos típicos en el contexto peruano:

• Primeras 2 semanas: se observan mejoras en la respuesta de tickets críticos si el proveedor ha implementado un portal de incidencias propio. Un TMR inferior a 6 h en este periodo ya indica un proceso ágil.
• 30 días: la disponibilidad del sistema debería estabilizarse en ≥ 99,5 %. Si la facturación electrónica sigue generando rechazos de SUNAT, el soporte aún no está cumpliendo.
• 60‑90 días: la tasa de incidencias recurrentes debería haber descendido al menos un 30 % respecto a la línea de base. Este descenso muestra que se están corrigiendo causas raíz y no solo parcheando.
• 180 días: el cumplimiento de SLA de actualizaciones debe rondar el 95 %. Además, el costo de interrupción debería haberse reducido en al menos un 15 % gracias a menos paradas inesperadas.

Dato: En proyectos de ERP para pymes peruanas, la mejora visible en uptime y TMR suele consolidarse entre el mes y el trimestre.

Qué hacer si los números no salen

1. Revisa la medición
   • Verifica que los tickets se estén clasificando correctamente. Un error de categorización inflará el TMR.
   • Asegúrate de que el cálculo de uptime incluya solo los horarios productivos de tu empresa; de lo contrario, el porcentaje puede estar sobreestimado.
2. Identifica la causa raíz
   • Si el TMR sigue alto, revisa si hay cuellos de botella internos (por ejemplo, falta de información del usuario) que el proveedor no puede controlar.
   • Analiza si las incidencias recurrentes comparten la misma dependencia tecnológica (p. ej., una API de la SUNAT). En tal caso, la solución pasa por renegociar la integración.
3. Escala según el contrato
   • Consulta los niveles de escalamiento definidos en el SLA. Si el proveedor no cumple en 48 h, activa el proceso de escalado a gerencia de cuenta.
   • Documenta cada incumplimiento; un registro continuo sirve de evidencia para renegociar términos o, en última instancia, considerar cómo cambiar de proveedor de software.
4. Ajusta la expectativa
   • Algunas mejoras (por ejemplo, la reducción de incidencias de bajo nivel) pueden requerir más de 180 días. Revisa si el contrato contempla revisiones trimestrales de métricas.
   • Si el soporte está alineado con los indicadores críticos pero falla en métricas de vanidad, no es necesario cambiar de proveedor; simplemente comunica que esas métricas no forman parte del alcance.

Conclusión

Medir si el soporte y mantenimiento de software ha valido la pena exige una línea de base clara, indicadores enfocados en tiempo de respuesta, disponibilidad y reducción de incidentes, y una visión de plazos realista. Si al cabo de seis meses los números siguen por debajo de los umbrales acordados, la causa suele estar en la medición o en la ejecución del proveedor; solo entonces vale la pena explorar opciones de cambio. Con datos concretos, tu empresa podrá decidir con fundamento si continuar la relación o buscar una alternativa que garantice la continuidad operativa y el cumplimiento de requisitos como la facturación electrónica de SUNAT.