La primera oleada de reingeniería de procesos de negocio fracasó por una razón honesta: la tecnología de la época no podía ofrecer lo que la teoría prometía. En 1993 una empresa podía redibujar un proceso en una pizarra, pero los sistemas subyacentes eran rígidos, dependían del procesamiento por lotes y resultaban difíciles de integrar, de modo que el rediseño o bien se atascaba en la frontera del mainframe o bien degeneraba en un ejercicio de recorte de costes revestido con el lenguaje de la transformación. La idea era acertada y las herramientas no lo eran, y ambas quedaron unidas en el recuerdo.

Esa restricción se ha disuelto en gran medida. Las interfaces de programación de aplicaciones son hoy una expectativa estándar y no un proyecto a medida. El streaming de eventos, las plataformas de datos en cloud y los motores de orquestación hacen viable componer un proceso que se ejecute a través de varios sistemas de registro sin transportar los datos a mano entre ellos. Lo que antes era una integración heroica es hoy ingeniería corriente. La consecuencia es que la pregunta de la reingeniería, largamente aplazada por lo caro que resultaba responderla, ha vuelto a ser abordable, y está regresando en la mayoría de las organizaciones bajo otros nombres: rediseño del ciclo pedido a cobro, incorporación de clientes, resiliencia del suministro, aceleración del cierre financiero.

La tentación de aplazar la pregunta de la reingeniería es comprensible y ya no es segura. Durante años el curso racional era esperar, porque el coste de integración de cualquier rediseño serio superaba al beneficio, y las empresas fueron acumulando soluciones improvisadas con la confiada expectativa de que se resolverían con la próxima actualización del sistema. Rara vez fue así. Cada actualización preservaba la forma antigua del proceso porque migrar esa forma salía más barato que cuestionarla, y el diseño accidental se endurecía hasta parecer permanente. Lo que ha cambiado es que los competidores que sí se hacen la pregunta pueden ahora actuar sobre la respuesta, y un proceso que tarda el doble o cuesta el doble ya no queda oculto por el hecho de que todos los demás sean igual de lentos.

Hay una segunda razón por la que la pregunta importa ahora. Tres décadas de adopción de software empresarial han dejado a la mayoría de las grandes empresas con un CRM que modela al cliente, un ERP que modela la transacción y las finanzas, y una suite de cadena de suministro que modela el material y la capacidad, cada uno configurado por una función distinta, en un momento distinto y con una lógica distinta. Los procesos que realmente generan valor, tomar un pedido y cumplirlo, captar un cliente y atenderlo, planificar el suministro frente a la demanda real, discurren directamente a través de los tres. La organización está ordenada por funciones; el trabajo está ordenado por flujos; y la brecha entre ambos es donde se acumulan el coste, la demora y el error. La reingeniería es la disciplina de cerrar esa brecha de forma deliberada en lugar de disimularla con hojas de cálculo y buena voluntad.

La idea fundacional de la reingeniería, y todavía la que más rinde, es que un negocio se describe con más verdad por sus procesos que por su organigrama. Una empresa centrada en las funciones optimiza cada departamento frente a sus propios objetivos: ventas maximiza las contrataciones, operaciones minimiza el coste unitario, finanzas protege el capital circulante. Cada uno es localmente racional y la suma resulta a menudo globalmente pobre, porque los traspasos entre funciones, allí donde el cliente realmente espera, no pertenecen a nadie. Una empresa centrada en los procesos invierte esto. Da nombre a los flujos de principio a fin que importan, otorga a cada uno un responsable con autoridad real a través de las líneas funcionales, y mide el flujo en su conjunto: tiempo transcurrido, rendimiento a la primera, coste de servir, conversión de efectivo.

De aquí se deriva una dura pregunta previa, que insistimos en responder antes de que empiece cualquier rediseño: reingeniería o mejora incremental. Ambas no son intercambiables, y confundirlas resulta caro en ambos sentidos. La mejora incremental es la elección correcta cuando un proceso es fundamentalmente sólido y solo está incrustado de desperdicio; aquí las herramientas del lean y la mejora continua se amortizan pronto y con seguridad. La reingeniería solo está justificada cuando el proceso encarna supuestos que ya no se sostienen, cuando la secuencia de pasos existe por una restricción que desde entonces ha desaparecido, o cuando el resultado deseado es inalcanzable por mucho que se afine el diseño existente. La prueba que aplicamos es contundente. Si no habrías podido llegar a este proceso diseñando desde una hoja en blanco para el resultado de hoy, es candidato a rediseño. Si sí habrías podido, es candidato a mejora.

