Puntos clave del artículo
Primero el inventario, luego las compras
El listado de sistemas, contratos e integraciones muestra con qué cuenta ya la administración y dónde está el riesgo.
Un único plan de obligaciones
EZD, KSC, KSeF, e-Doręczenia y el Registro Central de Contratos afectan a las mismas personas y al mismo flujo documental.
Presupuesto en el lenguaje del Consejo de Distrito
Obligación legal por un lado, inversión por otro, y el coste de no actuar expresado con claridad.
Responsable de la digitalización
El secretario con un asesor junto a los técnicos informáticos, sin crear un puesto de director de TI.
Zdjęcia ilustracyjne
Este artículo está dirigido a los secretarios de distrito (sekretarz powiatu) y a los starostas, así como a los tesoreros (skarbnik) con quienes se acuerda el presupuesto. La administración de distrito tiene su propia particularidad: numerosos departamentos con sistemas sectoriales propios y registros nacionales, entidades organizativas del distrito y, según la Ley de Ciberseguridad Nacional (KSC), la condición de entidad clave. Por eso, poner orden en TI no es aquí solo una cuestión de comodidad, sino también de cumplimiento de obligaciones.
Por qué en la administración de distrito resulta más difícil
La administración de distrito gestiona trámites que se apoyan en sistemas y registros operados por diversos proveedores e instituciones: matriculación de vehículos, catastro y geodesia, expedientes de construcción, finanzas, personal y registro de entrada. Cada departamento conoce su propio sistema, pero rara vez alguien tiene la visión de conjunto: qué sistemas intercambian datos entre sí, quién es el titular de cada contrato, cuándo termina el soporte del fabricante y qué ocurrirá si el proveedor sube el precio.
De mis conversaciones con administraciones de distrito identifico varias causas recurrentes:
- El conocimiento está disperso. El técnico informático conoce la infraestructura, los departamentos conocen sus aplicaciones, los proveedores conocen sus contratos. Nadie tiene la imagen completa.
- Las obligaciones llegan por separado, pero recaen sobre las mismas personas. KSC, KSeF, e-Doręczenia y el Registro Central de Contratos, junto con la futura obligación del sistema de clase EZD, son en la práctica cambios sobre el mismo flujo documental.
- El departamento de TI es pequeño. Dos o tres personas mantienen el hardware, la red y el trabajo diario de la administración. No tienen tiempo para liderar la selección de un sistema de gran envergadura.
- Las decisiones se toman bajo presión de plazos. En ese momento ya no queda tiempo para comparar ofertas y la administración negocia desde una posición más débil.
Paso 1. Inventario de sistemas y contratos
El primer paso no es elegir un sistema, sino elaborar un listado de lo que la administración ya posee. Un buen inventario responde a preguntas sencillas: qué sistemas funcionan en cada departamento, quién es su titular, con quién está firmado el contrato y hasta cuándo, cuánto cuesta su mantenimiento, qué sistemas intercambian datos entre sí y dónde están los puntos únicos de fallo, es decir, los lugares donde la avería de un elemento o la salida de una sola persona paraliza el trabajo.
El inventario dura de 2 a 6 semanas, se sitúa por debajo del umbral de contratación pública y no requiere acceso a datos de los vecinos. Concluye con una página de síntesis para el starosta y el Consejo Ejecutivo del Distrito (Zarząd Powiatu), además de un conjunto de documentos que servirá de base para cada paso posterior. Más detalles: inventario de sistemas de TI.
Paso 2. Plan de obligaciones de una sola página
A partir del inventario se elabora una página con las obligaciones y los plazos. Junto a cada obligación: quién responde, cuál es el siguiente paso y para cuándo.
- Sistema de clase EZD. Obligación anunciada; según las explicaciones del Ministerio de Digitalización de octubre de 2026, el plazo se ha aplazado como muy pronto a 2029, y la normativa aún está en fase de proyecto. Conviene verificarlo periódicamente, ya que el calendario suele actualizarse.
- KSC. La administración de distrito es una entidad clave en el sentido de la Ley de Ciberseguridad Nacional; parte de las obligaciones tiene sus propios plazos. Por dónde empezar lo explico en el artículo La Ley de KSC en la administración de distrito.
- KSeF y e-Doręczenia. Cambian el flujo de facturas y correspondencia, por lo que afectan a los mismos procesos que el sistema de clase EZD.
- Registro Central de Contratos. Requiere información sobre los contratos que, de todos modos, recopila el inventario; lo explico paso a paso en el artículo Registro Central de Contratos.
El plan de obligaciones funciona como el cronograma de una reforma en un edificio que se sigue utilizando a diario. No se puede renovar la instalación de cada habitación por separado y sin coordinación. Hay que saber qué discurre por cada pared y organizar las obras de modo que la oficina siga funcionando en todo momento.
Paso 3. Un presupuesto defendible ante el Consejo de Distrito
Un presupuesto de TI presentado como una única partida es difícil de defender. Resulta más fácil cuando se divide entre obligación normativa (lo que hay que hacer por imperativo legal) e inversión (lo que la administración hace para trabajar con mayor eficacia), y junto a ello se añade el coste de no actuar: qué ocurrirá si no hacemos nada. El proyecto de presupuesto se elabora en otoño, así que es el mejor momento para preparar esta separación. Más información en el artículo Presupuesto de TI ante el Consejo.
Paso 4. Un responsable de la digitalización sin crear una nueva plaza
Todo proyecto de envergadura necesita un responsable: alguien que vele por el conjunto, los plazos y las decisiones. En una administración de distrito sin director de TI, esa función suele recaer en el secretario, aunque rara vez dispone del tiempo ni de la experiencia necesarios para dirigir la selección de sistemas grandes. En lugar de crear un puesto, esto puede reforzarse con un asesor externo a tiempo parcial: alguien que, semanal o mensualmente, se reúne con el secretario y el responsable de TI, mantiene un registro de proyectos y riesgos, ayuda en las negociaciones con los proveedores y evalúa sus propuestas de forma independiente. Las decisiones siguen correspondiendo a la administración.
En este esquema, el responsable de TI es un aliado, no el objeto de la supervisión. El registro de sistemas y la separación del presupuesto son los mejores argumentos a favor de los recursos que el técnico informático suele llevar tiempo solicitando.
Ejemplo práctico
He visto el mismo mecanismo en una gran unidad de administración local (JST), donde la contraparte dentro de la administración fue el jefe del departamento de informática. La oficina iba acumulando aplicaciones cada vez más numerosas y desconectadas entre sí, pensadas para dar soporte a unidades concretas. Empezamos con un inventario básico de necesidades y sistemas existentes. A partir de ahí se elaboró un mapa de actuaciones orientado a optimizar el coste de los proyectos futuros, y después se sentaron las bases de una estrategia de aplicaciones, traducida en requisitos tecnológicos: un coste total de propiedad óptimo, la reducción del riesgo de dependencia de un único proveedor (vendor lock-in) y un plan para transferir el conocimiento de los proveedores al equipo interno de TI.
La administración adoptó estándares de modelado de procesos, de transferencia de conocimiento entre proveedores y de documentación de requisitos y arquitectura de sistemas, y planificó la estrategia de aplicaciones para los próximos diez años. Lo que más sorprendió fue un hecho concreto: las unidades organizativas que contaban con presupuesto y competencias propias llevaban adelante, en paralelo, sus propias iniciativas informáticas. Ampliaban silos y elevaban los costes de mantenimiento, cuando desde el principio podrían haberse integrado en una única estrategia coherente. Sin el inventario, nadie lo habría detectado.