Mantenimiento de software municipal: cómo contratar soporte y evolutivos para un ayuntamiento

El mantenimiento de software municipal es una parte esencial de cualquier proyecto tecnológico público. Una aplicación puede estar correctamente implantada y dejar de ser fiable pocos meses después si no se actualizan dependencias, no se revisan integraciones, no se corrigen errores o no existe un procedimiento claro para atender incidencias y evolutivos.

En un ayuntamiento, además, el software suele formar parte de procesos que no pueden detenerse fácilmente: registro, expedientes, firma, notificaciones, portales internos, cuadros de mando, automatizaciones o servicios de atención. Por eso el mantenimiento no debería tratarse como una bolsa indefinida de horas, sino como un servicio con alcance, niveles de servicio, documentación y responsabilidades medibles.

Cuando la entidad utiliza software a medida para Administraciones Públicas, conectores o aplicaciones internas, definir el mantenimiento desde el inicio reduce dependencia del proveedor y mejora la continuidad.

Qué incluye realmente el mantenimiento de software

El concepto engloba varias actividades diferentes. El mantenimiento correctivo resuelve errores; el preventivo busca evitar fallos futuros; el adaptativo responde a cambios de sistemas externos o normativa técnica; y el evolutivo incorpora nuevas funcionalidades.

Separar estos conceptos es importante porque cada uno tiene una forma distinta de planificarse y presupuestarse. Una incidencia que impide registrar expedientes no puede gestionarse igual que una nueva petición para añadir un informe.

El contrato debe indicar qué categorías están incluidas, cómo se solicitan y cómo se mide su ejecución.

Cuándo necesita un ayuntamiento un contrato de mantenimiento

Siempre que una aplicación sea relevante para la operación diaria y no exista capacidad interna suficiente para mantenerla, resulta recomendable definir un servicio estable.

También es necesario cuando existen integraciones con APIs de terceros, automatizaciones que dependen de interfaces externas o aplicaciones desarrolladas con frameworks y librerías que requieren actualización.

Una auditoría tecnológica municipal puede ayudar a identificar qué sistemas necesitan cobertura prioritaria y cuáles pueden mantenerse con recursos internos.

Inventario de aplicaciones mantenidas

El contrato debería incluir un inventario claro de aplicaciones, módulos, integraciones y entornos. Cada elemento debe indicar versión, tecnología, criticidad, responsable y dependencias.

Esto evita conflictos posteriores sobre si una incidencia pertenece o no al alcance contratado.

El inventario debe actualizarse cuando se añaden nuevos módulos o se retiran componentes.

Mantenimiento correctivo

El correctivo responde a errores que afectan al funcionamiento esperado. El pliego debería clasificar incidencias por severidad y definir tiempos de respuesta y resolución.

Una caída completa del servicio, una integración detenida o un fallo que impide continuar un trámite requieren una prioridad distinta de un problema visual menor.

También conviene diferenciar solución definitiva y workaround temporal cuando sea necesario restaurar el servicio rápidamente.

Mantenimiento preventivo

El preventivo incluye revisiones periódicas de logs, dependencias, consumo de recursos, certificados, copias, errores recurrentes y capacidad.

Su objetivo es detectar degradaciones antes de que se conviertan en incidencias críticas.

La integración de sistemas municipales y APIs necesita especialmente este seguimiento porque los servicios externos pueden cambiar sin que la aplicación principal haya sido modificada.

Mantenimiento adaptativo

Las plataformas externas evolucionan. Puede cambiar una API, una versión del sistema operativo, un certificado, un navegador o un servicio común.

El contrato debe definir cómo se gestionan esas adaptaciones y si están incluidas en una cuota fija o requieren una estimación adicional.

También resulta útil identificar con antelación las dependencias que pueden generar cambios obligatorios.

Mantenimiento evolutivo

Los usuarios detectan nuevas necesidades después de trabajar con una aplicación. El mantenimiento evolutivo permite incorporar mejoras sin iniciar un contrato independiente para cada cambio.