El tercer principio es que un proceso que abarca CRM, SCM y ERP no puede rediseñarse en uno solo de ellos por separado. El maestro de clientes, el maestro de productos, la lógica de precios y el estado del pedido son hechos compartidos que viven, de forma redundante y a menudo inconsistente, en los tres sistemas. Un rediseño genuino tiene que decidir dónde se crea cada hecho, cómo se propaga y qué sistema prevalece cuando discrepan. Por eso tratamos los datos y la integración no como una preocupación de implementación posterior, sino como la sustancia misma del diseño. El modelo de proceso y el modelo de datos son dos vistas de lo mismo, y un esfuerzo de reingeniería que produce hermosos diagramas de proceso y deja sin resolver la propiedad de los datos no ha reinventado nada en realidad.

Un cuarto principio sustenta a los otros tres: un proceso, un sistema y una organización no son tres cosas que haya que alinear, sino una sola vista desde tres ángulos. Cuando se tratan como líneas de trabajo separadas con gobierno separado, cada una optimiza para su propia finalización, y se encuentran en la puesta en marcha en mutua contradicción. El sistema impone un flujo que la organización no está dotada de personal para ejecutar sobre datos que el proceso suponía limpios. Diseñarlos como una sola decisión es más exigente intelectualmente y mucho más barato en la práctica, porque las contradicciones se encuentran sobre el papel y no en producción.

El campo se está moviendo, y no siempre en la dirección que anuncian los proveedores. Merece la pena nombrar con claridad unos cuantos patrones, porque cambian cómo debe abordarse un rediseño.

Componibilidad frente al monolito. El supuesto de que una única suite de ERP deba adueñarse de la mayor parte del proceso está cediendo ante una arquitectura de sistemas especializados unidos por integración. La capa de interacción con el cliente, el motor de planificación, el núcleo financiero y los sistemas de cumplimiento son cada vez más distintos, elegidos por sus méritos y compuestos en un flujo. Esto es liberador para el diseño de procesos, porque ya no estás atado a la opinión de un único proveedor sobre cómo debe funcionar el ciclo pedido a cobro, pero traslada la dificultad a la capa de integración y gobierno, que ahora carga con la coherencia que solía aportar el monolito.

La minería de procesos como evidencia. Durante la mayor parte de su historia la reingeniería comenzaba con talleres en los que las personas describían cómo creían que funcionaba el proceso, lo cual era de forma fiable una ficción. La minería de procesos reconstruye el proceso real a partir de los registros de eventos que los sistemas ya emiten, mostrando cada variante, bucle de retrabajo y desvío tal como ocurre de verdad. Hoy consideramos que iniciar un rediseño sin esta evidencia raya en la negligencia. Sustituye la opinión por una línea base medida y, más adelante, proporciona el instrumento que te indica si el rediseño se comporta según lo previsto en producción.

El ERP en cloud y la realidad de los dos niveles. El paso al ERP en cloud se vende a menudo como una oportunidad para volver a procesos estándar y abandonar años de personalización, y para el trabajo genuinamente común ese es un buen consejo. Pero ese mismo paso se endurece con frecuencia en un panorama de dos niveles: un núcleo estandarizado rodeado de los sistemas especializados que soportan la verdadera distintividad de la empresa. La pregunta de diseño no es, por tanto, si personalizar, sino dónde reside legítimamente la distintividad, manteniendo el núcleo cerca del estándar mientras se permite que el borde difiera, e integrando ambos de forma deliberada y no por accidente.

La automatización pasa de la tarea al proceso. La primera generación de automatización, en particular la automatización robótica de procesos, en su mayoría imitaba a un humano haciendo clic por las pantallas, lo que afianzaba el proceso existente en lugar de rediseñarlo. El patrón más útil ahora es automatizar el flujo rediseñado al nivel del proceso, usando orquestación e integración nativa, y reservar la automatización a nivel de pantalla para los bordes genuinos donde no existe ninguna interfaz. Automatizar un mal proceso solo te permite ejecutarlo más rápido.

Un proceso reinventado vale solo lo que la arquitectura que lo sostiene. Varios principios de diseño separan los rediseños que se mantienen de los que revierten en silencio.

Una única fuente de verdad por hecho, no por sistema. El instinto de declarar un sistema maestro de todo es tan erróneo como no tener ningún maestro. La disciplina es más fina: para cada entidad y atributo significativo, nombra exactamente un sistema que lo cree, y deja que los demás se suscriban. El CRM puede poseer la relación con el cliente mientras el ERP posee la cuenta legal y la posición de crédito; lo que importa es que la propiedad sea explícita, acordada y aplicada, de modo que la reconciliación deje de ser un ritual mensual.

