El sistema de registro debería ser local
He llegado a pensar que, para supply chain, la mayoría de las empresas deberían dejar de comprar amplios sistemas de registro y comenzar a construirlos localmente. Me refiero al software que registra órdenes, recepciones, movimientos de stock, facturas, aprobaciones y las secuelas administrativas de las operaciones ordinarias. Estos sistemas son críticos, pero su valor es limitado. Son libros contables con flujos de trabajo. El mercado aún los valora, los presenta y los regula como si fueran las joyas de la corona de la empresa. Ese error se ha vuelto muy caro.
En Introducción a supply chain, especialmente en los capítulos 5 y 6, tracé una línea entre el software que mantiene el rastro documental y el software que toma decisiones. Esa distinción importa aquí. Una vez que observamos un sistema de registro sin el teatro habitual, gran parte del misticismo desaparece. Un sistema de registro debería ser confiable, auditable y bastante aburrido. No debería pretender pensar. Debería recordar hechos, hacer cumplir algunos flujos de trabajo y mantenerse al margen.
El impuesto oculto de los sistemas de registro empaquetados
Un sistema de registro alcanza la madurez comercial rápidamente. Una vez que puede manejar de forma fiel las compras, las ventas, el inventario, la facturación y algunos flujos de trabajo adyacentes, el valor adicional de hacerlo más amplio es mínimo. Los proveedores lo saben perfectamente. Su respuesta ha sido la misma durante décadas: agregar otra entidad, otra pantalla, otro módulo, otra página de configuración. Vender el siguiente incremento a la base instalada. Con el tiempo, el producto se convierte en el sedimento de innumerables solicitudes de clientes, muchas sensatas de forma aislada y absurdas en conjunto. El resultado es un mastodonte de funcionalidades cuya complejidad sigue aumentando a pesar de que la tarea subyacente apenas ha cambiado.
La literatura académica ha descrito el mismo problema con un lenguaje más sosegado durante años. Strong y Volkoff observaron que los sistemas empresariales empaquetados están diseñados para requerimientos genéricos en lugar de específicos y, por lo tanto, tienden a encajar de manera imperfecta en cualquier organización concreta. Un estudio más reciente sobre la personalización de ERP deja explícito el compromiso: lo hecho a la medida puede mejorar la funcionalidad y la satisfacción del usuario, pero también incrementa el costo de implementación, la complejidad y el gasto en actualizaciones posteriores. Una revisión de ERP inadaptados de 2025 alcanza una conclusión igualmente desalentadora: las tasas de fracaso en la implementación se mantienen altas, la desalineación entre procesos estandarizados y flujos de trabajo locales persiste, y no ha surgido ninguna práctica industrial ampliamente adoptada que resuelva estas discrepancias de forma clara.
Este impuesto no se limita a las tarifas de licencia. El benchmark ERP de Panorama de 2025 reporta un costo mediano de proyecto de 450,000 USD y un cronograma mediano de nueve meses. Entre los proyectos que excedieron el presupuesto, la razón más común fue la necesidad inesperada de tecnología adicional. Entre los proyectos que se retrasaron, los problemas de datos fueron los principales culpables. El mismo informe señala que muchas implementaciones de ERP aún no logran eliminar los silos organizacionales. Este es el patrón que sigo viendo: la suite no elimina la complejidad; la redistribuye en integración, migración, gobernanza y soluciones alternativas elaboradas.
Los modelos de datos subyacentes cuentan la misma historia. La documentación de Microsoft para Dynamics explica que un concepto empresarial simple, como un cliente, puede estar disperso en varias tablas normalizadas, lo que es precisamente la razón por la que las entidades de datos existen como abstracciones desnormalizadas. La documentación de JD Edwards de Oracle expone largos catálogos de tablas por tipo y por módulo. ERPRef, un catálogo de esquemas de terceros, lista 1,687 tablas para SAP Business One 9.0 y 5,097 para JD Edwards 9.20; en ese mismo catálogo, la tabla de facturas A/R en SAP Business One 9.3 se muestra con 424 columnas. Una empresa dada usará solo una fracción de esta amplitud, sin embargo, sigue pagando por esa amplitud en permisos, mapeos, integraciones, capacitación y actualizaciones.
Existe un segundo impuesto, y a menudo es el más dañino. La visión de la empresa basada en la atención de William Ocasio parte de una observación simple: lo que hacen las empresas depende de cómo se canaliza la atención de los tomadores de decisiones. Un sistema de registro extenso consume esa atención tan seguramente como consume efectivo. Los años dedicados a implementaciones, limpiezas, migraciones, rediseños, complementos y actualizaciones son años en los que la alta dirección queda absorbida por la mecánica de la infraestructura administrativa. He argumentado en otro lugar que, cuando los registros y reportes consumen la mayor parte del presupuesto en software, también acaparan la mayor parte del tiempo ejecutivo, dejando poco espacio para el software que realmente podría mejorar las decisiones.
Por qué lo hecho a la medida dejó de ser difícil
Lo notable es que el argumento técnico a favor de los sistemas de registro hechos a la medida dejó de ser exótico hace ya bastante tiempo. PostgreSQL cuenta con casi cuarenta años de desarrollo activo y ha sido compatible con ACID desde 2001. ASP.NET Core es gratuito, open source y multiplataforma. Entity Framework Core soporta seguimiento de cambios, actualizaciones y migraciones de esquemas a través de múltiples bases de datos. Django viene con protecciones integradas contra ataques web comunes. Cuando la infraestructura del software transaccional se ha vuelto tan madura, construir un sistema de registro interno y estrecho ya no es un acto de valentía.
Existe incluso un detalle revelador en la documentación de Django. Se recomienda su interfaz de administración automática para la herramienta de gestión interna de una organización, no para una interfaz pública. Ese pequeño comentario resume todo el asunto. La industria ha estandarizado el esqueleto del back-office del software CRUD de manera tan exhaustiva que los principales frameworks ya lo incluyen de serie. Lo que sigue siendo difícil no es la infraestructura. Lo que sigue siendo difícil es decidir qué entidades, estados y flujos de trabajo realmente importan a la empresa y cuáles solo están presentes porque algún proveedor ha pasado veinte años recopilando peculiaridades de un segmento de mercado.
Es aquí donde lo hecho a la medida gana de manera decisiva. La ventaja no radica en la virtuosidad del código. La ventaja es la exactitud semántica. Las entidades pueden corresponder a la empresa tal como opera en realidad: su jerarquía de productos, sus excepciones en las compras, sus estados de recepción, sus reglas de aprobación, sus motivos de devolución, sus retenciones por calidad, y esas distinciones extrañas pero útiles que no se debería esperar que entienda una suite genérica. Un pequeño código local puede seguir siendo inteligible. Más importante aún, la empresa mantiene la propiedad del conocimiento operativo incorporado en ese código. El software refleja el negocio; el negocio ya no tiene que heredar los compromisos acumulados de toda la base de clientes de un proveedor.
Lo que cambiaron los agentes de código
Lo que cambió en 2025 no fue la base de datos, ni el navegador, ni el stack web. Lo que cambió fue el costo de producir el código. En enero de 2025, Anthropic reportó un 49 por ciento en SWE-bench Verified para un agente Claude 3.5 Sonnet mejorado. Para agosto, Claude Opus 4.1 alcanzó el 74.5 por ciento. El equipo de SWE-bench señaló posteriormente que mini-SWE-agent alcanzó el 65 por ciento en el mismo subconjunto verificado en una configuración minimalista. OpenAI, por su parte, lanzó Codex como un agente de software en la nube que puede trabajar en muchas tareas en paralelo, ejecutar pruebas y linters en entornos aislados, y proponer cambios para revisión; en un experimento de producto interno separado, OpenAI afirma que Codex escribió la totalidad de un código base de un millón de líneas que se construyó en aproximadamente una décima parte del tiempo que habría requerido la codificación manual.
Esto no significa que los agentes hagan a cada ingeniero más rápido en cada código base. El ensayo aleatorizado de METR con desarrolladores experimentados de open source encontró que las herramientas de IA de principios de 2025 los ralentizaron en un 19 por ciento cuando trabajaban en sus propios repositorios. Tomo ese resultado en serio. Sin embargo, no describe el mismo problema. Mantener un código base público maduro con estándares exigentes y años de contexto tácito no es la misma tarea que redactar un flujo de trabajo de recepción, un portal de proveedores, un back-office de ajuste de stock o una pantalla de devoluciones para un equipo interno. Para este último, los requerimientos son locales, los criterios de aceptación son concretos y la arquitectura es ordinaria. El trabajo separado de METR sobre el horizonte temporal también informa que la duración de las tareas de software que los agentes de frontera pueden completar con un 50 por ciento de fiabilidad se ha estado duplicando aproximadamente cada siete meses. Ese es exactamente el tipo de tendencia que importa cuando el trabajo es estrecho y bien delimitado.
Por eso, incluso un fabricante, distribuidor o minorista ordinario ahora puede poseer de manera sensata mucho más de su software transaccional que antes. Tal empresa no necesita convertirse en un proveedor de software. Necesita un responsable de procesos que conozca el negocio, un líder con conocimientos técnicos, un pequeño código base, una suite de pruebas y la disciplina para mantener el alcance estrecho. Los agentes de código reducen la cantidad de implementación manual necesaria para las partes aburridas, que resultan ser la mayor parte de los sistemas de registro. Mientras tanto, el stack open source maduro hace el resto. La combinación es poderosa precisamente porque los sistemas de registro son tan poco glamorosos. Son mayormente formularios, tablas, validaciones, permisos, flujos de trabajo e integraciones. Ahí es donde las herramientas son más fuertes.
Seguiría dejando de lado los ámbitos en los que el valor principal del proveedor radica en mantenerse al día con los cambios normativos. Esos son verdaderos casos excepcionales. Fuera de ellos, especialmente en supply chain, lo predeterminado debería invertirse. Para los flujos de compra, recepciones, devoluciones, retenciones de calidad, colaboración con proveedores, administración de datos maestros y dominios transaccionales similares, el software empaquetado y amplio se ha convertido en la forma costosa de obtener un ajuste mediocre. La alternativa hecha a la medida ya no está reservada a las empresas de tecnología. Ahora está al alcance de las empresas ordinarias, siempre que estén dispuestas a poseer una cantidad modesta de código y a rechazar la tentación de convertir ese código base en una gran plataforma.
El argumento ya no es sentimental ni futurista. Los sistemas de registro empaquetados y amplios son genéricos por construcción, inadaptados por costumbre e inflacionarios tanto en costo como en atención. Las herramientas para construir reemplazos estrechos han madurado durante años. Los agentes de código han comprimido ahora la última parte que solía impedir a muchas empresas actuar, a saber, la enorme cantidad de codificación rutinaria. Para los sistemas de registro de supply chain, la carga de la prueba se ha invertido. Una empresa debería comenzar preguntándose por qué se debería comprar este sistema en absoluto.