El riesgo aparece cuando cualquier petición se clasifica como evolutivo y consume una bolsa sin criterios claros. Conviene definir cómo se analiza, estima, aprueba y acepta cada mejora.

Los evolutivos importantes deberían tener requisitos y pruebas propias.

SLA: tiempos de respuesta y resolución

Los acuerdos de nivel de servicio deben ser realistas y relacionarse con la criticidad. Una incidencia crítica puede exigir respuesta muy rápida, mientras una consulta funcional puede resolverse en un plazo mayor.

El SLA debería indicar horario de cobertura, canales de entrada, tiempo de primera respuesta, tiempo objetivo de resolución y escalado.

También conviene establecer qué ocurre cuando la causa está en un tercero y el adjudicatario depende de otro proveedor.

Clasificación de incidencias

Una clasificación habitual puede separar crítica, alta, media y baja. Sin embargo, lo importante es definir ejemplos concretos.

Crítica podría ser indisponibilidad total o pérdida de una función esencial; alta, degradación importante sin alternativa; media, error con workaround; y baja, incidencia menor o consulta.

La clasificación evita discusiones durante una situación urgente.

Mesa de ayuda y canales de soporte

El contrato debe definir cómo se registran incidencias. Puede utilizarse una plataforma de tickets, correo específico o portal de soporte.

Las solicitudes deberían conservar fecha, usuario, descripción, prioridad, estado y solución.

Esto permite medir el servicio y detectar problemas recurrentes.

Monitorización proactiva

Cuando la aplicación es crítica, esperar a que un usuario avise puede ser insuficiente. La monitorización puede comprobar disponibilidad, errores, latencia, colas, uso de recursos y estado de integraciones.

Las alertas deben enviarse a responsables adecuados y evitar ruido excesivo.

Un cuadro de mando técnico facilita al ayuntamiento comprobar el estado general sin depender únicamente del proveedor.

Logs y trazabilidad

Los logs son esenciales para investigar fallos, pero deben diseñarse correctamente. Deben incluir contexto suficiente sin almacenar información sensible innecesaria.

La política debe definir conservación, acceso y mecanismos de búsqueda.

La trazabilidad es especialmente relevante en automatizaciones de procesos municipales, donde un fallo puede afectar a múltiples expedientes.

Actualización de dependencias

Frameworks, librerías, runtimes y paquetes reciben actualizaciones de seguridad y compatibilidad. Mantener versiones antiguas indefinidamente aumenta riesgo.

El adjudicatario debería revisar dependencias periódicamente y proponer ventanas de actualización cuando exista impacto.

Las actualizaciones relevantes deben probarse antes de producción.

Gestión de vulnerabilidades

El mantenimiento debe contemplar la respuesta ante vulnerabilidades que afecten a componentes utilizados.

El contrato puede establecer tiempos máximos para evaluar avisos críticos y aplicar mitigaciones o parches.

La guía sobre ENS para ayuntamientos ayuda a integrar estas tareas en la gestión global de seguridad.

Copias de seguridad

Debe quedar claro quién realiza backups, qué se copia, con qué frecuencia y durante cuánto tiempo. Si la infraestructura pertenece a otro proveedor, las responsabilidades deben coordinarse.

Las copias solo son fiables cuando existen pruebas de restauración.

El mantenimiento debería incluir verificaciones periódicas de recuperación cuando el servicio lo requiera.

Continuidad y recuperación

Las aplicaciones críticas necesitan procedimientos para restaurar servicio tras una incidencia grave.

Conviene definir prioridades, responsables, objetivos de recuperación y dependencias externas.

La documentación debe ser utilizable por otro equipo y no depender exclusivamente del conocimiento de una persona.

Certificados y credenciales

Muchas integraciones utilizan certificados, tokens o secretos con fecha de expiración. El mantenimiento debe incluir un inventario y alertas suficientes para renovarlos a tiempo.

