Pliego técnico para digitalización de un ayuntamiento: qué debe incluir

Preparar un pliego técnico para la digitalización de un ayuntamiento exige traducir una necesidad administrativa a requisitos que puedan entender, valorar y ejecutar distintos proveedores. Un pliego demasiado genérico genera ofertas difíciles de comparar; uno excesivamente cerrado puede limitar la competencia o encorsetar la solución antes de conocer las alternativas del mercado.

La referencia general para la contratación es la Ley 9/2017, de Contratos del Sector Público, que debe consultarse siempre en su versión vigente. Desde el punto de vista técnico, el pliego debe ser coherente con el objeto, la necesidad, los criterios de adjudicación, los hitos y el modelo de ejecución definido por la entidad.

Un proyecto de digitalización de la Administración Pública no debería comenzar por una lista de funcionalidades aisladas. Antes es necesario conocer procesos, sistemas actuales, integraciones, usuarios, datos, obligaciones de seguridad y resultados esperados.

Qué función cumple el pliego técnico

El Pliego de Prescripciones Técnicas describe las características de la prestación desde el punto de vista funcional y tecnológico. Su función es dejar claro qué debe entregar el adjudicatario y bajo qué condiciones se considerará correctamente ejecutado.

En contratación tecnológica, el pliego también protege a la Administración frente a ambigüedades posteriores. Si no se definieron exportaciones, APIs, migraciones, documentación o soporte, exigirlos durante la ejecución puede ser difícil.

Por eso la preparación técnica debe coordinarse con la memoria justificativa, el PCAP y el resto del expediente, evitando contradicciones entre documentos.

Empezar por la necesidad, no por la herramienta

Antes de escribir requisitos debe describirse el problema. ¿Hay expedientes manuales? ¿Datos duplicados? ¿Sistemas que no se comunican? ¿Demasiadas consultas ciudadanas? ¿Falta de trazabilidad? ¿Dependencia de hojas de cálculo?

La guía sobre errores frecuentes en la digitalización de ayuntamientos muestra por qué seleccionar una herramienta antes de analizar el proceso suele generar sobrecostes.

La necesidad debería expresarse con indicadores. Por ejemplo: reducir pasos manuales, integrar dos sistemas, disponer de trazabilidad, mejorar tiempos de respuesta o eliminar recaptura de datos.

Definir el alcance con precisión

El alcance debe distinguir qué está incluido y qué no. En proyectos de digitalización es frecuente que conceptos como “integración”, “migración” o “automatización” se interpreten de manera diferente.

Conviene enumerar módulos, procesos, departamentos, integraciones, fuentes de datos y colectivos afectados. Si existe una fase piloto, debe indicarse qué resultado habilitará el paso a producción.

La digitalización de ayuntamientos suele afectar a varias áreas, por lo que es útil separar alcance mínimo obligatorio y posibles evolutivos.

Requisitos funcionales

Los requisitos funcionales describen qué debe permitir hacer el sistema o servicio. Deben redactarse desde la perspectiva del proceso y no únicamente desde la interfaz.

Ejemplos: registrar una solicitud, recuperar datos de otro sistema, generar una propuesta, pedir una validación, notificar un resultado, exportar un expediente o consultar un indicador.

La automatización de procesos administrativos funciona mejor cuando cada requisito identifica evento de inicio, reglas, responsables, excepciones y salida esperada.

Requisitos no funcionales

Rendimiento, disponibilidad, seguridad, escalabilidad, usabilidad, accesibilidad, mantenibilidad y portabilidad forman parte de los requisitos no funcionales. Son esenciales porque una aplicación puede cumplir sus funciones y aun así ser inadecuada para producción.

Los requisitos deberían ser medibles. “La aplicación será rápida” es ambiguo; es preferible definir tiempos máximos de respuesta para operaciones críticas o volúmenes de referencia.

También debe indicarse el entorno esperado: nube, infraestructura municipal, modelo híbrido o servicio gestionado.

Interoperabilidad y servicios comunes

Las soluciones municipales no operan aisladas. Pueden necesitar DIR3, SIA, servicios de identificación, firma, registros, intermediación de datos, factura electrónica o sistemas de notificaciones.

Los contenidos sobre DIR3, SIA, Cl@ve y Plataforma de Intermediación de Datos ayudan a identificar dependencias que pueden convertirse en requisitos del pliego.

Es recomendable pedir que las integraciones queden documentadas y que no dependan de mecanismos manuales ocultos.

APIs y acceso a los datos

La Administración debe conservar control sobre sus datos. Si la solución utiliza una base de datos o plataforma propietaria, el pliego debería definir mecanismos de exportación, formatos, frecuencia y condiciones de acceso.

Cuando existan APIs, conviene exigir documentación técnica, autenticación, límites, versionado y entornos de prueba. Una API mencionada comercialmente pero no incluida contractualmente puede no estar disponible después.

La transformación administrativa sostenible necesita interfaces que permitan evolución y cambio de proveedor.

