Qué debe incluir el diagnóstico de un sistema a medida

Un sistema a medida no debería comenzar con una lista de pantallas. Primero hay que entender qué operación se quiere mejorar, quién participa, qué reglas ya existen y cómo se comprobará que la solución realmente funciona. Ese trabajo previo es el diagnóstico.

1. El problema y el resultado esperado

La primera parte describe la situación actual sin asumir todavía una tecnología. Conviene separar el síntoma —por ejemplo, información duplicada— de la causa: capturas independientes, reglas ambiguas o responsabilidades que nadie tiene asignadas.

• Qué actividad genera el problema y con qué frecuencia ocurre.
• A quién afecta y qué consecuencia operativa produce.
• Qué debería cambiar después de implementar la solución.
• Qué evidencia permitirá confirmar la mejora.

2. El proceso real, incluidas sus excepciones

Un diagrama ideal no basta. El diagnóstico debe registrar cómo entra una solicitud, quién la revisa, qué decisiones se toman, qué información cambia y cómo termina el flujo. También debe incluir lo que ocurre cuando faltan datos, una autorización se rechaza o un servicio externo no responde.

Las excepciones suelen definir más trabajo de software que el recorrido normal. Si no se documentan, reaparecen durante las pruebas como cambios urgentes.

3. Usuarios, roles y responsabilidades

Cada tipo de usuario necesita acciones y visibilidad diferentes. Una matriz sencilla de roles evita que “todos puedan hacer todo” y ayuda a distinguir operación, supervisión, administración y soporte.

• Quién captura, consulta, valida, corrige, autoriza y administra.
• Qué información puede ver cada rol y en qué momento.
• Qué acciones requieren confirmación o una segunda autorización.
• Qué debe quedar registrado para auditoría y diagnóstico.

4. Reglas de negocio y prioridades

Las reglas convierten el proceso en comportamiento verificable: campos obligatorios, cálculos, transiciones permitidas, límites, alertas y condiciones de cierre. Deben redactarse con ejemplos y asignar un responsable que pueda resolver dudas.

También conviene priorizar. Una primera versión debe resolver el núcleo operativo; las funciones que no cambian el resultado principal pueden programarse para una etapa posterior sin perderse del mapa.

5. Datos, documentos e integraciones

El diagnóstico identifica qué datos existen, de dónde provienen, quién los mantiene y cuánto tiempo se conservan. Si hay archivos históricos, se evalúa su calidad antes de prometer una migración automática.

Para cada integración con otro sistema conviene registrar:

• Responsable técnico y ambiente disponible para pruebas.
• Método de conexión, autenticación y límites de uso.
• Datos enviados y recibidos, frecuencia y validaciones.
• Comportamiento esperado cuando la integración no está disponible.

6. Seguridad, continuidad y operación

Además de las funciones visibles, se definen requisitos de acceso, respaldo, recuperación, trazabilidad, rendimiento y soporte. No todos los sistemas necesitan la misma disponibilidad, pero todos necesitan una expectativa explícita y una persona responsable de operarlos.

7. Alcance, entregables y criterios de aceptación

Un alcance profesional describe qué se entregará y también qué queda fuera. Cada módulo debe tener condiciones de aceptación que puedan probarse. “Que sea fácil de usar” es una intención; “un operador puede registrar y localizar una solicitud con los campos acordados” es verificable.

Entregables mínimos del diagnóstico

1. Resumen ejecutivo: problema, objetivo, restricciones y resultado esperado.
2. Mapa del proceso: etapas, decisiones, excepciones y responsables.
3. Matriz de usuarios: roles, permisos y acciones sensibles.
4. Catálogo funcional: requisitos priorizados y reglas de negocio.
5. Inventario técnico: datos, documentos, equipos e integraciones.
6. Registro de riesgos: supuestos, dependencias y decisiones pendientes.
7. Plan de validación: escenarios de prueba y criterios de aceptación.
8. Ruta de implementación: etapas, entregables, soporte y responsabilidades.

Señales de que el diagnóstico aún no está listo

• La solución se describe sólo como una lista de pantallas.
• No existe una persona autorizada para resolver reglas contradictorias.
• Se promete integrar o migrar información que todavía no se ha revisado.
• El alcance no explica exclusiones, dependencias ni condiciones de aceptación.
• La operación posterior, los respaldos y el soporte no tienen responsable.

Conclusión

Diagnosticar no significa retrasar el proyecto. Significa reducir decisiones improvisadas durante la construcción. Un buen diagnóstico permite estimar por etapas, comparar alternativas y comenzar con una versión que resuelva el proceso principal sin ocultar riesgos ni dependencias.