Una credencial caducada puede detener un proceso aunque el código no tenga ningún error.

Los secretos deben almacenarse de forma segura y evitar cuentas personales.

Mantenimiento de APIs y conectores

Las integraciones son uno de los componentes que más cambios externos sufren. El proveedor debe conocer versiones, endpoints y dependencias.

La guía de APIs municipales explica por qué versionado, documentación y pruebas son fundamentales.

Los cambios de terceros deben probarse en entorno controlado siempre que sea posible.

Mantenimiento del gestor de expedientes e integraciones documentales

Cuando el software trabaja con expedientes, documentos o firma, deben revisarse especialmente metadatos, validaciones y conexiones con servicios comunes.

La guía sobre expediente electrónico municipal ayuda a identificar componentes que no pueden degradarse sin afectar a la tramitación.

También es importante comprobar que las actualizaciones no alteran firmas ni exportaciones.

Mantenimiento de firma electrónica

Los certificados caducan y los servicios de validación evolucionan. El soporte debe contemplar renovación, configuración y pruebas de los circuitos.

La guía sobre firma electrónica en ayuntamientos permite revisar estos puntos.

Una incidencia de firma puede bloquear numerosos procedimientos, por lo que suele requerir alta prioridad.

Accesibilidad después de publicar

La accesibilidad puede degradarse cuando se añaden módulos o componentes. El mantenimiento debe revisar que nuevas interfaces no introducen barreras.

La guía de accesibilidad web municipal ayuda a establecer criterios de regresión.

Las mejoras de interfaz deben incluir comprobaciones manuales y automáticas cuando proceda.

Rendimiento y capacidad

El uso de una aplicación puede crecer con el tiempo. La monitorización debe detectar consultas lentas, consumo de memoria, almacenamiento y cuellos de botella.

Antes de ampliar infraestructura conviene identificar la causa real.

Las métricas permiten decidir si es necesario optimizar código, base de datos o recursos.

Base de datos

El mantenimiento puede incluir revisión de consultas, índices, tamaño, copias y consistencia.

Las operaciones de mantenimiento deben planificarse para evitar impacto en horario crítico.

También debe controlarse el crecimiento de tablas de logs o históricos.

Entornos de desarrollo y pruebas

Las correcciones y evolutivos no deberían aplicarse directamente en producción sin validación.

El proveedor necesita entornos adecuados o procedimientos equivalentes que permitan probar cambios.

La separación reduce riesgo y facilita reversión.

Despliegues y reversión

Cada despliegue debería quedar registrado con versión, cambios y responsable. En aplicaciones críticas conviene disponer de un procedimiento de rollback.

La automatización de despliegues puede reducir errores, siempre que exista control.

La documentación debe permitir entender qué versión está activa en cada entorno.

Repositorio de código

El código fuente debe mantenerse en control de versiones y con acceso definido para la entidad cuando corresponda.

La documentación sobre ramas, releases y despliegue facilita la continuidad.

Este punto es especialmente importante si el mantenimiento lo asume un proveedor distinto del desarrollador original.

Onboarding de un nuevo mantenedor

Cuando cambia el proveedor, debe existir una fase de transición para revisar arquitectura, repositorios, infraestructura, integraciones e incidencias abiertas.

La migración de sistemas municipales muestra la importancia de preparar la salida desde el inicio.

El proveedor anterior debería entregar documentación y activos conforme al contrato.

Documentación viva

Un manual entregado una vez y nunca actualizado pierde valor. El mantenimiento debe contemplar diagramas, dependencias, procedimientos y runbooks actualizados.

También conviene documentar decisiones relevantes y problemas conocidos.

El conocimiento debe permanecer en repositorios accesibles a la entidad.

Bolsa de horas: cuándo funciona

Una bolsa puede ser útil para evolutivos pequeños y necesidades variables. Sin embargo, debe existir un mecanismo de estimación, aprobación y consumo transparente.

