Muchos proyectos empiezan con frases como “necesitamos un dashboard”, “queremos un CRM” o “hace falta una app”. Esas frases describen una forma posible de solución, pero todavía no explican el problema.
1. Define el evento que inicia el proceso
¿Qué ocurre para que el trabajo empiece? Puede ser una venta, una solicitud, un pago, una incidencia o la llegada de un documento.
2. Identifica estados
Los estados convierten trabajo ambiguo en flujo visible. Una solicitud puede pasar por recibida, validada, asignada, en proceso, bloqueada y resuelta. Cada transición debería tener una regla.
3. Documenta reglas de negocio
Ejemplos: quién puede aprobar un descuento, cuándo se genera un recargo, qué campos son obligatorios, qué sucede si un pago no coincide o qué condición cambia una cuenta de estado.
4. Define responsables y permisos
No basta con saber qué hace el sistema. Hay que definir quién puede ver, crear, modificar, aprobar o cancelar cada tipo de registro.
5. Describe los datos esenciales
Identifica entidades principales —cliente, unidad, pedido, pago, proveedor— y qué relaciones existen entre ellas. Esta parte suele revelar duplicidades que antes parecían “problemas de reportes”.
6. Diseña las excepciones
¿Qué pasa si el dato falta? ¿Si una integración no responde? ¿Si el usuario necesita corregir un movimiento ya aprobado? Las excepciones forman parte del proceso, no son bugs futuros.
7. Define qué decisión debe habilitar el sistema
Cada reporte o dashboard debería existir porque alguien necesita tomar una decisión. Eso evita construir indicadores decorativos.
Un buen discovery reduce retrabajo
El entregable útil no es una lista infinita de funcionalidades. Es un mapa claro del proceso actual, el proceso objetivo, las reglas, los datos y una priorización de módulos.
Después de eso puedes decidir con más criterio entre SaaS o software a medida, estimar el costo del desarrollo y diseñar una implementación por fases.