Reingeniería de procesos: qué es, tipos y cómo aplicarla

La reingeniería de procesos suele explicarse como si siempre hubiera que empezar de una hoja en blanco. En la práctica, la mayoría de las operaciones medianas y grandes no puede darse ese lujo: dependen de un ERP, un CRM o un core bancario o asegurador que no van a reemplazar.

Esta guía cubre qué es la reingeniería de procesos, en qué se diferencia de automatizar o mejorar de forma gradual, qué tipos y etapas tiene, y cómo aplicarla cuando el rediseño no puede partir de cero.

Qué es la reingeniería de procesos y en qué se diferencia de automatizar o mejorar un proceso existente

La reingeniería de procesos empresariales, conocida como BPR por sus siglas en inglés, es un rediseño radical de un proceso de negocio. No es un ajuste, una mejora incremental ni una capa de tecnología sobre lo que ya existe.

IBM distingue la BPR de otras dos disciplinas cercanas. La gestión de procesos de negocio, BPM, coordina y administra procesos existentes de forma continua. La mejora de procesos de negocio, BPI, ajusta procesos ya existentes de forma gradual. La BPR, en cambio, implica repensar y rediseñar el proceso desde sus objetivos, según describe IBM.

Automatizar tampoco es lo mismo que rediseñar. Automatizar conecta sistemas y reglas de negocio para que un proceso ya definido corra sin que una persona lo empuje paso a paso, como desarrolla la guía sobre automatización de procesos. La reingeniería ocurre antes: define cómo debería funcionar ese proceso desde cero, y recién después llega el momento de automatizar lo que se rediseñó.

El origen de la reingeniería y los tres tipos que distingue la disciplina

La reingeniería de procesos tiene sus raíces en los años 80 en Norteamérica, desarrollada por los consultores Michael Hammer y James Champy, según ubica Inesdi. La metodología ganó protagonismo en 1993, cuando Hammer y Champy publicaron el libro 'Reengineering the Corporation', que planteaba rediseñar procesos de forma fundamental en lugar de mejorarlos paso a paso, según señala IBM.

Inesdi distingue tres tipos de reingeniería. La administrativa rediseña la gestión, las decisiones y los recursos de la organización. La organizacional rediseña la estructura y la cultura de la empresa. Y la reingeniería de procesos empresariales, la BPR, rediseña de forma radical los procesos más importantes de la operación, según Inesdi. Esta guía se centra en ese tercer tipo.

Las etapas de un proyecto de reingeniería, de evaluar el estado actual a implementar el cambio

IBM describe seis pasos dentro de un proyecto de BPR: definir los objetivos del rediseño, evaluar el estado actual del proceso, identificar las brechas entre ese estado y el objetivo, diseñar el estado futuro del proceso, implementar los cambios y, por último, evaluar los resultados e iterar, según IBM.

Inesdi describe un recorrido similar en seis etapas: preparación y sensibilización del equipo, identificación y análisis del proceso actual, diseño del nuevo proceso, implementación y gestión del cambio, y monitorización y mejora continua, según Inesdi. Ambas fuentes coinciden en un punto central: el rediseño llega después de entender a fondo cómo funciona el proceso hoy, no antes.

Cuándo conviene un rediseño total y cuándo conviene rediseñar sin reemplazar el ERP, el CRM o el core existente

La mayoría de las guías sobre reingeniería tratan el rediseño como si siempre partiera de una hoja en blanco, sin sistemas previos que condicionen el diseño. En una operación mediana o grande, esa condición casi nunca se cumple: hay un ERP, un CRM o un core bancario o asegurador que la empresa no va a reemplazar, por costo, por riesgo regulatorio o porque ya sostiene el negocio todos los días.

La pregunta que decide el enfoque no es cuán radical debe ser el cambio, sino qué sistemas no se pueden tocar y cómo se diseña el nuevo proceso alrededor de ellos. Un rediseño total, desde cero, tiene sentido cuando la empresa puede reemplazar su tecnología de base sin poner en riesgo la operación. Cuando eso no es posible, el rediseño radical se aplica primero sobre el proceso (quién decide, en qué orden, con qué reglas, con qué excepciones) y después se integra con los sistemas existentes en lugar de sustituirlos.

Ese es el principio detrás de la metodología de 5 pasos de Bprosys: relevar el proceso real, diseñar el nuevo proceso antes de tocar tecnología, construir e integrar la automatización con los sistemas existentes, desplegar con pruebas y gobernanza, y escalar el rediseño a otros procesos. El orden importa: primero el proceso, después la herramienta.

Un ejemplo aplicado: rediseñar la aprobación de crédito sin reemplazar el core bancario

Considere un banco que aprueba créditos con un proceso repartido entre tres áreas, con pasos que se hacen por correo y un core bancario que no está en discusión reemplazar. Reemplazar el core completo tomaría años y pondría en riesgo la operación diaria; no automatizar el proceso tal como está solo haría más rápido un rediseño defectuoso.

La reingeniería en ese escenario relevó primero cómo funcionaba el proceso en la práctica, no como figuraba en el manual: quién aprobaba cada monto, qué excepciones existían y dónde se perdía tiempo esperando una firma. Con ese mapa, el equipo rediseñó el proceso desde cero (nuevos umbrales de aprobación, un solo responsable por etapa, reglas explícitas para las excepciones) y recién después integró ese diseño con el core bancario existente, sin sustituirlo. El resultado es un proceso nuevo que corre sobre la misma base tecnológica que la empresa ya tiene y en la que confía.

Por qué mapear el proceso real, no el del manual, es el paso previo indispensable

Ningún rediseño parte de cero en la práctica, aunque el objetivo sea radical: parte de entender cómo funciona el proceso hoy, con sus excepciones y sus atajos, no de lo que dice un documento desactualizado. La guía sobre cómo mapear su proceso antes de escalar el equipo desarrolla ese paso: el proceso que hoy funciona con un equipo chico rara vez está escrito en ningún lado, porque circula en la memoria de dos o tres personas.

Antes de rediseñar conviene responder el checklist de 6 preguntas para saber si su proceso está documentado: si alguien nuevo podría ejecutar el proceso solo con el documento, si incluye las excepciones y no solo el camino esperado, y si especifica qué sistemas intervienen en cada paso. Rediseñar sobre un mapa incompleto arrastra las mismas inconsistencias que tenía el proceso manual, como muestra la guía sobre procesos que su equipo rehace desde cero, y sostener ese proceso sin rediseñarlo tiene un costo que rara vez aparece en una factura, como detalla la nota sobre el costo invisible del proceso manual.