La primera cifra de un proyecto no es el presupuesto. Es la cifra que describe el problema. Sin ella, no hay proyecto: hay un ejercicio de estilo con la esperanza de que las cosas mejoren. En udae no arrancamos una automatización sin haber tomado antes esa cifra. Y no la cerramos sin volver a tomarla al final. Esta nota explica cómo lo hacemos.
La regla de las dos fotos
La idea es simple: dos fotografías con la misma cámara, encuadre y ajustes. Una tomada antes de tocar nada. La otra, tomada un mes después de entregar el sistema. Todo lo que ocurra entre las dos fotos es negociación de metodología, elección de herramientas y decisiones técnicas. Pero el proyecto se juzga por la diferencia entre ambas.
Este enfoque no es original nuestro. Cualquier ingeniero industrial reconocerá el patrón de baseline y post-implementación. Lo que sí es nuestro es la exigencia: sin esas dos fotos, no hay proyecto. No hay «lo notarás». No hay «te lo prometo». Hay un número antes, y un número después. Si no mejora, no ha servido.
Qué se mide
Depende del proceso, pero casi siempre se mide alguna combinación de tres cosas:
- Tiempo humano. Cuántos minutos de trabajo dedica una persona a la tarea, cuántas veces al día o al mes. Multiplicado por el coste hora del puesto. En cuadres, cobros, avisos e informes, es la métrica dominante.
- Errores atrapables. Cuántas veces al mes una diferencia se descubre tarde: una factura sin cobrar, un pago duplicado, un cliente que reclama un servicio que no consta. Cada error tiene un coste directo, y otro indirecto en confianza.
- Retraso de decisión. Cuántos días pasan desde que un hecho ocurre en la operativa hasta que aparece en el informe que ve la dirección. En muchos negocios es la métrica más silenciosa y la más cara.
No se miden más de tres o cuatro cosas por proyecto. Más métricas implican menos foco, menos rigor y, sobre todo, más excusas para no haber cumplido.
Cómo se toma la cifra de antes
Aquí es donde el proyecto suele quedarse atascado. La empresa quiere empezar; el equipo técnico quiere construir; la dirección quiere ver avances. Pedir dos semanas para medir el estado actual parece un lujo. No lo es. Es la única forma de saber si el sistema que se va a construir sirve.
Dos semanas es el mínimo razonable. Un mes es lo ideal. En ese periodo pedimos al equipo que registre, sin cambiar nada, tres datos por cada instancia del proceso: cuándo empezó, cuánto duró, y si hubo algún error. No se pide un diario meticuloso: basta con una hoja compartida donde cada persona anote lo suyo. La cifra final es un promedio con banda de incertidumbre, no un número exacto.
Ejemplo real
Antes: cierre financiero mensual de tres clubes. 3 h 40 min por cierre. 4 errores atrapados al mes. Informe a dirección con 5 días de desfase.
Este era el punto de partida de un proyecto que hicimos con un grupo de tres gimnasios. La medición duró tres semanas. Con esas cifras sobre la mesa, la propuesta cambió por completo: no propusimos migrar de Virtuagym, ni cambiar el software financiero. Propusimos un flujo que leyese Virtuagym y Mollie, cuadrase automáticamente, y publicase el informe en un panel del que la dirección tira cuando quiere.
Cuatro meses después de entregar, la segunda foto:
Después: cierre financiero mensual de tres clubes. 12 min por cierre. 0 errores atrapados en tres meses. Informe a dirección disponible cada mañana.
La conversación cambió. Antes hablábamos del proyecto en abstracto. Después hablábamos de qué hacer con las tres horas semanales que la oficina había recuperado. Ese es el único tipo de conversación que justifica un proyecto de este tipo.
Cuando los números no mejoran
Ocurre. No es lo común, pero ocurre. Y en udae lo tratamos con la misma disciplina que cuando mejoran: se mira la foto, se comparan las cifras, y se admite. Hay tres motivos habituales por los que un proyecto no mueve la aguja:
- Se medía la métrica equivocada. El sistema mejoró algo real, pero no lo que se había prometido medir. Es un error de diseño del proyecto, no del sistema. Se corrige eligiendo bien la métrica desde el inicio.
- El proceso automatizado no era el que consumía el tiempo.El equipo dedicaba las horas a otra tarea que no estaba en el alcance. Se detecta con la primera medición si se hace bien; si aparece después, hay que ampliar el alcance.
- El sistema no se está usando. Nadie tira del panel, nadie mira el informe, nadie confía en el flujo. Es un problema de adopción, no de software. Se corrige con formación, no con más código.
La segunda foto es la que compromete
La primera foto la toma el proyecto. La segunda la toma el cliente, con nuestro acompañamiento. Es él quien accede al panel, mira los registros y cuenta los minutos. Si el número no mejora, la conversación no es agradable. Pero es la única conversación que importa. Todo lo demás es literatura.
Por eso, cuando alguien pide un proyecto sin querer medir, la respuesta suele ser que todavía no. Primero conviene definir cómo se va a saber que ha funcionado. Después, y solo después, se construye.