La integración como un contrato, no como una conexión. Las interfaces punto a punto construidas con prisas se convierten en la parte más frágil del panorama de sistemas, porque cada una codifica supuestos que nadie escribió. Diseñamos la integración como contratos versionados con eventos, cargas útiles y semántica definidos, mediados por una capa que puede absorber el cambio en cualquiera de los dos lados. El objetivo es que un sistema pueda reemplazarse tras su contrato sin que cada vecino tenga que enterarse.

Diseñar el proceso para que sea observable. Un proceso que no puede medirse en marcha no puede gestionarse, y la mayoría no puede. Construimos el flujo rediseñado de modo que su estado, sus tiempos y sus excepciones se emitan como eventos por construcción, alimentando la misma minería de procesos que estableció la línea base. La observabilidad no es una instrumentación añadida después; es una propiedad diseñada desde dentro, y es lo que permite que el proceso siga mejorando una vez terminado el proyecto.

Diseñar para la reversibilidad. Un rediseño que solo puede avanzar es un rediseño que encontrará resistencia, porque el coste de equivocarse es catastrófico. Construimos la migración de modo que cada incremento pueda pausarse, ejecutarse en paralelo con el sistema vigente y deshacerse si la evidencia lo exige. Esto no es timidez; es lo que hace asequible la audacia. Cuando un cambio puede revertirse a bajo coste, una organización intentará cambios que jamás arriesgaría bajo una migración de todo o nada, y son precisamente esos intentos los que se acumulan hasta convertirse en una transformación real.

Diseñar para la excepción, no para el camino feliz. La mayoría de los rediseños se dibujan para la transacción que se comporta, y la mayor parte del coste reside en las que no lo hacen: el envío parcial, la factura en disputa, el cliente que existe dos veces bajo nombres ligeramente distintos. Un proceso que enruta sus excepciones a una hoja de cálculo y a un individuo dispuesto no ha sido diseñado; ha sido diseñado a medias y dejado a la buena voluntad humana para el resto. Modelamos las rutas de excepción de forma explícita, decidimos cuáles son lo bastante comunes como para merecer una ruta de primera clase a través del sistema y cuáles son genuinamente lo bastante raras como para confiarlas a un trabajo manual reflexivo, y hacemos de esa distinción una elección deliberada y no un accidente de lo que el software resultara soportar. La verdadera medida de un rediseño es cómo se comporta en su peor martes, no en el mejor.

Las formas en que fracasan estos programas son lo bastante constantes como para catalogarlas, y la mayoría son fallos de criterio y no de tecnología.

Sustitución del ERP de un solo golpe. El error individual más caro es sustituir el ERP y reinventar los procesos en una única migración simultánea en toda la empresa. La teoría es que un corte limpio evita el coste de mantener dos mundos; la práctica es que el riesgo se acumula, porque todos los problemas afloran a la vez sin manera de aislar la causa, y el negocio pierde la capacidad de retroceder. Preferimos un rediseño entregado por proceso y por dominio, con el nuevo flujo probado en un alcance acotado antes de ampliarlo. Una migración por fases es más lenta y mucho más probable que llegue a buen puerto.

Automatizar el desorden existente. Un programa que mapea el proceso actual, lo automatiza fielmente y llama transformación al resultado ha gastado muchísimo para moverse más rápido en la dirección equivocada. La automatización debe seguir al rediseño, nunca sustituirlo.

Reinventar el diagrama, no la organización. Un rediseño que cambia el sistema y el proceso pero deja intactos los incentivos, los roles y las líneas de reporte será revertido en silencio por las personas a quienes incomoda. Si el proceso es ahora interfuncional pero los bonus siguen siendo funcionales, ganan los objetivos funcionales. La propiedad del proceso sin autoridad es decoración.

Deuda de datos aplazada. Los equipos posponen de forma rutinaria el trabajo de datos maestros y de calidad por poco glamuroso, con la intención de abordarlo más tarde. Más tarde el proceso rediseñado, que suponía datos limpios y consistentes, se topa con la realidad y se atasca. La calidad de los datos no es una tarea de limpieza adyacente al proyecto; es una condición previa para que el proceso funcione siquiera. El diseño liderado por consultores sin operadores en la sala agrava esto: un rediseño dibujado enteramente por especialistas pasará por alto el conocimiento tácito de las personas que ejecutan el trabajo, la razón por la que un paso que parece redundante es en realidad portante, la excepción que ocurre cada semana y nunca se documentó. Cuando esos operadores se encuentran por primera vez con el nuevo proceso en la formación, descubren sus lagunas, y su confianza, una vez perdida, sale cara de recuperar.

