Un ERP antes de que existiera esa palabra

Hace poco tuve en mis manos un documento fechado en mayo de 1975: una propuesta comercial escrita por Dabor Domic para Manufacturas Orlando S.A.C.I. Cincuenta años después, esa misma lógica de diseño terminó convirtiéndose en un sistema que hoy se llama DADO y que opera en 18 clientes, a plena satisfacción. Leerlo hoy es una experiencia extraña: es como encontrar el plano de una casa que todavía no se ha terminado de construir, pero que ya lleva medio siglo habitada.

¿Qué se puede aprender de una propuesta comercial de hace cincuenta años? Bastante más de lo que uno esperaría.

Una idea que no necesitaba tecnología nueva, sino claridad

En 1975 no había bases de datos relacionales ni mucho menos nube. Había tarjetas perforadas, cintas magnéticas y procesamiento por lotes. Y sin embargo, ahí ya estaba la idea central de lo que hoy llamamos un ERP: que una empresa no es una colección de departamentos aislados, sino un organismo donde sueldos, producción, existencias e inventarios deberían hablar entre sí.

Lo que me llama la atención no es la tecnología —obsoleta, por supuesto— sino la arquitectura del pensamiento. Domic ya distinguía operaciones que hoy llamaríamos Crear, Leer, Actualizar y Eliminar, codificadas en letras simples: A de agregar, M de modificar, S de calcular sueldo, T de eliminar. El CRUD, avant la lettre.

¿No es curioso que las categorías fundamentales de cómo organizamos la información cambien tan poco, aunque las herramientas cambien todo el tiempo?

La fábrica como ecuación

Otra cosa que me sorprendió fue el salto que da el documento hacia la ingeniería de producción. No se conformaba con automatizar papeleo: proponía un modelo matemático de la fábrica completa, con sus seis secciones —cueros, corte, aparado, suela, armado, envase— traducidas a restricciones y ecuaciones de flujo.

Una sección no puede procesar más de lo que recibe de la anterior. El tiempo disponible en cada sección pone un techo real a lo que se puede fabricar. Y sobre esa base, la gerencia podía elegir su objetivo: minimizar tiempo ocioso, minimizar bodegaje, o acortar el calendario total de fabricación.

Es un gemelo digital de la fábrica, cuarenta años antes de que ese término se pusiera de moda.

Confianza, no solo control

Hay un detalle que me parece más humano que técnico. El sistema detectaba desviaciones —piezas que no cuadraban, cuero que rendía menos de lo esperado— pero el documento insiste en que debía ser transparente para el trabajador, que pudiera verificar sus propios registros.

¿Cuántos sistemas de control que diseñamos hoy, con toda la potencia de la inteligencia artificial, siguen olvidando ese detalle? Se puede construir vigilancia, o se puede construir confianza. La diferencia no está en la tecnología, está en la intención con que se diseña.

Un ciclo, no una línea

Lo que más resuena conmigo, quizás porque es también la lógica que aplico en mi trabajo de coaching, es que el sistema no terminaba en un reporte. Domic diseñó un ciclo cerrado: información, decisión, acción, retroalimentación. Los resultados de la producción volvían a alimentar el próximo ciclo de planificación.

Eso es exactamente lo que distingue a un sistema vivo de un archivo muerto. Los datos por sí solos no sirven de nada si no vuelven a entrar en la conversación.

Lo que no cambió en cincuenta años

El documento cierra con una idea que podría haber sido escrita hoy mismo, en plena discusión sobre inteligencia artificial: el valor del computador no está en el cálculo en sí, sino en su capacidad de ampliar la comprensión y la capacidad de actuar del ser humano.

Cincuenta años, un cambio radical de tecnología, y el mismo principio de fondo. La tarjeta perforada se convirtió en formulario digital, el archivo maestro en base de datos, el procesamiento por lotes en tiempo real. Pero la pregunta esencial —para qué sirve toda esta información, a quién sirve— sigue siendo exactamente la misma.

¿Será que las herramientas que usamos importan menos de lo que creemos, y lo que realmente importa es la claridad con la que entendemos el problema que queremos resolver?