Propiedad del código y desarrollos a medida

Cuando el objeto incluye desarrollo específico, debe definirse qué ocurre con el código fuente, configuraciones, scripts, conectores y documentación. La respuesta dependerá del modelo contractual, pero no debería quedar implícita.

También conviene indicar repositorios, control de versiones, proceso de entrega y documentación de despliegue cuando corresponda.

En proyectos a medida, la continuidad futura mejora si el ayuntamiento recibe los activos necesarios para mantener o transferir el servicio.

Migración de datos

Las migraciones son una de las principales fuentes de desviaciones. El pliego debe indicar qué sistemas origen existen, volumen aproximado, formatos, calidad conocida y responsabilidad sobre limpieza y transformación.

Es recomendable exigir una migración de prueba, informe de incidencias, validación de muestras y reconciliación final. “Migrar todos los datos” sin metodología es una especificación insuficiente.

Cuando existen documentos, deben revisarse metadatos, versiones y vinculación con expedientes.

Esquema Nacional de Seguridad

La seguridad debe incorporarse desde el pliego, no al final del proyecto. Según la naturaleza del sistema y su ámbito, será necesario valorar las obligaciones relacionadas con el Esquema Nacional de Seguridad.

La guía de ENS para ayuntamientos permite identificar medidas de control de acceso, trazabilidad, continuidad, gestión de incidentes y proveedores que pueden afectar al contrato.

El pliego debe diferenciar claramente obligaciones del adjudicatario y responsabilidades que permanecen en la entidad.

Protección de datos

Si el proveedor trata datos personales por cuenta del ayuntamiento, deben definirse las condiciones correspondientes y coordinar el pliego con la documentación jurídica del tratamiento.

Desde el punto de vista técnico conviene especificar ubicación de datos, subencargados, copias, cifrado, logs, eliminación y devolución al finalizar el contrato.

El diseño debe aplicar minimización y no recopilar información que el proceso no necesita.

Accesibilidad y experiencia de usuario

Los servicios dirigidos a ciudadanía y empleados deben considerar accesibilidad y usabilidad. Formularios, tablas, documentos y componentes interactivos deben poder utilizarse en diferentes dispositivos y con tecnologías de asistencia.

La web para ayuntamientos y la sede forman parte de un mismo recorrido ciudadano, por lo que el pliego debería exigir consistencia cuando se integran nuevos servicios.

Las pruebas de aceptación pueden incluir casos reales con usuarios internos y externos.

Niveles de servicio

Cuando el contrato incluye explotación o soporte, los SLA deben definir disponibilidad, tiempos de respuesta y resolución, horarios, severidades y canales.

Es importante distinguir incidencia crítica, alta, media y consulta. Sin una clasificación acordada, proveedor y Ayuntamiento pueden interpretar de forma distinta la prioridad.

Los niveles de servicio deberían tener mecanismos de seguimiento y, cuando proceda, consecuencias contractuales alineadas con el PCAP.

Soporte, mantenimiento y evolutivos

El pliego debe aclarar qué está incluido tras la puesta en producción. Correcciones, actualizaciones, soporte a usuarios, cambios normativos y nuevas funcionalidades son conceptos diferentes.

Si se incluyen bolsas de horas o evolutivos, debe definirse cómo se solicitan, estiman, aprueban y consumen.

La ausencia de este modelo puede provocar que cualquier cambio termine considerado fuera de alcance.

Formación y transferencia de conocimiento

La formación debe adaptarse a roles. Un administrador necesita contenidos distintos de un tramitador o responsable de área.

También es recomendable exigir manuales, vídeos, procedimientos y documentación de operación. La transferencia de conocimiento reduce dependencia y facilita incorporar nuevo personal.

Una solución no está realmente implantada si el equipo interno no sabe operarla.

Entornos de desarrollo, pruebas y producción

Separar entornos reduce riesgo. Los cambios deberían validarse antes de llegar a producción y existir un procedimiento de despliegue y reversión.

El pliego puede definir responsabilidades sobre infraestructura, backups, monitorización y mantenimiento de cada entorno.

En integraciones con servicios comunes, disponer de pruebas controladas evita afectar a expedientes reales.

Criterios de aceptación

Cada entregable importante debe tener una forma objetiva de aceptación. Puede ser una demostración funcional, batería de pruebas, informe, rendimiento mínimo o validación de datos.

La aceptación no debería basarse únicamente en que “la aplicación funciona”. Es necesario comprobar escenarios normales, errores, permisos, cargas y procesos de contingencia.

La entidad puede utilizar matrices de trazabilidad que relacionen requisito, prueba y resultado.

Consultas preliminares y pruebas de concepto

Cuando el mercado tecnológico es complejo o la entidad no conoce bien las alternativas disponibles, puede resultar útil explorar soluciones antes de cerrar definitivamente las prescripciones, siempre dentro de los mecanismos legalmente previstos y preservando la igualdad de trato. El objetivo debe ser comprender modelos de prestación, integraciones habituales, costes de transición y riesgos técnicos, no diseñar el expediente alrededor de un proveedor concreto.

