Nuestras Opiniones

Los sistemas de información del gobierno no fallan porque la tecnología sea «demasiado difícil». Fallan porque el problema no está definido, no se entiende a los usuarios y las decisiones se retrasan hasta que el proyecto se convierte en un objetivo móvil. Un período de planificación de 90 días impone la disciplina: no tienes tiempo para ir a la perfección, sino que necesitas opciones claras, un alcance realista y un plan que se pueda construir.

Este artículo establece una hoja de ruta mínima viable: el conjunto mínimo de pasos y resultados que hacen que un sistema de información gubernamental sea financiable, adquirible e implementable, sin ahogar a los equipos en el papeleo.

Qué significa realmente «hoja de ruta mínima viable»

Una hoja de ruta no es un conjunto de diapositivas con aspiraciones. Es una herramienta de toma de decisiones.

En 90 días, su objetivo es lograr la claridad suficiente para que los líderes puedan aprobar la dirección, los responsables del presupuesto puedan ver los factores que impulsan los costos, el departamento de TI pueda validar la viabilidad y el departamento de adquisiciones pueda lanzar una licitación creíble. Si sus resultados no se pueden usar para tomar decisiones, no son resultados de la hoja de ruta, sino documentación.

El punto de referencia es simple: el día 90, deberías poder responder, en un lenguaje sencillo, qué estamos creando, para quién es, cómo funcionará, cuánto costará, cómo lo entregaremos y cómo mediremos el éxito.

La estructura de 90 días (sin tonterías)

Piensa en la obra en cuatro sprints. Cada sprint termina con resultados concretos que reducen el riesgo.

Días 1 a 10: Alinee el propósito y la autoridad

Empieza por definir el «por qué» y el «quién decide». Aquí es donde muchos proyectos fracasan silenciosamente: cinco agencias comparten el mismo sistema, pero nadie es el propietario de las decisiones.

Lo que necesitas es una carta de proyecto breve en la que se nombre al patrocinador, al propietario del producto, al modelo de gobierno y al ritmo de toma de decisiones. Combínalo con una exposición clara del problema (qué es lo que está mal hoy, para quién y a qué costo). Si no puedes escribirlo en media página, no estás preparado para diseñar nada.

Días 11 a 30: Descubra los usuarios, los procesos y las restricciones

Este sprint gira en torno a la realidad. Usted mapea el servicio tal como existe: recorridos de los usuarios, pasos del proceso, cuellos de botella y puntos problemáticos en materia de datos. El objetivo no es documentarlo todo, sino identificar los pocos momentos que provocan el 80% de los retrasos, las quejas o las filtraciones.

Al final de este sprint, deberías tener validados los recorridos de los usuarios, una lista de los casos de uso prioritarios y una visión clara de las limitaciones que determinarán la solución: obligaciones legales, protección de datos, límites de conectividad, sistemas heredados y capacidad operativa.

Días 31 a 60: Diseñe el «sistema mínimo viable»

Ahora traduces las necesidades en algo que se pueda construir. El cambio más importante en este caso es la disciplina: su sistema debe ofrecer un servicio mínimo viable, no todas las funciones que todas las partes interesadas desean.

Aquí es donde se definen los requisitos funcionales de manera que las compras y los proveedores puedan fijar precios, sin dejar de tener margen para la iteración. También decides con antelación si vas a crear, comprar o configurar, y qué integraciones no son negociables. Un diagrama de arquitectura simple que muestre los flujos de datos y la propiedad suele ser más útil que 40 páginas de texto.

Para el día 60, necesita tener un borrador del plan de solución: alcance, módulos, funciones, esquema del modelo de datos, necesidades de integración, enfoque de seguridad y un modelo operativo realista para la institución que lo administrará.

Días 61 a 90: convierta el plan en algo que pueda financiarse y adquirirse

Aquí es donde las hojas de ruta se hacen realidad. Usted convierte el plan en un plan de entrega: secuenciación, asignación de recursos, costos, estrategia de adquisición y gobierno de la implementación.

Fundamentalmente, usted define lo que significa «hecho». Si no puedes medir la adopción y la calidad del servicio, acabarás midiendo solo resultados como la «cantidad de capacitaciones impartidas». Tu paquete para el Día de los 90 debe incluir los KPI, un enfoque de supervisión y un plan de gestión del cambio que trate la adopción como una característica del producto, no como una idea de último momento.

Los productos que más importan (y por qué)

Una hoja de ruta de 90 días no necesita cientos de páginas, pero sí algunos artefactos de alto rendimiento:

1) Una descripción del servicio de una página.
Qué hará el sistema, para quién y el valor que desbloquea. Esto es lo que los altos funcionarios recuerdan y repiten.

2) Una lista de los «10 casos de uso principales» con criterios de aceptación.
Si el sistema no puede ofrecer estos casos de uso de manera confiable, no es el sistema correcto.

3) Una nota sobre datos e interoperabilidad.
Qué conjuntos de datos existen y cuáles no, quién los posee y qué debe integrarse con qué. Esto evita sorpresas costosas en el futuro.

4) Una base de seguridad y privacidad.
No se trata de una auditoría completa, sino de normas mínimas claras: control de acceso, registro, respuesta a incidentes, requisitos de alojamiento y restricciones de cumplimiento.

5) Una hoja de ruta de entrega con los costos y la ruta de adquisición.
Las fases, las hipótesis de personal, los rangos de CAPEX/OPEX y lo que se puede contratar ahora y qué se puede contratar más adelante.

Estos resultados generan rentabilidad porque reducen la incertidumbre, que es la razón principal por la que las compras públicas de TI atraen ofertas débiles o precios inflados.

Trampas comunes (y cómo evitarlas)

Trampa 1: Intentar digitalizar el caos.
Si el proceso subyacente se interrumpe, digitalizarlo solo acelera la falla. En el período de 90 días, céntrese en la «mejora mínima viable del proceso» para los puntos más problemáticos.

Trampa 2: Tratar la consulta con las partes interesadas como una forma de crear consenso.
No es necesario que todos estén de acuerdo; se necesita que todos sean escuchados y que haya una autoridad clara para decidir. La gobernanza es la columna vertebral del producto.

Trampa 3: ignorar el modelo operativo.
Un sistema sin un propietario real, una línea presupuestaria, una capacidad de soporte y una administración de datos reales es un proyecto piloto que nunca se amplía. Defina el hogar institucional con antelación.

Trampa 4: ningún proveedor puede fijar el precio de los requisitos de redacción.
Evite un lenguaje vago como «moderno, sólido y fácil de usar». Conviértalo en requisitos mensurables: tiempo de respuesta, tiempo de actividad, estándares de accesibilidad, registros de auditoría, funciones de usuario y necesidades de presentación de informes.

Cómo se ve esto en la práctica: una nota de la experiencia de Aninver

En todas nuestras tareas en el sector público y digital, que van desde el mantenimiento de la plataforma web CPIA del Banco Africano de Desarrollo hasta el diseño de programas de capacitación y creación de capacidades digitales en el Caribe y el apoyo a las instituciones públicas con plataformas web y herramientas de comunicación digital, el patrón es constante: los proyectos avanzan más rápido cuando los equipos se comprometen con un alcance mínimo viable, una gobernanza clara y datos utilizables desde el primer día.

Si su institución está planificando un sistema de información y quiere una hoja de ruta que realmente pueda adquirirse e implementarse, explore más trabajos y artículos de Aninver sobre la transformación digital y la prestación del sector público, donde compartimos enfoques prácticos, lecciones aprendidas y herramientas que ayudan a los proyectos a pasar de la intención a la ejecución.