Autor: MA Nautilius
En 1990, cuando buena parte de las empresas apenas comenzaba a imaginar lo que los sistemas de información podrían hacer por sus operaciones, Michael Hammer lanzó una provocación que terminaría definiendo toda una disciplina.
El problema, argumentaba, no era que las organizaciones utilizaran poca tecnología. Era que estaban utilizando tecnología nueva para ejecutar más rápido formas antiguas de trabajar.
Su artículo en Harvard Business Review, Reengineering Work: Don’t Automate, Obliterate, llevaba un título deliberadamente incómodo. Hammer observaba que muchas empresas informatizaban procesos construidos alrededor de restricciones acumuladas durante décadas. Formularios pasaban de una persona a otra porque la información no estaba disponible en otro lugar. Departamentos verificaban el trabajo de otros departamentos. Decisiones ascendían por diferentes niveles jerárquicos porque quienes realizaban el trabajo no tenían acceso a los datos necesarios para tomarlas.
La computadora podía acelerar todo aquello. Pero Hammer proponía una pregunta mucho más radical: ¿por qué conservarlo?
Más de treinta años después, esa pregunta ha regresado. Sólo que ahora tenemos agentes de IA.
Una vieja historia con una tecnología muy distinta
La primera generación de reingeniería de procesos estuvo estrechamente vinculada a la expansión de los sistemas empresariales. ERP, bases de datos, redes y posteriormente plataformas de workflow permitieron conectar actividades que antes estaban separadas.
Thomas Davenport desarrolló en aquellos años una visión complementaria. En Process Innovation, publicado en 1993, vinculó explícitamente tecnología, diseño organizacional, información y recursos humanos. La tecnología era un habilitador poderoso, pero la transformación ocurría cuando cambiaba el proceso.
Esa distinción sigue siendo fundamental. Un sistema tradicional podía registrar una orden, comprobar una condición, mover información entre aplicaciones o aplicar una regla previamente establecida. Podía automatizar una parte considerable del trabajo, pero normalmente necesitaba que la organización hubiera definido de antemano la secuencia que debía seguir.
Los agentes de IA comienzan a alterar esa relación. Un agente puede recibir un objetivo, interpretar información procedente de diferentes fuentes, utilizar herramientas, decidir qué acción realizar a continuación y coordinar una secuencia de actividades dentro de determinados límites.
Eso significa que una de las restricciones alrededor de las cuales diseñamos numerosos procesos empieza a cambiar: ya no necesitamos necesariamente una persona en cada punto donde hace falta interpretar información para decidir el siguiente paso.
Y cuando cambia una restricción fundamental, no basta con preguntar qué podemos automatizar. Hay que volver a preguntar cómo debería funcionar el proceso.
El peligro de construir un agente para cada caja
Imaginemos un proceso comercial relativamente común. Un prospecto llega a la empresa. Alguien revisa la información. Otra persona completa los datos que faltan. El CRM asigna el registro. Un ejecutivo determina si la oportunidad merece seguimiento. Quizá consulta inventario, condiciones comerciales o historial. Si necesita una excepción, solicita autorización. Después prepara una propuesta, espera una respuesta y registra el resultado.
Sobre un mapa de procesos aparecen muchas cajas. La tentación contemporánea consiste en mirar cada una y preguntar: ¿podemos poner IA aquí?
Un agente para investigar al prospecto. Otro para completar información. Un copiloto para el vendedor. Una automatización para preparar el documento. Otro agente para hacer seguimiento. Cada iniciativa puede ser razonable por separado y, aun así, el proceso resultante puede seguir siendo conceptualmente idéntico al anterior. Sólo que ahora algunas cajas funcionan más rápido.
Ese es precisamente el problema que vuelve a colocar a BPR en la conversación.
En septiembre de 2026, Masha Shunko y Serguei Netessine plantearon en Harvard Business Review que muchas organizaciones están invirtiendo en inteligencia artificial sin capturar beneficios empresariales equivalentes porque están automatizando actividades individuales sin rediseñar los workflows que realmente producen el resultado.
McKinsey llegó prácticamente al mismo punto desde la perspectiva de operaciones: los agentes no corrigen por sí mismos las deficiencias de un workflow. Colocarlos encima de una operación mal diseñada puede amplificarlas. Microsoft, al describir su patrón de transformación de procesos empresariales con agentes, advierte de un antipatrón parecido: automatizar paso por paso un proceso existente puede limitarse a conseguir que un proceso defectuoso se ejecute más rápido.
Tres fuentes distintas llegan así a una conclusión incómoda para muchos programas de IA: la tarea quizá sea una unidad demasiado pequeña para diseñar la transformación. El objeto relevante vuelve a ser el proceso completo.
A veces el problema ni siquiera está dentro de las tareas
Hay otra razón para mirar el proceso end-to-end. Los mapas tradicionales concentran nuestra atención en las actividades. Pero una parte importante de la fricción empresarial puede encontrarse precisamente en el espacio entre ellas.
Un analista termina su trabajo y envía información a otro departamento. Alguien debe revisarla. Falta un dato. Se solicita una aclaración. La respuesta tarda. Después aparece una discrepancia y comienza otra ronda de coordinación. Cuando finalmente todo está completo, el siguiente equipo puede comenzar.
Ninguna de esas actividades parece extraordinariamente costosa cuando se mide aisladamente. El problema aparece cuando se observa el tiempo transcurrido.
McKinsey denomina a este fenómeno coordination interface tax: el costo acumulado de los handoffs en los que personas deben transferir contexto, reconciliar información, obtener aprobaciones o determinar quién debe actuar después.
En uno de los workflows industriales estudiados por la firma, el procesamiento efectivo requería aproximadamente entre 12 y 24 horas, mientras que la latencia acumulada entre etapas alcanzaba entre nueve y dieciocho días. Es un caso particular y no un benchmark aplicable a cualquier empresa, pero ilustra algo importante: optimizar las cajas no necesariamente elimina el tiempo que se pierde entre ellas.
Los agentes introducen una posibilidad interesante precisamente ahí. Si un sistema puede conservar contexto, consultar múltiples fuentes, coordinar aplicaciones y decidir qué acción corresponde dentro de límites previamente definidos, algunos handoffs que antes necesitaban intervención humana pueden desaparecer por completo.
Entonces la pregunta deja de ser “¿cómo automatizamos esta transferencia?” y se convierte en “¿por qué sigue existiendo esta transferencia?” Es una diferencia pequeña en lenguaje y enorme en diseño.
Cuando quitar un handoff también significa mover autoridad
Sin embargo, eliminar pasos produce inmediatamente un problema más delicado. Supongamos que una persona revisaba una solicitud antes de enviarla al siguiente departamento. Si un agente puede hacer esa revisión, ¿puede también aprobarla?
La respuesta no depende únicamente de si técnicamente puede hacerlo. Depende de las consecuencias de equivocarse.
Aquí aparece una de las diferencias más importantes entre la reingeniería de los noventa y la reingeniería que empieza a emerger alrededor de sistemas agentivos. El diseño del proceso ahora debe incluir explícitamente derechos de decisión y grados de autonomía.
Shunko y Netessine proponen cuatro formas de distribuir esa relación entre persona e IA: Assist, Approve, Audit y Automate. En algunos puntos, la IA simplemente asiste y la persona continúa realizando el trabajo. En otros, el sistema puede preparar una decisión pero necesita aprobación antes de ejecutarla. Hay situaciones donde puede actuar y ser auditado posteriormente. Y existen actividades suficientemente acotadas para que puedan automatizarse dentro de los límites establecidos.
La elección cambia con el riesgo y, especialmente, con la reversibilidad de las consecuencias. Esto hace que la habitual expresión human in the loop resulte insuficiente. No dice qué hace el humano dentro del loop: ¿decide, autoriza, supervisa, audita una muestra, atiende únicamente las excepciones o puede detener el sistema?
Microsoft aborda el mismo problema mediante derechos de decisión: documentar qué puede decidir autónomamente un agente y qué requiere autorización humana. Visto así, la gobernanza deja de ser el documento que se prepara después de diseñar el agente. Se convierte en parte de la arquitectura del proceso.
El proceso también necesita saber qué hacer cuando la IA no sabe
Existe otra diferencia. Los procesos empresariales tradicionales fueron diseñados principalmente alrededor de personas y sistemas deterministas. Los agentes construidos sobre modelos probabilísticos introducen una condición distinta: pueden encontrarse con situaciones ambiguas para las cuales su respuesta no tenga suficiente confianza.
Eso significa que el diagrama del proceso necesita algo más que el camino ideal. Necesita diseñar la incertidumbre.
¿Qué ocurre cuando faltan datos? ¿Cuándo debe detenerse el agente? ¿Cuándo debe solicitar información adicional? ¿Qué acción puede revertirse? ¿En qué momento una persona debe intervenir? ¿Cómo se registra la razón de una excepción?
Shunko y Netessine llaman la atención sobre la necesidad de diseñar ese unhappy path antes de desplegar la automatización. Durante años, muchos procesos se diseñaron suponiendo que las excepciones eran desviaciones del sistema. En un entorno agentivo, la capacidad de reconocer, escalar y aprender de las excepciones puede convertirse en parte central del propio diseño.
Ya no diseñamos únicamente el camino por el que queremos que avance el trabajo. Diseñamos también qué debe hacer el sistema cuando no debería avanzar.
BPM empieza a cambiar de significado
Esta transformación ya está comenzando a aparecer en la literatura académica. En 2026, Diego Calvanese, Marlon Dumas y un amplio grupo internacional de investigadores publicaron en Information Systems un manifiesto sobre Agentic Business Process Management (APM).
BPM tradicionalmente ha tratado los procesos como estructuras que pueden modelarse, ejecutarse, analizarse y mejorarse. APM comienza a explorar qué sucede cuando dentro de esas estructuras participan agentes humanos y de software capaces de percibir, razonar y actuar con cierto grado de autonomía.
Los autores plantean cuatro capacidades especialmente relevantes: autonomía enmarcada, explicabilidad, capacidad de convertir interacciones conversacionales en acciones y posibilidad de modificar determinados comportamientos dentro de un marco establecido.
No estamos ante una disciplina madura. El propio artículo se presenta como manifiesto y agenda de investigación. Quedan preguntas importantes sobre control, cumplimiento, verificación y comportamiento emergente. Pero su aparición señala un cambio conceptual.
Durante décadas preguntamos cómo conseguir que la tecnología ejecutara un proceso que habíamos definido. Ahora empezamos a preguntar cómo gobernar un proceso en el que algunos participantes tecnológicos pueden decidir cómo ejecutar partes del trabajo.
Volver a una hoja en blanco
En paralelo está apareciendo en la práctica profesional el concepto de Zero-Based Process Redesign (ZBPR).
Conviene tratarlo con cuidado. A diferencia de BPR o BPM, no existe todavía una literatura académica comparable que permita considerarlo una disciplina consolidada. Capgemini Invent e InformationWeek, entre otras fuentes, lo utilizan recientemente para describir un enfoque de rediseño desde cero alrededor de las capacidades actuales de la IA.
Su intuición, sin embargo, resulta familiar. En vez de comenzar con el proceso existente y preguntar dónde colocar agentes, se comienza con el resultado y se pregunta qué proceso construiríamos hoy.
Imaginemos de nuevo el proceso comercial. Si diseñáramos desde cero, quizá no existiría un paso para capturar manualmente información y otro para validarla. Tal vez la información se obtendría directamente de sistemas autorizados y se verificaría durante la misma interacción.
Quizá tampoco existiría una asignación manual seguida de una revisión seguida de otra aprobación. Podría existir un sistema que mantuviera el contexto del caso y sólo involucrara a una persona cuando apareciera una decisión que excediera sus límites.
El resultado podría no ser un proceso con las mismas diez actividades automatizadas. Podría ser un proceso con cuatro.
Ahí está la diferencia entre automatizar trabajo y eliminar trabajo que dejó de ser necesario. Y, paradójicamente, esa idea que parece tan propia de la era agentiva nos devuelve directamente a Hammer.
No todo merece ser destruido y reconstruido
La historia de BPR también contiene una advertencia. La búsqueda de transformaciones radicales puede convertirse fácilmente en dogma.
No todos los procesos empresariales están rotos. No todo handoff carece de valor. No toda aprobación es burocracia. Y no toda intervención humana es una ineficiencia esperando ser automatizada.
Una aprobación puede existir porque alguien debe asumir responsabilidad económica. Una separación entre funciones puede ser un control deliberado. Una segunda revisión puede proteger al cliente. Un procedimiento aparentemente lento puede responder a una obligación regulatoria o a un riesgo que no aparece en el diagrama simplificado.
Por eso la alternativa no debería plantearse como “automatización incremental versus reingeniería radical” con una respuesta universal. Procesos maduros y estables pueden beneficiarse enormemente de Lean, Six Sigma, automatización tradicional, copilotos o agentes que asistan actividades específicas.
La reingeniería se vuelve especialmente interesante cuando encontramos otra clase de síntomas: numerosos handoffs, duplicación de información, esperas entre departamentos, reconciliaciones manuales, controles repetidos, decisiones construidas alrededor de información que antes era difícil obtener o estructuras que existen principalmente porque los sistemas históricos no podían comunicarse.
En esos casos, automatizar primero puede producir un efecto indeseado: convertir un proceso heredado en infraestructura tecnológica y hacerlo todavía más costoso de modificar después.
Antes de poner un agente, redibujar el proceso
De la literatura clásica y de los trabajos recientes surge una secuencia bastante más útil que empezar haciendo un inventario de casos de uso de IA.
Primero habría que establecer con claridad qué resultado produce el proceso y para quién. Después conviene reconstruir cómo se genera realmente ese resultado, incluyendo no sólo las actividades sino las esperas, transferencias de contexto, verificaciones, reconciliaciones y decisiones que ocurren entre ellas.
Sólo entonces tiene sentido preguntar cuáles de esos elementos siguen siendo necesarios. Algunos existirán porque aportan valor. Otros porque gestionan un riesgo real. Otros porque cumplen una obligación. Pero probablemente aparecerá una cuarta categoría: actividades que existen porque, cuando el proceso fue diseñado, personas y sistemas tenían limitaciones que hoy pueden haber cambiado.
Es ahí donde la IA agentiva merece entrar en la conversación. No para recibir automáticamente todo el trabajo disponible, sino para reconsiderar la arquitectura.
El siguiente paso consiste en distribuir ese trabajo entre personas, software determinista y agentes. Y junto con el trabajo hay que distribuir autoridad: qué puede ejecutar un agente, qué puede decidir, qué necesita aprobación, qué puede auditarse posteriormente y qué nunca debería ejecutar autónomamente.
Finalmente aparece la pregunta que con frecuencia llega demasiado tarde: cómo sabremos que el proceso nuevo es realmente mejor. No basta con que una tarea tarde menos. La medición tiene que regresar al resultado que justificó el rediseño.
La paradoja de la reingeniería agentiva
Después de revisar más de tres décadas de pensamiento sobre procesos, quizá la conclusión más interesante sea que la IA agentiva no vuelve obsoleto al Business Process Reengineering. Lo vuelve sorprendentemente actual.
En 1990, Hammer advertía que informatizar un proceso heredado podía significar utilizar una tecnología extraordinaria para preservar una forma anticuada de trabajar. En 2026 corremos exactamente el mismo riesgo, sólo que con herramientas mucho más capaces.
Podemos construir un agente para cada actividad, conectar cada departamento, automatizar cada transferencia y producir demostraciones técnicamente impresionantes. Y terminar con el mismo proceso.
La oportunidad más profunda aparece cuando dejamos de considerar el workflow existente como una restricción y lo tratamos como una hipótesis.
¿Por qué existe este paso? ¿Por qué esta información cambia de manos? ¿Por qué alguien necesita aprobar esto? ¿Por qué el cliente espera mientras dos áreas se coordinan? ¿Qué riesgo protege realmente este control? ¿Qué trabajo desaparecería si información, razonamiento y ejecución pudieran ocurrir de otra manera?
Algunas respuestas demostrarán que el proceso actual está bien diseñado. Otras justificarán una automatización puntual.
Pero habrá ocasiones en que la respuesta obligue a borrar varias cajas del diagrama.
Ahí empieza realmente la reingeniería.
La pregunta decisiva para una empresa que adopta agentes de IA quizá no sea cuántos agentes puede desplegar, sino algo mucho más incómodo:
si hoy diseñáramos esta empresa con las capacidades que tenemos disponibles, ¿construiríamos este proceso otra vez?
Perspectiva Zherpa
Esta investigación también permite situar con mayor precisión el concepto de Capacidad Agentiva utilizado por Zherpa. En su definición pública, no se trata simplemente de desplegar un agente, sino de integrar capacidad de IA a un proceso real con propósito, permisos, límites, continuidad y medición de su contribución.
La investigación no depende de este marco ni pretende utilizar la evidencia externa para validarlo. La coincidencia relevante está en otro lugar: los trabajos recientes revisados desplazan el centro de atención desde la herramienta hacia el sistema de trabajo en el que ésta actúa.
Ese cambio de perspectiva importa. Porque un agente puede ejecutar. Pero sigue siendo la empresa la que debe decidir qué trabajo merece existir, qué autoridad está dispuesta a delegar y qué resultado justificará haber rediseñado el proceso.
Fuentes principales
- Michael Hammer, Reengineering Work: Don’t Automate, Obliterate, Harvard Business Review, 1990.
- Thomas H. Davenport, Process Innovation: Reengineering Work Through Information Technology, Harvard Business School Press, 1993.
- H.A. Reijers y S. Limam Mansar, Best practices in business process redesign, Omega, 2005.
- Masha Shunko y Serguei Netessine, Stop Automating Old Processes. Design New Ones Instead., Harvard Business Review, septiembre de 2026.
- McKinsey & Company, Stacking the odds: A blueprint for successfully scaling agentic AI, septiembre de 2026.
- McKinsey & Company, Cutting the “coordination tax”: How agentic AI can reshape workflows, septiembre de 2026.
- Microsoft Learn, Core business process transformation pattern, 2026.
- Diego Calvanese et al., Agentic Business Process Management: A Research Manifesto, Information Systems, 2026.
- Capgemini Invent, From zero to autonomous: Redesigning operations with agentic AI.
- InformationWeek, Drive Agentic AI Outcomes With Zero-Based Process Redesign.
- Eraneos, Redesigning for AI: The process building blocks for enterprise transformation.
