Una empresa de logística regional decidió hace dos años sustituir su sistema interno de seguimiento de envíos. El antiguo era un Access ya con quince años, mantenido por un freelance que se jubilaba en seis meses. La urgencia era real. La dirección, con buen criterio, no quería repetir el mismo error de su predecesor (un sistema hecho deprisa que duró eso, quince años de parches encadenados). Querían algo nuevo, ordenado, mantenible.
Contrataron una agencia con buen reputación. Definieron el proyecto en una reunión de cuatro horas y arrancaron con un sprint inicial de descubrimiento: dos semanas de entrevistas, capturas del Access actual y bocetos de pantallas. Empezaron a programar.
Tres meses después, en la primera demo, descubrieron que el sistema nuevo no permitía registrar envíos parciales. Es decir, casos en los que un cliente pide veinte palets pero solo se cargan dieciséis porque uno está dañado y otros tres llegan al día siguiente. Eso pasaba en el 12% de los envíos. El Access antiguo lo gestionaba con una columna llamada "incidencia" donde se anotaba a mano. La agencia, al modelar el sistema nuevo, dio por hecho que cada envío era atómico: o iba entero o no salía.
No fue un error de programación. Fue una regla de negocio que nadie había puesto por escrito.
El coste de descubrirlo a mitad
Cuando esa regla apareció en la demo, ya había código construido sobre la suposición contraria. La tabla de envíos tenía un único registro por orden, con una cantidad y un estado. Soportar envíos parciales requería partir el envío en varias entregas, cada una con su propio estado, su propia documentación y su propia facturación. Eso afectaba al modelo de datos, a la lógica de cálculo de comisiones de transportistas, a la integración con el ERP del cliente y a las cinco pantallas que ya estaban hechas.
La agencia presupuestó 18.000 € adicionales para rehacer la parte afectada. La empresa, además del sobrecoste, perdió siete semanas. Pero el problema no terminó ahí. En las semanas siguientes aparecieron tres reglas más con el mismo patrón. Una sobre cómo se trataban los envíos a oficinas postales (que admitían recogida del cliente final pero no entrega a domicilio). Otra sobre el cálculo de tarifas en envíos urgentes con condiciones meteorológicas adversas. Y una sobre el periodo de retención de documentación firmada físicamente, que era distinto del periodo legal porque tenían un cliente con auditoría externa que exigía cinco años.
Cada una requirió rehacer una parte de lo construido. El proyecto, que se había firmado por 60.000 € y cuatro meses, terminó costando 102.000 € y diez meses. Y dos años después, sigue arrastrando deuda técnica de las decisiones tomadas a mitad bajo presión.
Lo que faltó al inicio
La fase de descubrimiento de dos semanas se centró en lo que se ve. Las pantallas, los flujos generales, el aspecto. Lo que no se hizo fue sentarse con los responsables de operaciones, almacén y administración a sacar a la luz las reglas de negocio que vivían en la cabeza de tres personas con quince años de oficio. Esas reglas no estaban en el Access ni en ningún manual. Estaban en frases del tipo "ah, sí, pero cuando es un envío urgente y el cliente nos llama después de las seis, le aplicamos una tarifa nocturna que no aparece en la tabla porque la metí yo a mano hace años".
Modelar reglas de negocio significa precisamente eso: identificar todas las decisiones que el sistema actual toma (a veces por código, a veces a mano, a veces por costumbre) y ponerlas por escrito en un formato que un equipo técnico pueda traducir a software sin tener que adivinar nada.
Hay reglas estructurales (un envío puede tener entre 1 y N entregas), reglas de cálculo (la tarifa nocturna se aplica si la creación es entre 18:00 y 08:00 y la entrega es al día siguiente), reglas de comportamiento (cuando un envío lleva más de 48h sin actualizarse, se pone en estado "incidencia" y se notifica al gestor) y reglas de excepción (los clientes en convenio con la asociación X no pagan suplemento por entrega rural). Cada una de estas categorías requiere un tratamiento distinto en el modelo de datos y en la lógica del software.
Por qué se salta esta fase tan a menudo
La principal razón es que parece improductiva. Mientras se redactan reglas no se ve nada nuevo, no hay pantallas, no hay capturas que mostrar a la dirección, no hay sensación de avance. La presión por empezar a construir algo visible empuja a saltarse esa fase y empezar con maquetas. Las maquetas son agradecidas: se enseñan, se ajustan, se comparten. Las reglas de negocio son tediosas: se descubren conversando, se discuten, se contradicen entre departamentos y se documentan en tablas o en frases del tipo "si X y no Y, entonces Z, salvo cuando W".
La segunda razón es que muchas reglas son tácitas. La gente que ejecuta el proceso a diario no es consciente de que está aplicando reglas. Las aplica como aplicas la gramática del castellano: sin pensarlo. Solo cuando se les pregunta de forma específica ("¿qué pasa si un cliente llama el viernes a las siete pidiendo un urgente para el lunes?") aparece la regla. Se necesitan entrevistas dirigidas, no charlas abiertas, para sacarlas.
La tercera es que algunas reglas son contradictorias entre departamentos. Operaciones tiene una manera de tratar los envíos parciales y administración tiene otra. Mientras nadie pregunte, conviven. Cuando se modela el negocio para un sistema nuevo, hay que elegir, y la elección genera fricción. Es más cómodo dejar la decisión "para más adelante" y construir sobre la regla de uno de los dos. Más adelante siempre llega tarde.
Cómo se hace bien
No hace falta una metodología pesada ni semanas eternas. Hace falta una persona con criterio que entreviste a los responsables de cada área con un guion estructurado y vaya documentando las reglas en un formato consistente.
Para cada regla: cuándo se aplica (qué condiciones la disparan), qué hace (qué decisión, qué cálculo, qué cambio de estado), qué excepciones tiene (en qué casos no aplica) y de dónde viene (es regulación legal, política interna, costumbre, exigencia de un cliente concreto). Las reglas que vienen de exigencia legal no son negociables. Las que vienen de costumbre quizás se simplifiquen. Las que vienen de un cliente concreto pueden ser candidatas a parametrización.
Esa documentación se revisa cruzada entre los departamentos implicados. Aparecen contradicciones, se resuelven, se cierran. Cuando se pasan al equipo técnico, ya están traducibles a modelo de datos y a casos de prueba. El sistema que se construye después no descubre reglas a mitad: las implementa todas porque ya están escritas.
El otro coste oculto
Más allá del sobrecoste y el retraso, hay un efecto secundario que se nota dos años después. Los sistemas construidos sin modelar las reglas de negocio acaban con código lleno de excepciones añadidas a posteriori. Un campo "tipo de envío" que originalmente tenía tres valores y ahora tiene catorce. Funciones llamadas calcularTarifaEspecial que en realidad calculan la tarifa de tres clientes específicos hardcodeados. Comentarios en el código del estilo // importante: no tocar este if, lo necesita Juan de almacén sin que nadie sepa exactamente por qué.
Ese código funciona, pero es muy difícil de mantener. Cada cambio futuro tiene que pasar por arqueología digital antes de poder hacerse. La empresa acaba dependiendo de la persona que sabe por qué cada parche está donde está, y cuando esa persona se va, el sistema se vuelve intocable. Es exactamente cómo se construyó el Access que se quería reemplazar al principio.
El equilibrio razonable
Modelar reglas de negocio antes de programar no quiere decir parar todo durante seis meses haciendo documentación. Quiere decir dedicar entre el 10% y el 20% del tiempo del proyecto a esa fase, antes de que aparezcan las primeras pantallas. En un proyecto de cuatro meses, son entre dos y cuatro semanas. En uno de un año, entre uno y dos meses. Esa inversión paga durante todo el proyecto y durante los años siguientes.
Cuando una agencia te diga que pueden empezar a construir tras una semana de descubrimiento, hazte una pregunta: ¿están seguros de haber capturado las reglas que viven en la cabeza de los responsables, o están dispuestos a descubrirlas durante el desarrollo y facturarlas como cambios? La primera opción no existe en una semana. La segunda es lo habitual cuando el proceso se acelera.
La experiencia repetida es esta: cada hora dedicada a modelar reglas de negocio antes de programar ahorra entre cinco y diez horas durante el proyecto, y muchas más durante el mantenimiento posterior. Si una empresa tuviera que justificar cualquier inversión con ese ROI, lo haría sin pensar. Cuando la inversión es menos visible (documentos en lugar de pantallas), la justificación cuesta más. Pero el cálculo es el mismo.