Antes de contar señales, una advertencia
Digitalizar un proceso inestable no elimina el desorden: lo convierte en formularios, permisos y automatizaciones difíciles de cambiar. Yo buscaría primero un resultado compartido y unas reglas suficientemente estables. No tienen que ser perfectas; tienen que poder explicarse.
Las siguientes señales ganan fuerza cuando aparecen juntas. Una sola rara vez justifica un proyecto.
Las diez señales
1. La tarea ocurre con frecuencia
Una fricción diaria o semanal acumula suficiente coste como para estudiar una mejora. Una excepción anual probablemente no.
2. El inicio y el final pueden explicarse
Aunque haya excepciones, el equipo sabe qué activa el proceso y qué significa terminarlo.
3. Varias personas necesitan el mismo dato
Cuando cada una mantiene su propia copia, la discusión acaba siendo qué versión es correcta.
4. Se repiten preguntas sobre el estado
¿Está aprobado? ¿Se ha enviado? ¿Quién lo tiene? Son señales de que falta una vista compartida.
5. Hay reglas que ya se aplican manualmente
Descuentos, prioridades, vencimientos o permisos pueden documentarse y, quizá, incorporarse a la herramienta.
6. Los errores dejan una huella medible
Repetir trabajos, usar una versión equivocada o perder un plazo permite calcular el impacto real.
7. Una sola persona sostiene el conocimiento
Si su ausencia paraliza la operación, el proceso necesita memoria compartida antes incluso de automatización.
8. El volumen está creciendo
Lo que funcionaba con diez casos puede romperse con cien. Conviene actuar antes de que el parche sea crítico.
9. Los usuarios están dispuestos a probar
Sin alguien que enseñe casos reales y decida, el desarrollo se basará en suposiciones.
10. Es posible definir un primer resultado pequeño
Una solicitud completa, una aprobación o una orden de trabajo son mejores comienzos que «digitalizar toda la empresa».
Tres situaciones en las que esperaría
Esperaría si cada persona describe un proceso distinto, si las reglas cambian por decisiones improvisadas o si nadie asumirá la propiedad del dato después del lanzamiento.
En esos casos empezaría con observación, una plantilla común y dos semanas de uso. Esa prueba suele aclarar más que una reunión sobre funciones.
Una prueba rápida
Elige cinco casos recientes, incluidos dos que salieron mal. Recorre cada paso, anota esperas, copias, decisiones y excepciones. Si el equipo puede explicar qué debería haber ocurrido, ya existe materia prima para una primera versión.
Si ni siquiera puede acordarlo, todavía no hace falta programar: hace falta decidir.
Un proceso está preparado cuando el problema es repetido, las reglas principales pueden explicarse y existe alguien dispuesto a probar una primera mejora completa.