No debería utilizarse para sustituir obligaciones básicas de soporte incluidas en una cuota.

El ayuntamiento necesita conocer saldo, trabajos ejecutados y horas pendientes.

Cuota fija y servicios incluidos

Una cuota periódica puede cubrir soporte, monitorización, actualizaciones, revisiones y un determinado nivel de atención.

El pliego debe detallar exactamente qué incluye para evitar que cualquier actuación termine facturándose aparte.

Puede combinarse con una bolsa de evolutivos para cambios no previstos.

Indicadores del servicio

Algunos KPI útiles son número de incidencias, tiempo de primera respuesta, tiempo de resolución, reincidencia, disponibilidad, errores de integraciones y cumplimiento de SLA.

También conviene medir evolutivos entregados y desviaciones de estimación.

El objetivo no es generar métricas por sí mismas, sino detectar degradación y mejorar el servicio.

Reuniones de seguimiento

En servicios relevantes puede establecerse una revisión mensual o trimestral con incidencias, cambios, riesgos y planificación.

Estas reuniones deben apoyarse en datos y no convertirse en el único mecanismo de control.

Las decisiones importantes deberían quedar registradas.

Cómo preparar el pliego de mantenimiento

El pliego debe definir inventario, alcance, horarios, SLA, seguridad, monitorización, backups, documentación, herramientas y modelo de evolutivos.

La guía sobre pliego técnico para digitalización de un ayuntamiento ofrece criterios generales para estructurar contratos tecnológicos. También conviene revisar el clúster de contratación pública digital para alinear el mantenimiento con el resto de servicios tecnológicos de la entidad.

También debe quedar clara la transición de entrada y salida del servicio.

Criterios técnicos de adjudicación

Puede valorarse metodología de soporte, monitorización, gestión de cambios, seguridad, continuidad, documentación y transición cuando guarden relación con el objeto.

La experiencia debería centrarse en complejidad y tecnologías comparables, no únicamente en contratos idénticos.

El objetivo es seleccionar un proveedor capaz de mantener el servicio estable y evolucionarlo sin generar dependencia innecesaria.

Qué puede aportar BlackHold Consulting

BlackHold Consulting trabaja en ámbitos que encajan con mantenimiento y evolución de sistemas: digitalización y desarrollo de flujos, automatización de procesos, automatización de tareas administrativas e integración documental.

También dispone de capacidades en procesos complejos, consultoría tecnológica, agentes e integraciones y servicios de automatización. Estas capacidades pueden utilizarse para soporte, evolución e integración de aplicaciones cuando la contratación pública correspondiente así lo determine.

Checklist para contratar mantenimiento

Inventario

¿Están identificados todos los sistemas cubiertos?

SLA

¿Cada criticidad tiene tiempos claros?

Monitorización

¿El proveedor detectará fallos de forma proactiva?

Seguridad

¿Se incluyen parches, secretos y vulnerabilidades?

Backups

¿Está definida la responsabilidad y la restauración?

Evolutivos

¿Existe un proceso transparente de estimación y aprobación?

Documentación

¿Se actualizarán repositorios y procedimientos?

Reversibilidad

¿Otro proveedor podría asumir el servicio sin reconstruir todo el conocimiento?

Preguntas frecuentes

Conclusión

El mantenimiento de software municipal es un servicio de continuidad, no una simple respuesta a incidencias. Debe cubrir prevención, seguridad, integraciones, actualizaciones, documentación y evolución de forma medible.

Un buen contrato permite que el ayuntamiento conozca qué está cubierto, cuánto tarda el proveedor en responder, qué riesgos existen y cómo se incorporan nuevas necesidades.

Cuando una entidad depende de aplicaciones a medida, integraciones o automatizaciones, contar con un equipo capaz de mantener y evolucionar la arquitectura reduce interrupciones y protege la inversión tecnológica a largo plazo.

Fotografía: Christina Morillo / Pexels.