Alcance por sistema en lugar de por resultado. Los programas constituidos como un proyecto de ERP o un proyecto de CRM heredan los límites del software y no los límites del trabajo, y los flujos entre sistemas, que son precisamente donde reside el valor, caen en las brechas entre las líneas de trabajo. El mandato debería nombrar un resultado y un flujo, y dejar que los sistemas queden dentro de él.

Partimos del flujo y del resultado, no del sistema. Antes de proponer cambio alguno establecemos qué se supone que debe lograr el proceso de principio a fin en términos que el negocio reconozca, tiempo transcurrido, coste de servir, conversión de efectivo, esfuerzo del cliente, y medimos el estado actual frente a ello usando los datos de eventos que los sistemas ya poseen en lugar del relato que la gente cuenta en los talleres. Esa línea base medida zanja el primer debate, si el proceso amerita reingeniería o mejora, sobre la evidencia y no sobre el entusiasmo.

Cuando el rediseño está justificado, diseñamos el proceso, el modelo de datos y la integración a la vez, tratándolos como tres vistas de una sola decisión y no como tres proyectos sucesivos. Resolvemos de forma explícita la propiedad de cada hecho compartido entre CRM, SCM y ERP, definimos la integración como contratos versionados, y hacemos de la orquestación del flujo un artefacto inspeccionable en lugar de una lógica dispersa por la configuración. El proceso rediseñado se construye para emitir su propio estado, de modo que pueda medirse en producción frente a la misma línea base que lo justificó.

Entregamos por dominio y por flujo, nunca mediante una migración de un solo golpe. Una porción acotada del proceso rediseñado se prueba en producción, sobre transacciones reales, antes de ampliarla, de modo que el riesgo permanezca aislado y el negocio conserve la capacidad de retroceder. En todo momento tratamos el cambio organizativo, la propiedad, los incentivos, los roles, como parte de la ingeniería y no como una ocurrencia tardía, porque un proceso que la organización no está dispuesta a ejecutar no sobrevivirá. Nuestro objetivo es un rediseño que siga mejorando después de que nos marchemos, porque los instrumentos para gestionarlo se incorporaron desde el principio.

Somos francos sobre el ritmo. Un rediseño que abarca tres sistemas de registro no puede terminarse honestamente en un trimestre, y cualquier propuesta que lo prometa vende una migración de golpe y no un rediseño. Secuenciamos el trabajo de modo que cada dominio arroje una mejora medible por sí mismo, lo cual gana la confianza y la atención necesarias para el siguiente, en lugar de pedir al negocio que contenga el aliento durante un programa de varios años a cambio de una única recompensa lejana. Esa secuenciación disciplina además el diseño en sí: un flujo obligado a demostrar su valía en una porción acotada no puede esconderse tras la promesa de que todo encajará al final. Si una porción no logra mejorar el resultado que se le encomendó mejorar, preferimos con mucho descubrirlo en un dominio antes que en los tres a la vez.

Lo que distingue nuestro trabajo en reingeniería de procesos es que nos negamos a tratar el CRM, la cadena de suministro y el ERP como territorios separados con rediseños separados. Sostenemos el flujo de principio a fin, los datos que discurren por él y la organización que lo opera en una sola vista, y resolvemos las cuestiones difíciles de propiedad e integración como decisiones de diseño en lugar de aplazarlas a la implementación. Esa es una conversación más difícil de iniciar y un resultado mucho más duradero de rematar.

Hay además un corolario práctico que cambia lo que el trabajo tiene permitido dar por supuesto. Cuando un encargo requiere una capacidad que aún no existe, no tiene por qué esperar a un ciclo de compras ni a la hoja de ruta de un proveedor. La Nashua 360 Enterprise Platform está construida para acomodar casi cualquier funcionalidad a buen ritmo, mediante extreme vibe coding: lo que se necesita se describe en lenguaje llano y se genera con rapidez, pero siempre dentro de principios de arquitectura firmes y bajo un aseguramiento de calidad riguroso, de modo que la velocidad nunca se logre a costa de la coherencia, la seguridad o el control. El efecto es estratégico y no meramente cómodo. Desplaza la línea entre fabricar y comprar, mantiene la opcionalidad barata, y deja que la arquitectura siga a la estrategia en lugar de que la estrategia se doblegue ante lo que hubiera en la estantería.

La recompensa por esta disciplina es un conjunto de procesos esenciales que hacen lo que el negocio realmente necesita, medidos frente a resultados que le importan, sostenidos por una arquitectura que puede cambiar sin romperse, y ejecutados por una organización dispuesta a ejecutarlos. Eso es lo que la reingeniería siempre se propuso entregar, y con las herramientas de hoy por fin puede.