{"id":165,"date":"2026-09-20T02:15:46","date_gmt":"2026-09-20T08:15:46","guid":{"rendered":"https:\/\/zherpa.ai\/blog\/?p=165"},"modified":"2026-09-20T02:22:33","modified_gmt":"2026-09-20T08:22:33","slug":"reingenieria-procesos-agentes-ia-bpr","status":"publish","type":"post","link":"https:\/\/zherpa.ai\/blog\/investigacion\/reingenieria-procesos-agentes-ia-bpr\/","title":{"rendered":"Reingenier\u00eda de procesos en la era de los agentes de IA: el error de automatizar el pasado"},"content":{"rendered":"

Autor: MA Nautilius<\/strong><\/p>\n

En 1990, cuando buena parte de las empresas apenas comenzaba a imaginar lo que los sistemas de informaci\u00f3n podr\u00edan hacer por sus operaciones, Michael Hammer lanz\u00f3 una provocaci\u00f3n que terminar\u00eda definiendo toda una disciplina.<\/p>\n

El problema, argumentaba, no era que las organizaciones utilizaran poca tecnolog\u00eda. Era que estaban utilizando tecnolog\u00eda nueva para ejecutar m\u00e1s r\u00e1pido formas antiguas de trabajar.<\/p>\n

Su art\u00edculo en Harvard Business Review<\/em>, Reengineering Work: Don\u2019t Automate, Obliterate<\/em><\/a>, llevaba un t\u00edtulo deliberadamente inc\u00f3modo. Hammer observaba que muchas empresas informatizaban procesos construidos alrededor de restricciones acumuladas durante d\u00e9cadas. Formularios pasaban de una persona a otra porque la informaci\u00f3n no estaba disponible en otro lugar. Departamentos verificaban el trabajo de otros departamentos. Decisiones ascend\u00edan por diferentes niveles jer\u00e1rquicos porque quienes realizaban el trabajo no ten\u00edan acceso a los datos necesarios para tomarlas.<\/p>\n

La computadora pod\u00eda acelerar todo aquello. Pero Hammer propon\u00eda una pregunta mucho m\u00e1s radical: \u00bfpor qu\u00e9 conservarlo?<\/strong><\/p>\n

M\u00e1s de treinta a\u00f1os despu\u00e9s, esa pregunta ha regresado. S\u00f3lo que ahora tenemos agentes de IA.<\/p>\n

Una vieja historia con una tecnolog\u00eda muy distinta<\/h2>\n

La primera generaci\u00f3n de reingenier\u00eda de procesos estuvo estrechamente vinculada a la expansi\u00f3n de los sistemas empresariales. ERP, bases de datos, redes y posteriormente plataformas de workflow permitieron conectar actividades que antes estaban separadas.<\/p>\n

Thomas Davenport desarroll\u00f3 en aquellos a\u00f1os una visi\u00f3n complementaria. En Process Innovation<\/em><\/a>, publicado en 1993, vincul\u00f3 expl\u00edcitamente tecnolog\u00eda, dise\u00f1o organizacional, informaci\u00f3n y recursos humanos. La tecnolog\u00eda era un habilitador poderoso, pero la transformaci\u00f3n ocurr\u00eda cuando cambiaba el proceso.<\/p>\n

Esa distinci\u00f3n sigue siendo fundamental. Un sistema tradicional pod\u00eda registrar una orden, comprobar una condici\u00f3n, mover informaci\u00f3n entre aplicaciones o aplicar una regla previamente establecida. Pod\u00eda automatizar una parte considerable del trabajo, pero normalmente necesitaba que la organizaci\u00f3n hubiera definido de antemano la secuencia que deb\u00eda seguir.<\/p>\n

Los agentes de IA comienzan a alterar esa relaci\u00f3n. Un agente puede recibir un objetivo, interpretar informaci\u00f3n procedente de diferentes fuentes, utilizar herramientas, decidir qu\u00e9 acci\u00f3n realizar a continuaci\u00f3n y coordinar una secuencia de actividades dentro de determinados l\u00edmites.<\/p>\n

Eso significa que una de las restricciones alrededor de las cuales dise\u00f1amos numerosos procesos empieza a cambiar: ya no necesitamos necesariamente una persona en cada punto donde hace falta interpretar informaci\u00f3n para decidir el siguiente paso.<\/strong><\/p>\n

Y cuando cambia una restricci\u00f3n fundamental, no basta con preguntar qu\u00e9 podemos automatizar. Hay que volver a preguntar c\u00f3mo deber\u00eda funcionar el proceso.<\/p>\n

El peligro de construir un agente para cada caja<\/h2>\n

Imaginemos un proceso comercial relativamente com\u00fan. Un prospecto llega a la empresa. Alguien revisa la informaci\u00f3n. Otra persona completa los datos que faltan. El CRM asigna el registro. Un ejecutivo determina si la oportunidad merece seguimiento. Quiz\u00e1 consulta inventario, condiciones comerciales o historial. Si necesita una excepci\u00f3n, solicita autorizaci\u00f3n. Despu\u00e9s prepara una propuesta, espera una respuesta y registra el resultado.<\/p>\n

Sobre un mapa de procesos aparecen muchas cajas. La tentaci\u00f3n contempor\u00e1nea consiste en mirar cada una y preguntar: \u00bfpodemos poner IA aqu\u00ed?<\/strong><\/p>\n

Un agente para investigar al prospecto. Otro para completar informaci\u00f3n. Un copiloto para el vendedor. Una automatizaci\u00f3n para preparar el documento. Otro agente para hacer seguimiento. Cada iniciativa puede ser razonable por separado y, aun as\u00ed, el proceso resultante puede seguir siendo conceptualmente id\u00e9ntico al anterior. S\u00f3lo que ahora algunas cajas funcionan m\u00e1s r\u00e1pido.<\/p>\n

Ese es precisamente el problema que vuelve a colocar a BPR en la conversaci\u00f3n.<\/p>\n

En septiembre de 2026, Masha Shunko y Serguei Netessine plantearon en Harvard Business Review<\/em><\/a> que muchas organizaciones est\u00e1n invirtiendo en inteligencia artificial sin capturar beneficios empresariales equivalentes porque est\u00e1n automatizando actividades individuales sin redise\u00f1ar los workflows que realmente producen el resultado.<\/p>\n

McKinsey<\/a> lleg\u00f3 pr\u00e1cticamente al mismo punto desde la perspectiva de operaciones: los agentes no corrigen por s\u00ed mismos las deficiencias de un workflow. Colocarlos encima de una operaci\u00f3n mal dise\u00f1ada puede amplificarlas. Microsoft<\/a>, al describir su patr\u00f3n de transformaci\u00f3n de procesos empresariales con agentes, advierte de un antipatr\u00f3n parecido: automatizar paso por paso un proceso existente puede limitarse a conseguir que un proceso defectuoso se ejecute m\u00e1s r\u00e1pido.<\/p>\n

Tres fuentes distintas llegan as\u00ed a una conclusi\u00f3n inc\u00f3moda para muchos programas de IA: la tarea quiz\u00e1 sea una unidad demasiado peque\u00f1a para dise\u00f1ar la transformaci\u00f3n.<\/strong> El objeto relevante vuelve a ser el proceso completo.<\/p>\n

A veces el problema ni siquiera est\u00e1 dentro de las tareas<\/h2>\n

Hay otra raz\u00f3n para mirar el proceso end-to-end. Los mapas tradicionales concentran nuestra atenci\u00f3n en las actividades. Pero una parte importante de la fricci\u00f3n empresarial puede encontrarse precisamente en el espacio entre ellas.<\/p>\n

Un analista termina su trabajo y env\u00eda informaci\u00f3n a otro departamento. Alguien debe revisarla. Falta un dato. Se solicita una aclaraci\u00f3n. La respuesta tarda. Despu\u00e9s aparece una discrepancia y comienza otra ronda de coordinaci\u00f3n. Cuando finalmente todo est\u00e1 completo, el siguiente equipo puede comenzar.<\/p>\n

Ninguna de esas actividades parece extraordinariamente costosa cuando se mide aisladamente. El problema aparece cuando se observa el tiempo transcurrido.<\/p>\n

McKinsey denomina a este fen\u00f3meno coordination interface tax<\/strong><\/a>: el costo acumulado de los handoffs en los que personas deben transferir contexto, reconciliar informaci\u00f3n, obtener aprobaciones o determinar qui\u00e9n debe actuar despu\u00e9s.<\/p>\n

En uno de los workflows industriales estudiados por la firma, el procesamiento efectivo requer\u00eda aproximadamente entre 12 y 24 horas, mientras que la latencia acumulada entre etapas alcanzaba entre nueve y dieciocho d\u00edas. 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.<\/p>\n

Los agentes introducen una posibilidad interesante precisamente ah\u00ed. Si un sistema puede conservar contexto, consultar m\u00faltiples fuentes, coordinar aplicaciones y decidir qu\u00e9 acci\u00f3n corresponde dentro de l\u00edmites previamente definidos, algunos handoffs que antes necesitaban intervenci\u00f3n humana pueden desaparecer por completo.<\/p>\n

Entonces la pregunta deja de ser \u201c\u00bfc\u00f3mo automatizamos esta transferencia?\u201d y se convierte en \u201c\u00bfpor qu\u00e9 sigue existiendo esta transferencia?\u201d<\/strong> Es una diferencia peque\u00f1a en lenguaje y enorme en dise\u00f1o.<\/p>\n

Cuando quitar un handoff tambi\u00e9n significa mover autoridad<\/h2>\n

Sin embargo, eliminar pasos produce inmediatamente un problema m\u00e1s delicado. Supongamos que una persona revisaba una solicitud antes de enviarla al siguiente departamento. Si un agente puede hacer esa revisi\u00f3n, \u00bfpuede tambi\u00e9n aprobarla?<\/p>\n

La respuesta no depende \u00fanicamente de si t\u00e9cnicamente puede hacerlo. Depende de las consecuencias de equivocarse.<\/p>\n

Aqu\u00ed aparece una de las diferencias m\u00e1s importantes entre la reingenier\u00eda de los noventa y la reingenier\u00eda que empieza a emerger alrededor de sistemas agentivos. El dise\u00f1o del proceso ahora debe incluir expl\u00edcitamente derechos de decisi\u00f3n y grados de autonom\u00eda<\/strong>.<\/p>\n

Shunko y Netessine proponen cuatro formas de distribuir esa relaci\u00f3n entre persona e IA: Assist, Approve, Audit<\/em> y Automate<\/em>. En algunos puntos, la IA simplemente asiste y la persona contin\u00faa realizando el trabajo. En otros, el sistema puede preparar una decisi\u00f3n pero necesita aprobaci\u00f3n 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\u00edmites establecidos.<\/p>\n

La elecci\u00f3n cambia con el riesgo y, especialmente, con la reversibilidad de las consecuencias. Esto hace que la habitual expresi\u00f3n human in the loop<\/em> resulte insuficiente. No dice qu\u00e9 hace el humano dentro del loop: \u00bfdecide, autoriza, supervisa, audita una muestra, atiende \u00fanicamente las excepciones o puede detener el sistema?<\/p>\n

Microsoft aborda el mismo problema mediante derechos de decisi\u00f3n: documentar qu\u00e9 puede decidir aut\u00f3nomamente un agente y qu\u00e9 requiere autorizaci\u00f3n humana. Visto as\u00ed, la gobernanza deja de ser el documento que se prepara despu\u00e9s de dise\u00f1ar el agente. Se convierte en parte de la arquitectura del proceso.<\/strong><\/p>\n

El proceso tambi\u00e9n necesita saber qu\u00e9 hacer cuando la IA no sabe<\/h2>\n

Existe otra diferencia. Los procesos empresariales tradicionales fueron dise\u00f1ados principalmente alrededor de personas y sistemas deterministas. Los agentes construidos sobre modelos probabil\u00edsticos introducen una condici\u00f3n distinta: pueden encontrarse con situaciones ambiguas para las cuales su respuesta no tenga suficiente confianza.<\/p>\n

Eso significa que el diagrama del proceso necesita algo m\u00e1s que el camino ideal. Necesita dise\u00f1ar la incertidumbre.<\/p>\n

\u00bfQu\u00e9 ocurre cuando faltan datos? \u00bfCu\u00e1ndo debe detenerse el agente? \u00bfCu\u00e1ndo debe solicitar informaci\u00f3n adicional? \u00bfQu\u00e9 acci\u00f3n puede revertirse? \u00bfEn qu\u00e9 momento una persona debe intervenir? \u00bfC\u00f3mo se registra la raz\u00f3n de una excepci\u00f3n?<\/p>\n

Shunko y Netessine llaman la atenci\u00f3n sobre la necesidad de dise\u00f1ar ese unhappy path<\/em> antes de desplegar la automatizaci\u00f3n. Durante a\u00f1os, muchos procesos se dise\u00f1aron 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\u00f1o.<\/p>\n

Ya no dise\u00f1amos \u00fanicamente el camino por el que queremos que avance el trabajo. Dise\u00f1amos tambi\u00e9n qu\u00e9 debe hacer el sistema cuando no deber\u00eda avanzar.<\/p>\n

BPM empieza a cambiar de significado<\/h2>\n

Esta transformaci\u00f3n ya est\u00e1 comenzando a aparecer en la literatura acad\u00e9mica. En 2026, Diego Calvanese, Marlon Dumas y un amplio grupo internacional de investigadores publicaron en Information Systems<\/em> un manifiesto sobre Agentic Business Process Management (APM)<\/strong><\/a>.<\/p>\n

BPM tradicionalmente ha tratado los procesos como estructuras que pueden modelarse, ejecutarse, analizarse y mejorarse. APM comienza a explorar qu\u00e9 sucede cuando dentro de esas estructuras participan agentes humanos y de software capaces de percibir, razonar y actuar con cierto grado de autonom\u00eda.<\/p>\n

Los autores plantean cuatro capacidades especialmente relevantes: autonom\u00eda enmarcada, explicabilidad, capacidad de convertir interacciones conversacionales en acciones y posibilidad de modificar determinados comportamientos dentro de un marco establecido.<\/p>\n

No estamos ante una disciplina madura. El propio art\u00edculo se presenta como manifiesto y agenda de investigaci\u00f3n. Quedan preguntas importantes sobre control, cumplimiento, verificaci\u00f3n y comportamiento emergente. Pero su aparici\u00f3n se\u00f1ala un cambio conceptual.<\/p>\n

Durante d\u00e9cadas preguntamos c\u00f3mo conseguir que la tecnolog\u00eda ejecutara un proceso que hab\u00edamos definido. Ahora empezamos a preguntar c\u00f3mo gobernar un proceso en el que algunos participantes tecnol\u00f3gicos pueden decidir c\u00f3mo ejecutar partes del trabajo.<\/p>\n

Volver a una hoja en blanco<\/h2>\n

En paralelo est\u00e1 apareciendo en la pr\u00e1ctica profesional el concepto de Zero-Based Process Redesign (ZBPR)<\/strong>.<\/p>\n

Conviene tratarlo con cuidado. A diferencia de BPR o BPM, no existe todav\u00eda una literatura acad\u00e9mica comparable que permita considerarlo una disciplina consolidada. Capgemini Invent<\/a> e InformationWeek<\/em><\/a>, entre otras fuentes, lo utilizan recientemente para describir un enfoque de redise\u00f1o desde cero alrededor de las capacidades actuales de la IA.<\/p>\n

Su intuici\u00f3n, sin embargo, resulta familiar. En vez de comenzar con el proceso existente y preguntar d\u00f3nde colocar agentes, se comienza con el resultado y se pregunta qu\u00e9 proceso construir\u00edamos hoy.<\/p>\n

Imaginemos de nuevo el proceso comercial. Si dise\u00f1\u00e1ramos desde cero, quiz\u00e1 no existir\u00eda un paso para capturar manualmente informaci\u00f3n y otro para validarla. Tal vez la informaci\u00f3n se obtendr\u00eda directamente de sistemas autorizados y se verificar\u00eda durante la misma interacci\u00f3n.<\/p>\n

Quiz\u00e1 tampoco existir\u00eda una asignaci\u00f3n manual seguida de una revisi\u00f3n seguida de otra aprobaci\u00f3n. Podr\u00eda existir un sistema que mantuviera el contexto del caso y s\u00f3lo involucrara a una persona cuando apareciera una decisi\u00f3n que excediera sus l\u00edmites.<\/p>\n

El resultado podr\u00eda no ser un proceso con las mismas diez actividades automatizadas. Podr\u00eda ser un proceso con cuatro.<\/p>\n

Ah\u00ed est\u00e1 la diferencia entre automatizar trabajo y eliminar trabajo que dej\u00f3 de ser necesario<\/strong>. Y, parad\u00f3jicamente, esa idea que parece tan propia de la era agentiva nos devuelve directamente a Hammer.<\/p>\n

No todo merece ser destruido y reconstruido<\/h2>\n

La historia de BPR tambi\u00e9n contiene una advertencia. La b\u00fasqueda de transformaciones radicales puede convertirse f\u00e1cilmente en dogma.<\/p>\n

No todos los procesos empresariales est\u00e1n rotos. No todo handoff carece de valor. No toda aprobaci\u00f3n es burocracia. Y no toda intervenci\u00f3n humana es una ineficiencia esperando ser automatizada.<\/p>\n

Una aprobaci\u00f3n puede existir porque alguien debe asumir responsabilidad econ\u00f3mica. Una separaci\u00f3n entre funciones puede ser un control deliberado. Una segunda revisi\u00f3n puede proteger al cliente. Un procedimiento aparentemente lento puede responder a una obligaci\u00f3n regulatoria o a un riesgo que no aparece en el diagrama simplificado.<\/p>\n

Por eso la alternativa no deber\u00eda plantearse como \u201cautomatizaci\u00f3n incremental versus reingenier\u00eda radical\u201d con una respuesta universal. Procesos maduros y estables pueden beneficiarse enormemente de Lean, Six Sigma, automatizaci\u00f3n tradicional, copilotos o agentes que asistan actividades espec\u00edficas.<\/p>\n

La reingenier\u00eda se vuelve especialmente interesante cuando encontramos otra clase de s\u00edntomas: numerosos handoffs, duplicaci\u00f3n de informaci\u00f3n, esperas entre departamentos, reconciliaciones manuales, controles repetidos, decisiones construidas alrededor de informaci\u00f3n que antes era dif\u00edcil obtener o estructuras que existen principalmente porque los sistemas hist\u00f3ricos no pod\u00edan comunicarse.<\/p>\n

En esos casos, automatizar primero puede producir un efecto indeseado: convertir un proceso heredado en infraestructura tecnol\u00f3gica y hacerlo todav\u00eda m\u00e1s costoso de modificar despu\u00e9s.<\/p>\n

Antes de poner un agente, redibujar el proceso<\/h2>\n

De la literatura cl\u00e1sica y de los trabajos recientes surge una secuencia bastante m\u00e1s \u00fatil que empezar haciendo un inventario de casos de uso de IA.<\/p>\n

Primero habr\u00eda que establecer con claridad qu\u00e9 resultado produce el proceso y para qui\u00e9n. Despu\u00e9s conviene reconstruir c\u00f3mo se genera realmente ese resultado, incluyendo no s\u00f3lo las actividades sino las esperas, transferencias de contexto, verificaciones, reconciliaciones y decisiones que ocurren entre ellas.<\/p>\n

S\u00f3lo entonces tiene sentido preguntar cu\u00e1les de esos elementos siguen siendo necesarios. Algunos existir\u00e1n porque aportan valor. Otros porque gestionan un riesgo real. Otros porque cumplen una obligaci\u00f3n. Pero probablemente aparecer\u00e1 una cuarta categor\u00eda: actividades que existen porque, cuando el proceso fue dise\u00f1ado, personas y sistemas ten\u00edan limitaciones que hoy pueden haber cambiado.<\/p>\n

Es ah\u00ed donde la IA agentiva merece entrar en la conversaci\u00f3n. No para recibir autom\u00e1ticamente todo el trabajo disponible, sino para reconsiderar la arquitectura.<\/p>\n

El siguiente paso consiste en distribuir ese trabajo entre personas, software determinista y agentes. Y junto con el trabajo hay que distribuir autoridad: qu\u00e9 puede ejecutar un agente, qu\u00e9 puede decidir, qu\u00e9 necesita aprobaci\u00f3n, qu\u00e9 puede auditarse posteriormente y qu\u00e9 nunca deber\u00eda ejecutar aut\u00f3nomamente.<\/p>\n

Finalmente aparece la pregunta que con frecuencia llega demasiado tarde: c\u00f3mo sabremos que el proceso nuevo es realmente mejor. No basta con que una tarea tarde menos. La medici\u00f3n tiene que regresar al resultado que justific\u00f3 el redise\u00f1o.<\/p>\n

La paradoja de la reingenier\u00eda agentiva<\/h2>\n

Despu\u00e9s de revisar m\u00e1s de tres d\u00e9cadas de pensamiento sobre procesos, quiz\u00e1 la conclusi\u00f3n m\u00e1s interesante sea que la IA agentiva no vuelve obsoleto al Business Process Reengineering. Lo vuelve sorprendentemente actual.<\/p>\n

En 1990, Hammer advert\u00eda que informatizar un proceso heredado pod\u00eda significar utilizar una tecnolog\u00eda extraordinaria para preservar una forma anticuada de trabajar. En 2026 corremos exactamente el mismo riesgo, s\u00f3lo que con herramientas mucho m\u00e1s capaces.<\/p>\n

Podemos construir un agente para cada actividad, conectar cada departamento, automatizar cada transferencia y producir demostraciones t\u00e9cnicamente impresionantes. Y terminar con el mismo proceso.<\/p>\n

La oportunidad m\u00e1s profunda aparece cuando dejamos de considerar el workflow existente como una restricci\u00f3n y lo tratamos como una hip\u00f3tesis.<\/p>\n

\u00bfPor qu\u00e9 existe este paso? \u00bfPor qu\u00e9 esta informaci\u00f3n cambia de manos? \u00bfPor qu\u00e9 alguien necesita aprobar esto? \u00bfPor qu\u00e9 el cliente espera mientras dos \u00e1reas se coordinan? \u00bfQu\u00e9 riesgo protege realmente este control? \u00bfQu\u00e9 trabajo desaparecer\u00eda si informaci\u00f3n, razonamiento y ejecuci\u00f3n pudieran ocurrir de otra manera?<\/p>\n

Algunas respuestas demostrar\u00e1n que el proceso actual est\u00e1 bien dise\u00f1ado. Otras justificar\u00e1n una automatizaci\u00f3n puntual.<\/p>\n

Pero habr\u00e1 ocasiones en que la respuesta obligue a borrar varias cajas del diagrama.<\/p>\n

Ah\u00ed empieza realmente la reingenier\u00eda.<\/p>\n

La pregunta decisiva para una empresa que adopta agentes de IA quiz\u00e1 no sea cu\u00e1ntos agentes puede desplegar, sino algo mucho m\u00e1s inc\u00f3modo:<\/p>\n

si hoy dise\u00f1\u00e1ramos esta empresa con las capacidades que tenemos disponibles, \u00bfconstruir\u00edamos este proceso otra vez?<\/strong><\/p>\n

Perspectiva Zherpa<\/h2>\n

Esta investigaci\u00f3n tambi\u00e9n permite situar con mayor precisi\u00f3n el concepto de Capacidad Agentiva<\/strong> utilizado por Zherpa. En su definici\u00f3n p\u00fablica, no se trata simplemente de desplegar un agente, sino de integrar capacidad de IA a un proceso real con prop\u00f3sito, permisos, l\u00edmites, continuidad y medici\u00f3n de su contribuci\u00f3n.<\/p>\n

La investigaci\u00f3n no depende de este marco ni pretende utilizar la evidencia externa para validarlo. La coincidencia relevante est\u00e1 en otro lugar: los trabajos recientes revisados desplazan el centro de atenci\u00f3n desde la herramienta hacia el sistema de trabajo en el que \u00e9sta act\u00faa.<\/p>\n

Ese cambio de perspectiva importa. Porque un agente puede ejecutar. Pero sigue siendo la empresa la que debe decidir qu\u00e9 trabajo merece existir, qu\u00e9 autoridad est\u00e1 dispuesta a delegar y qu\u00e9 resultado justificar\u00e1 haber redise\u00f1ado el proceso.<\/p>\n

Fuentes principales<\/h2>\n