Un cliente nos pidió automatizar algo que su ERP sencillamente no puede hacer. La forma más rápida de decir que sí habría sido la decisión equivocada, y entender por qué es la explicación más clara de deuda tecnológica que podemos dar.
Hace unos días, un fabricante de alimentación nos contactó a través de un colaborador. Su petición era concreta y del todo razonable: preparan sus productos a partir de un puñado de recetas fijas, mezcla uno, mezcla dos, mezcla tres, y en cada tanda de producción alguien vuelve a introducir esas recetas en el sistema a mano. Querían dejar de hacer eso. Querían automatizar las mezclas.
Suena a un pequeño trabajo de integración. No lo es. Y la razón por la que no lo es es justo el tema de este artículo.
Qué es en realidad la deuda tecnológica
El término lo acuñó el programador Ward Cunningham como metáfora, y es una buena metáfora. Entregar una solución rápida e imperfecta es como pedir un préstamo. Consigues algo que funciona hoy, pero pagas intereses para siempre, un poco de esfuerzo extra cada vez que tocas el sistema, hasta que amortizas el principal haciendo el trabajo como es debido.
La deuda no es automáticamente algo malo. A veces la asumes de forma deliberada y con los ojos abiertos: una fecha de entrega real, una ventana de mercado, una prueba de concepto que ya sabes que vas a tirar. Lo que hace peligrosa a la deuda es asumirla sin darte cuenta, o asumirla para tapar un problema que en realidad nunca va a desaparecer.
El peor tipo de deuda tecnológica es el que nunca podrás devolver, porque se apoya en unos cimientos que no son tuyos.
El problema real, no el aparente
El cliente lleva su negocio con Distrito K / SQL-PYME, un ERP español construido sobre una base de datos Firebird. Tiene una API y, sobre el papel, eso son buenas noticias: una API significa que podemos integrar de forma limpia en lugar de hurgar en la base de datos en crudo que hay debajo.
Así que leímos la documentación de la API con cuidado, de principio a fin. Y este es el hallazgo que lo cambia todo. La API cubre la gestión comercial y el almacén: clientes, artículos, existencias, documentos de venta y compra, movimientos de almacén. No expone ni un solo objeto de fabricación. Ninguna orden de producción. Ninguna lista de materiales. Ninguna receta, ningún "escandallo". Ni siquiera permite definir los componentes de un artículo a través de ella.
Ahora vuelve a leer la petición del cliente con eso en mente. Nos pidieron automatizar sus mezclas. Una mezcla es, por definición, una operación de fabricación: entran componentes, sale un producto terminado, siguiendo una receta. Eso es, exacta y precisamente, lo único que la API de su ERP no puede representar.
El parche tentador
Siempre hay una manera de hacer que "funcione". Construyes un puente. Lees los datos maestros, artículos y existencias, del ERP a través de su API. Modelas las recetas y la lista de materiales en un segundo sistema que sí entiende de fabricación. Haces el cálculo allí. Y escribes el resultado de vuelta en el ERP como un simple movimiento de almacén, porque un movimiento de almacén es uno de los pocos documentos que la API acepta.
En una diapositiva se ve limpio. En producción es un parche, y un parche cobra intereses:
- El problema real sigue ahí. El ERP sigue sin poder gestionar una orden de fabricación. No le has dado esa capacidad, solo has escondido la carencia detrás de un segundo sistema.
- Ahora hay dos cerebros. Las recetas viven en un sitio; las existencias, los precios y la facturación viven en otro. Cada artículo, cada unidad, cada precio hay que mantenerlo sincronizado a través de un enlace frágil, para siempre.
- El enlace es frágil por diseño. La API mantiene estado, solo permite una sesión por usuario y esa sesión caduca. Solo para llegar al servidor del cliente necesitas una máquina dedicada dentro de su red y un túnel privado. Nada de eso resuelve el problema del cliente: es un andamiaje cuyo único cometido es sostener el parche.
- Cada cambio futuro cuesta más. Un nuevo tipo de mezcla, un campo adicional, una actualización de versión del ERP, cada uno hay que gestionarlo ahora dos veces y volver a probarlo a través del puente.
Eso son los intereses. Los pagas cada mes, para siempre, y al final sigues sin tener lo único que de verdad necesitabas: un sistema que gestione tu producción.
Por qué no recomendamos el parche
Podríamos haberlo construido. Es trabajo real y facturable, del orden de ciento cincuenta horas. Decir que sí habría sido la respuesta fácil y rentable.
Pero nuestro trabajo no es vender horas. Es dejar al cliente mejor de como lo encontramos. Un puente que apuntala de forma permanente una herramienta que estructuralmente no puede hacer el trabajo consigue lo contrario: añade complejidad, añade puntos de fallo y ata al cliente a pagar intereses sobre una deuda que nunca se amortiza. Eso no es una solución. Es una suscripción a un problema.
La respuesta honesta es la más difícil de decir en voz alta: las mezclas son un problema de fabricación, así que su sitio está en un sistema construido para gestionar fabricación.
La salida de la deuda
La jugada correcta no es parchear alrededor de la carencia, es cerrarla. Coge la parte que el ERP actual no puede hacer, producción, recetas, listas de materiales, órdenes de fabricación, y llévala a un sistema que la gestione de forma nativa.
Eso es exactamente lo que hace un ERP completo con un módulo de fabricación de verdad. En Odoo, por ejemplo, el módulo MRP trata las recetas (listas de materiales), las órdenes de fabricación, el consumo de componentes y la salida de producto terminado como objetos de primera clase. La mezcla que hoy alguien vuelve a teclear a mano se convierte en una orden de fabricación que el sistema ya entiende: sin puente, sin segundo cerebro, sin túnel sosteniendo un parche.
Es más trabajo por adelantado que una integración rápida. También es la última vez que pagas por ello. En lugar de alquilar un apaño para siempre, el cliente pasa a ser dueño de la capacidad.
La conclusión
La deuda tecnológica no es solo código desordenado. Es la distancia entre la respuesta rápida y la correcta, más los intereses que aceptas pagar en silencio sobre esa distancia mientras el sistema siga vivo.
Hay deuda que vale la pena asumir, a conciencia, con un plan para devolverla. La deuda que hay que evitar a toda costa es la que asumes para esconder un problema que nunca podrás arreglar en su origen. Eso no es un atajo. Es una hipoteca sobre los cimientos de otro.
A veces lo más valioso que un partner tecnológico puede decirte es: "esto no deberíamos construirlo". Nosotros lo dijimos. Ese es todo el artículo.