Este artículo está dirigido a quienes encargan, aprueban o luego deben ejecutar la estrategia: secretarios y tesoreros (skarbnik) en administraciones públicas, presidentes y consejeros de empresas municipales (spółka komunalna), directores generales y directores financieros de empresas, así como responsables de TI que quieren que el documento por fin les ayude en la conversación sobre presupuesto. Sobre los errores típicos en las estrategias de las administraciones locales (JST) escribí por separado en el artículo Estrategia de TI en las JST: los errores más frecuentes. Aquí me centro en qué debe contener 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 está mal planteada a nivel de contenido. Acaba en un cajón porque no se puede utilizar en la primera decisión concreta que se presenta.
- Empieza por la visión, no por el inventario. Nadie comprobó qué sistemas, contratos y dependencias ya existen, así que el plan se aleja de la realidad en la primera compra.
- Describe objetivos, pero no el orden. Todo es importante, así que nada es lo primero.
- No tiene 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 sistemas se siguen comprando como antes, en función de las ofertas de los proveedores y no de estándares propios.
- No tiene responsable. El documento se aprobó mediante una resolución del consejo o del pleno, y ahí terminó su vida útil.
- Está escrita en lenguaje de TI. El consejo de administración y el pleno no encuentran en ella respuesta a sus preguntas: cuánto cuesta, para qué sirve, qué pasa si no hacemos nada.
Siete elementos de una estrategia que sí se utiliza
- Estado actual. Un registro de sistemas con propietario, contrato, licencia, coste y fin del soporte, un mapa de procesos e integraciones, y un registro de riesgos. Sin esto, cualquier otro punto es pura conjetura. Esta es tarea de la inventariación.
- Arquitectura objetivo. Una imagen sencilla de cómo se relacionan entre sí los registros, procesos, integraciones y accesos. No se trata de esquemas técnicos, sino de responder qué sistemas son centrales y cuáles los apoyan, dónde deben generarse los datos y qué sistemas deben heredarlos.
- Estándares. Unas pocas reglas obligatorias en cada compra: cómo asignamos permisos, cómo debe ser la interfaz para los empleados, cómo documentamos los requisitos, qué derechos sobre los datos debemos tener, qué lenguaje (estándar) usamos para describir los procesos, cómo garantizamos la salida de la colaboración.
- Hoja de ruta con distinció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 públicas, por ejemplo, un sistema de tipo EZD, el KSeF o el e-Doręczenia), y por otro lado lo que hacemos porque compensa. Con orden y justificación. Por ejemplo: una factura descargada del KSeF puede guardarse en el expediente, pero conforme a la normativa debería recibir la aprobación de fondo, la verificación formal y contable, y terminar su recorrido con el registro automático en el sistema financiero-contable.
- Presupuesto desglosado en 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. Ten en cuenta que la implantación suele ser una inversión puntual (CAPEX), pero desde el punto de vista presupuestario, la continuidad operativa y la seguridad son, entre otros, el servicio técnico y las actualizaciones (OPEX), que se repiten año tras año.
- Reglas de compra para los sistemas. Cuándo hace falta 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. Parte de esto lo describí en el artículo sobre el pliego de condiciones (SWZ) sin dependencia del proveedor.
- 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 coincidiendo con el presupuesto, respetando una regla clara de periodicidad 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 de ella directamente las partidas y su justificación? Si no es así, la estrategia y el presupuesto viven por separado, y las decisiones de gasto en TI las marca lo que resulta urgente en cada momento.
Ejemplo práctico
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. Al principio, el departamento de TI solicitó sustituir simultáneamente los ordenadores de oficina, comprar 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: recopiló los equipos, el software, las conexiones de red y los contratos de mantenimiento, y a continuación los asignó a procesos concretos, desde la atención al cliente hasta el control de las estaciones de tratamiento. Resultó que parte de los equipos que mediaban en la comunicación con las estaciones estaban cerca del fin de su 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 afectar de forma significativa a los servicios clave.
Sobre esta base se cambió el orden de las compras. Primero se previó ordenar y proteger las conexiones con las instalaciones tecnológicas, así como sustituir los equipos cuyo fallo podría dificultar el control del suministro de agua. A continuación se planificó completar las copias de seguridad y la monitorización. La sustitución de parte de los ordenadores de oficina se pospuso 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 al que da soporte → consecuencia de un fallo → compra propuesta. Gracias a ello, el consejo pudo aprobar los gastos por etapas y explicar al consejo de vigilancia por qué se dio prioridad a la infraestructura vinculada 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 se puede redactar con recursos propios si en la organización hay alguien con el tiempo y la visión de conjunto necesarios. 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 administración central, cuando llegan 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, reglas de compra y un presupuesto que se pueda defender.