Cuando la operación ya existe y el sistema todavía no

La hoja empezó con tres columnas. Hoy tiene catorce, dos pestañas que nadie borra por si acaso y una fórmula que falla desde marzo. El estado de un pedido se pregunta en un grupo de WhatsApp, y quien sabe dónde está cada cosa es una persona.

Eso ya es un sistema: se usa todos los días y la operación depende de él. Lo que no tiene es dueño, registro, ni forma de que entre alguien nuevo sin que se lo expliquen.

Primero seguimos un dato: quién lo escribe, quién lo aprueba, qué decisión produce y qué queda guardado. Ahí aparecen las reglas que nadie sabe explicar en una reunión y que solo se ven cuando alguien las usa de verdad.

Después se elige un flujo con frontera clara, resultado visible y alguien que lo necesite esta semana. Ése se construye y se pone a usar. Una plataforma entera levantada sin usuarios enseña menos que una primera parte que alguien abre el lunes.

Es la objeción que frena esta compra, y no el precio. La respuesta se da antes de empezar, porque cambia cómo se escribe el sistema.

El código es suyo. Se lo puede llevar.

Con su historial y con lo necesario para que otro equipo lo tome. Si hace falta un servicio de terceros, queda identificado con su nombre y su coste, y no dentro de una factura nuestra. Poder cambiar de proveedor sin reescribirlo todo es una condición del diseño.

1. El mapa del proceso: qué dato entra, quién lo aprueba y qué tiene que quedar registrado.
2. El flujo elegido funcionando, con sus estados vacíos, sus errores y sus confirmaciones.
3. El modelo de permisos: quién ve, quién crea, quién aprueba y quién exporta.
4. El historial de las acciones que importan, y cómo volver a la versión anterior.
5. El código, el repositorio y las llaves, a su nombre.

No las pantallas. Un proceso con veinte pantallas y ningún caso raro se entrega antes que otro con cinco y tres excepciones que solo conoce una persona.

Por eso la primera parte útil suele estar en semanas: se elige a propósito un flujo con frontera clara. Lo demás tarda lo que tarde en aparecer su operación real, y cada excepción que descubre un usuario es trabajo que no estaba en la lista. Eso se dice al empezar, no al final.

No convertimos en código una regla que nadie sabe explicar: primero se decide, después se escribe. No apagamos su hoja de cálculo el primer día, porque apagarla antes de que el equipo confíe en el sistema no la elimina, la convierte en un archivo en la sombra. No copiamos datos de personas a una herramienta nueva sin saber quién puede verlos. Y no levantamos una plataforma entera para quien todavía está averiguando qué necesita.

No publicamos casos de clientes todavía. Publicamos lo que nos ha pasado construyendo, con su método y su fecha, y está abajo en las notas: qué ocurre cuando la misma verdad vive en dos copias, por qué un nombre que empieza por el signo igual se ejecuta como fórmula al abrir la exportación, y cuántas peticiones se caen en un despliegue hecho de la forma fácil.