Por qué todavía no es una respuesta legítima
El software congela una decisión. Cada estado, cada permiso, cada regla sobre quién aprueba qué se vuelve un hecho que el sistema impone igual todos los días. Ese es el valor y también el riesgo: si el proceso de abajo todavía se está inventando, el software codifica un borrador y el negocio se pasa la construcción peleando con su propia herramienta.
Entonces la pregunta útil no es si el software ayudaría — casi siempre ayudaría, tarde o temprano — sino si ayudaría ahora. Lo que sigue es el chequeo que hacemos en un diagnóstico, incluidas las condiciones bajo las cuales decimos que no. Una lista que todo el mundo pasa es un documento de ventas; esta tiene reprobados a propósito.
Los tres que tienen que ser ciertos
El proceso tiene que quedarse quieto el tiempo suficiente para construirlo. Si los pasos cambiaron dos veces este trimestre y es probable que vuelvan a cambiar, no estás describiendo un proceso, estás describiendo un experimento, y los experimentos viven en una hoja de cálculo donde cambiar una regla toma una tarde. Se construye cuando la forma ya está firme y lo único que sigue creciendo es el volumen.
Tiene que repetirse. El valor de volver software un trabajo sale de que la misma secuencia corra muchas veces con el mismo resultado, así que el caso que pasa una vez al año y siempre distinto no es el caso para el cual construir. Busca el trabajo que ocupa la mayor parte de la semana y varía menos. Esa es la primera versión.
Alguien tiene que poder decidir. Toda construcción llega a una pregunta que solo el negocio responde: qué cuenta como aprobado, quién puede saltarse la regla, qué pasa con la excepción. Cuando esa respuesta exige un comité que se reúne una vez al mes, la construcción se frena en el peor punto posible, a mitad de camino. Una persona con autoridad para decidir vale más que un brief detallado.
Las señales que dicen todavía no
Nadie ha escrito el proceso, y las tres personas que lo operan lo describen distinto. Eso no es un bloqueo, es el primer trabajo; pero hacerlo mientras se está escribiendo código significa construir lo equivocado primero y cambiarlo después. Mapéalo antes, como su propio ejercicio, y la construcción arranca contra algo acordado en vez de algo supuesto.
Las reglas cambian cada semana porque todavía estás encontrando el mercado. Una empresa que aún descubre qué vende no debería congelar cómo lo vende, porque ahí cada cambio cuesta un despliegue en vez de una conversación. Quédate con el proceso manual por ahora, trata su fricción como señal de qué construir después, y vuelve a mirar cuando pase un mes sin que nadie cambie un paso.
El síntoma tiene forma de software y la causa no. Los traspasos fallan porque dos áreas no se ponen de acuerdo en quién es dueño de un paso, y un tablero hace visible ese desacuerdo sin resolverlo. Hay diagnósticos que terminan en un cambio de proceso o en la decisión de dejar de hacer algo, y escribir eso es mejor resultado que una construcción que automatiza la pelea.
Qué hacer si la respuesta es todavía no
Escribe el proceso como de verdad corre, no como lo cuenta el manual: los saltos de regla, las excepciones, el paso que alguien se brinca cuando el cliente es importante. Ese documento sirve por sí solo, porque casi siempre muestra dónde vive la demora, y es lo que cualquier estudio, incluido otro distinto, necesitaría antes de cotizar. Por eso es el primer entregable de un diagnóstico.
Después escoge un proceso, no toda la operación. Una primera versión que carga un flujo completo con datos reales, con la gente que lo usa a diario trabajando adentro, te dice más del resto que cualquier especificación. Si cambia cómo se siente el trabajo en unas pocas semanas, el resto es dimensionar. Si no cambia, lo averiguaste en la versión pequeña.