Este artículo está dirigido a quienes encargan la estrategia, la aprueban o después tienen que ejecutarla: secretarios y tesoreros (skarbnik) de ayuntamientos, presidentes y miembros de consejos de administración de empresas municipales (spółka komunalna), presidentes y directores financieros de empresas, así como responsables de TI que quieren que el documento les sirva por fin para hablar de presupuesto. Sobre los errores típicos en las estrategias de las entidades públicas escribí por separado en el artículo Estrategia de TI en las entidades de la administración local (JST): los errores más frecuentes. Aquí me centro en lo que debe figurar en el propio documento.
Por qué las estrategias acaban en un cajón
Por lo que he visto en organizaciones públicas y privadas, la estrategia rara vez es deficiente en su contenido. Acaba en un cajón porque no se puede usar en la primera decisión concreta que surge.
- Empieza por la visión y no por el inventario. Nadie ha comprobado qué sistemas, contratos y dependencias existen ya, así que el plan se desvía de la realidad en la primera compra.
- Describe objetivos, pero no el orden. Todo es importante, así que nada es prioritario.
- No hay dinero. La falta de vínculo con el presupuesto hace que la estrategia y el plan financiero vivan por separado.
- No cambia la forma de comprar. Los siguientes sistemas se siguen comprando como antes, según las ofertas de los proveedores y no según estándares propios.
- No tiene responsable. El documento se aprobó mediante una resolución o una decisión del consejo, y ahí terminó su vida.
- Está escrita en lenguaje de TI. El consejo de administración y el pleno no encuentran en ella respuesta a sus preguntas: cuánto, para qué, qué pasa si no hacemos nada.
Siete elementos de una estrategia que sí se usa
- Estado actual. Un registro de sistemas con su responsable, contrato, licencia, coste y fecha de fin de soporte, un mapa de procesos e integraciones, y un registro de riesgos. Sin esto, cada punto siguiente es una conjetura. Esta es la tarea de la inventariación.
- Arquitectura objetivo. Una imagen sencilla de cómo se relacionan entre sí los registros, los procesos, las integraciones y los accesos. No se trata de esquemas técnicos, sino de responder a qué sistemas son centrales y cuáles los apoyan, dónde deben generarse los datos y qué sistemas deben heredarlos.
- Estándares. Unas cuantas normas obligatorias en cada compra: cómo se asignan los permisos, qué aspecto debe tener la interfaz para los empleados, cómo se documentan los requisitos, qué derechos sobre los datos debemos tener, qué lenguaje (estándar) usamos para describir los procesos, cómo protegemos la salida de la colaboración.
- Hoja de ruta con separación entre obligación e inversión. Por un lado, lo que debemos hacer porque lo exige la ley o un contrato (en las administraciones, por ejemplo, un sistema de clase EZD —gestión electrónica de documentos y expedientes—, el KSeF —sistema nacional de facturación electrónica— o el e-Doręczenia —entrega electrónica polaca—); por otro, lo que hacemos porque compensa. Con un orden y una justificación. Por ejemplo: una factura descargada del KSeF puede archivarse directamente en el expediente, pero conforme a la ley debería recibir una aprobación de contenido, una verificación formal y contable, y culminar su recorrido con el registro automático en el sistema financiero-contable.
- Presupuesto desglosado entre inversión y mantenimiento. El mantenimiento crece con cada nuevo sistema y debe ser visible antes de que se tome la decisión de compra. Más sobre esto en el artículo sobre el coste total de propiedad (TCO). Recuerde que la implementación suele ser una inversión puntual (CAPEX), pero desde el punto de vista presupuestario, la continuidad operativa y la seguridad dependen, entre otras cosas, del servicio técnico y las actualizaciones (OPEX), que se repiten año tras año.
- Normas de contratación de sistemas. Cuándo se necesita una inventariación o un análisis previo a la compra, quién evalúa la oferta, qué cláusulas deben figurar en el contrato. He descrito parte de ello en el artículo sobre el pliego de condiciones (SWZ) sin dependencia de un proveedor único (vendor lock-in).
- Responsable y ritmo de revisión. Una persona concreta del lado directivo debe revisar la estrategia y los costes de propiedad, como mínimo una vez al año con motivo del presupuesto, respetando una periodicidad clara de estas revisiones.
La prueba más sencilla de una estrategia: ¿puede el tesorero (skarbnik) o el director financiero, al preparar el presupuesto del próximo año, tomar directamente de ella las partidas y su justificación? Si no es así, la estrategia y el presupuesto viven por separado, y el gasto en TI se decide según lo que resulte urgente en cada momento.
Un ejemplo de la práctica
La empresa Wodociągi Miejskie, perteneciente a un municipio de tamaño medio, preparaba el plan de compras de TI para el año siguiente. En un principio, el departamento de TI solicitaba sustituir simultáneamente los ordenadores de oficina, adquirir un nuevo sistema de monitorización y modernizar la infraestructura de red. Sin embargo, el consejo de administración pidió que se demostrara qué gastos eran más urgentes desde el punto de vista de la continuidad del suministro de agua.
La empresa empezó por la inventariación: reunió los equipos, el software, las conexiones de red y los contratos de servicio técnico, y luego los asignó a procesos concretos, desde la atención al cliente hasta el control de las estaciones de tratamiento. Resultó que parte de los dispositivos que intermediaban la comunicación con las estaciones estaban cerca del fin de su periodo de soporte, y la documentación de las conexiones no cubría todas las ubicaciones. Al mismo tiempo, la mayoría de los ordenadores de oficina podían seguir funcionando sin un impacto relevante en los servicios clave.
Sobre esta base se cambió el orden de las compras. En primer lugar, se previó ordenar y proteger las conexiones con las instalaciones tecnológicas y sustituir los equipos cuyo fallo pudiera dificultar el control del suministro de agua. A continuación, se planificó ampliar las copias de seguridad y la monitorización. La sustitución de parte de los ordenadores de oficina se aplazó a una fase posterior.
Ante el consejo de administración, el departamento de TI ya no justificaba el presupuesto con la afirmación genérica de que «el equipo es antiguo». Mostró la relación: componente concreto de la infraestructura → proceso que soporta → consecuencia de un fallo → compra propuesta. Gracias a ello, el consejo de administración pudo aprobar los gastos por etapas y explicar al consejo de vigilancia por qué se dio prioridad a la infraestructura ligada a la continuidad del servicio, y no al equipo de oficina más visible para los empleados.
Cuándo se necesita un asesor independiente
La estrategia puede redactarse con medios propios si en la organización hay alguien con el tiempo necesario y una visión de conjunto. El apoyo externo resulta útil cuando el estado actual no está documentado, cuando la estrategia debe servir de base para defender el presupuesto ante el pleno, el propietario o la sede central, cuando se acumulan varias obligaciones regulatorias a la vez, o cuando el consejo de administración y el departamento de TI ven las prioridades de forma distinta y hace falta alguien que traduzca una perspectiva a la otra.
Preparo la estrategia de digitalización y la arquitectura objetivo a partir de la inventariación: con hoja de ruta, estándares, normas de contratación y un presupuesto defendible.