En proyectos especialmente novedosos puede plantearse una prueba de concepto o fase piloto dentro de una estructura contractual adecuada. El pliego debería definir datos de prueba, alcance limitado, métricas de éxito, duración, condiciones de paso a producción y tratamiento de los activos generados. Una demo comercial no sustituye a una prueba con criterios objetivos.

Evitar el vendor lock-in

La dependencia de proveedor puede aparecer por formatos cerrados, integraciones no documentadas, licencias imprescindibles o ausencia de acceso a código y configuraciones.

El pliego debería analizar qué activos necesitaría el ayuntamiento para continuar el servicio con otro proveedor al finalizar el contrato.

La portabilidad es especialmente importante en proyectos estratégicos y de larga duración.

Plan de salida y reversibilidad

El contrato debería prever qué ocurre al finalizar la prestación o al cambiar de adjudicatario. Es recomendable definir exportación de datos y documentos, entrega de configuraciones y documentación, transferencia de conocimiento y colaboración durante la transición. Si existen integraciones, también debe especificarse cómo se entregan claves institucionales, endpoints, esquemas y procedimientos de despliegue.

Esta fase de reversibilidad evita que un cambio de proveedor se convierta en un proyecto de recuperación de información. La estrategia de salida debe pensarse al redactar el pliego, no cuando el contrato está a punto de vencer.

Presupuesto y estimación del esfuerzo

El presupuesto debe guardar relación con el alcance. Si se solicitan integraciones complejas, migraciones, soporte prolongado y desarrollo a medida con un presupuesto muy reducido, el mercado puede responder con pocas ofertas o propuestas de baja calidad.

Un estudio previo de mercado puede ayudar a entender modelos de prestación, rangos y dependencias sin convertir la preparación en una especificación dirigida.

La contratación pública digital debe equilibrar competencia, calidad y sostenibilidad del servicio.

Criterios técnicos de adjudicación

Los criterios deben permitir diferenciar calidad real. Puede valorarse metodología, arquitectura, plan de migración, enfoque de seguridad, usabilidad, soporte o capacidad de integración cuando guarden relación con el objeto y estén correctamente definidos.

Los criterios subjetivos deben describir qué aspectos se evaluarán. Una frase genérica como “calidad de la propuesta” dificulta una valoración consistente.

También conviene evitar premiar documentos excesivamente largos que no aportan evidencia adicional.

Preparar el pliego para automatización e IA

Si el proyecto incluye automatización, el pliego debe describir procesos, reglas, excepciones y supervisión. Si incorpora IA, deben añadirse métricas de calidad, gobernanza de datos y mecanismos de revisión humana.

La IA en servicios públicos requiere más control que una simple integración de software porque los resultados pueden depender de modelos y datos.

Conviene separar claramente qué decisiones son deterministas y cuáles dependen de sistemas de IA.

Cómo puede encajar BlackHold Consulting

Para una entidad que está preparando o ejecutando proyectos de modernización, BlackHold Consulting trabaja en áreas como digitalización y automatización de flujos, automatización de procesos con IA, automatización de tareas administrativas y consultoría estratégica tecnológica.

También resultan relevantes sus capacidades en automatización documental, automatización de procesos complejos, agentes de IA y servicios de automatización. La eventual contratación debe realizarse mediante el procedimiento que corresponda y con criterios objetivos definidos por la Administración.

Checklist del pliego técnico

Necesidad

¿Está descrito el problema que se quiere resolver?

Alcance

¿Se entiende qué incluye y qué queda fuera?

Integraciones

¿Se han inventariado sistemas y servicios comunes?

Datos

¿Se define migración, exportación y propiedad?

Seguridad

¿Se han incluido ENS, accesos, logs y continuidad?

Aceptación

¿Cada entregable tiene pruebas verificables?

Soporte

¿Se conocen SLA, mantenimiento y evolutivos?

Salida

¿El ayuntamiento puede cambiar de proveedor sin perder datos ni conocimiento?

Preguntas frecuentes

Conclusión

Un pliego técnico de digitalización municipal debe reducir ambigüedad y convertir una necesidad pública en una prestación verificable. Alcance, integraciones, datos, seguridad, migración, soporte y criterios de aceptación son tan importantes como las funcionalidades visibles.

La calidad del pliego condiciona la calidad de las ofertas y de la ejecución posterior. Cuanto mejor se definen dependencias y resultados, menor es el riesgo de sobrecostes, bloqueos y discrepancias.

Para proyectos complejos, disponer de apoyo técnico especializado antes y durante la contratación puede ayudar a estructurar requisitos realistas y preparar una implantación que mantenga interoperabilidad, seguridad y control público sobre los activos digitales.

Fotografía: Mikhail Nilov / Pexels.