En el desarrollo de software existe una frase que todos repetimos, pero que muy pocos aplican de verdad: “antes de escribir una línea de código, define tu proceso”.
Parece obvio, pero en la práctica sigue siendo uno de los puntos más débiles de muchos proyectos, especialmente cuando las empresas aún no tienen sus workflows plenamente definidos. En Addmira nos hemos encontrado a menudo con pequeñas empresas que necesitan acompañamiento para entender cómo estructurar sus procesos antes de digitalizarlos. Y en esos casos es normal: forma parte del valor que aportamos.
Sin embargo, cuando el cliente es una empresa grande, con procesos ya establecidos y con varios responsables internos asignados específicamente al proyecto, la expectativa es muy distinta. Y cuando esa definición no existe o aparece fragmentada, el proyecto completo puede tambalearse.
Hace poco vivimos un caso que ilustra perfectamente esta situación.
Un punto de partida frágil: un PowerPoint que no era un documento funcional
El proyecto parecía claro sobre el papel: ampliar un GMAO implantado desde hacía más de cinco años para añadir un módulo de gestión de maquinaria.
El cliente —como hemos comentado antes, una empresa de gran tamaño a nivel de península— nos entregó un PowerPoint con cuatro capturas de pantalla y unas notas. Sobre esa base se elaboró el presupuesto y el alcance, entendiendo que ese documento representaba los requisitos mínimos para construir una primera versión funcional.
Pero pronto descubrimos que estábamos construyendo sobre terreno inestable.
Un PowerPoint, por muy claro que parezca, no es un documento funcional. No detalla reglas de negocio, no describe excepciones, no define responsabilidades internas, no refleja decisiones estratégicas… Y cuando el propio cliente no tiene documentado su proceso, ese PowerPoint deja de ser una guía y pasa a ser un borrador.
El verdadero problema: el cliente iba descubriendo su workflow sobre la marcha
A medida que avanzaba el desarrollo, empezaron a surgir puntos críticos no definidos:
- “El módulo de contratos que habéis hecho solo nos sirve para los contratos marco (contrato marco? nuevo tipo de contrato).”
- “Las máquinas pueden trasladarse entre almacenes.”
- “Los contratos a corto plazo funcionan diferente que los de largo plazo.”
- “Si una máquina con contrato a corto plazo se traslada, se debe generar un contrato nuevo.”
- “Si una máquina con contrato a largo plazo se traslada, el contrato puede mantenerse.”
Nada de esto estaba contemplado en la documentación inicial, pese a que el cliente tenía varias personas internas dedicadas al proyecto. Cada reunión se convertía en un nuevo descubrimiento para ellos… y en un replanteamiento completo para nosotros.
Y aquí aparece el punto clave:
Si una empresa no conoce bien su propio proceso, es imposible digitalizarlo sin fricciones.
El efecto dominó: cada ajuste conceptual implica rehacer la base
Cuando los nuevos requisitos afectan al core del módulo —estructura de contratos, reglas de traslado, vínculos entre almacenes, caducidades— ya no es un simple “detalle”. Son cambios estructurales.
Lo que provoca:
- Refactorizaciones completas.
- Reconfiguraciones del modelo de datos.
- Nuevas pantallas y flujos.
- Revalidación continua del funcionamiento.
- Y, por supuesto, más tiempo de desarrollo.
Un módulo que debía estar listo en diciembre terminó funcionando tres meses después. No por ejecución técnica, sino por falta de claridad inicial.
El famoso “feature creep”: cada reunión añade una idea nueva
Este caso fue un ejemplo perfecto de cómo cada conversación puede generar nuevas “necesidades” no contempladas:
- “¿Podría ser que…?”
- “Ahora que lo veo, también necesitamos…”
- “Ya que estamos, podríamos añadir…”
Sin un alcance firme, el proyecto deja de ser un desarrollo y se convierte en una idea en constante evolución. Y eso, en un entorno empresarial grande, multiplica el impacto.
Lo que este caso nos enseñó (y que todo cliente debería saber)
1. Documentar el proceso es obligatorio, no opcional
Sin un workflow claro, el software solo puede imitar lo que se imagina, no lo que el negocio necesita.
2. Un PowerPoint no sustituye un análisis funcional detallado
Sirve como orientación, pero no define reglas ni excepciones.
3. Los cambios tardíos tienen un coste real
En tiempo, presupuesto y estabilidad del producto.
4. La comunicación debe ser continua, pero la definición debe ser sólida desde el inicio
No se puede descubrir el proceso mientras se programa.
5. El proveedor desarrolla software, pero no inventa los procesos del cliente
Podemos acompañar, guiar y ayudar —y lo hacemos, sobre todo con pequeñas empresas— pero la base debe venir del cliente.
Claridad hoy evita meses de retraso mañana
El proyecto terminó funcionando, sí, pero tres meses más tarde de lo previsto. Y no por un problema técnico, sino por algo mucho más básico: la falta de claridad inicial en los procesos del propio cliente.
Digitalizar un proceso no debe servir para descubrir cómo trabaja una empresa. Debe ser la consecuencia natural de tener ese proceso bien definido.
Porque cuando un cliente conoce su workflow, el software se convierte en un acelerador. Pero cuando no lo conoce, el desarrollo se convierte en una búsqueda constante a oscuras.
