Reingeniería de procesos de negocio: qué es, cómo funciona y por qué fracasa la mayoría de los programas

Puntos clave

‍

• La reingeniería de procesos empresariales rediseña un proceso desde cero, buscando un cambio radical en el rendimiento en lugar de mejoras incrementales, y es adecuada solo para una minoría de casos.

• Se diferencia de la mejora de procesos, que perfecciona un proceso existente mediante pasos pequeños y continuos, lo que conlleva un riesgo mucho menor.

• Un programa se desarrolla en cinco etapas: definir el alcance y los resultados, establecer el estado actual, diseñar el reemplazo, realizar una prueba piloto y, finalmente, implementar y medir los resultados frente a la base de referencia.

• La mayoría de los programas apresuran la segunda etapa y diseñan basándose en el proceso que la gente describe en los talleres en lugar del que realmente ejecutan, con sus excepciones y todo.

‍

‍

¿Qué es la reingeniería de procesos de negocio?

‍

La reingeniería de procesos de negocio, a menudo abreviada como BPR, es el rediseño fundamental de un proceso empresarial desde cero, con el objetivo de lograr una mejora drástica en el rendimiento en lugar de una incremental. Sustituye el proceso actual por completo, construyendo uno nuevo en torno a los resultados que la empresa necesita y dejando atrás los pasos antiguos.

‍

Lo que la diferencia de la optimización de un proceso es el punto de partida. La optimización toma el proceso existente y mejora pasos específicos. La reingeniería deja el proceso a un lado y se pregunta cómo sería la versión ideal si no hubiera que conservar nada del actual.

‍

El detonante suele ser una brecha que los cambios incrementales no pueden cerrar de forma creíble: un proceso diseñado para una escala o mercado que la organización ya ha superado, o un resultado que la empresa necesita ahora y que los pasos actuales nunca fueron diseñados para producir, por mucho que se refinen.

‍

Tres cosas suelen confundirse con ella:
‍

Automatizar un proceso deficiente, haciendo que los mismos pasos erróneos se ejecuten más rápido. La automatización por sí sola no es reingeniería.
‍

Una implementación de sistema que envuelve un proceso sin cambios con nuevo software, reproduciendo dicho proceso en una interfaz nueva.
‍

La "reingeniería" como recorte de costes bajo otro nombre, ya que su objetivo son los pasos, las transferencias y el retrabajo que ya no cumplen ninguna función, mientras que las personas que realizan el trabajo siguen siendo parte del proceso rediseñado.

‍

De dónde surgió la idea

‍

La idea surgió del artículo de Michael Hammer de 1990 en la Harvard Business Review, "Reengineering Work: Don’t Automate, Obliterate".

‍

Sostuvo que las empresas utilizaban la nueva tecnología para acelerar procesos que ni siquiera deberían haber existido, y que automatizar un proceso deficiente solo sirve para que se ejecute más rápido. Eso se convirtió en la base de la reingeniería de procesos como disciplina.

‍

Entre los principios que estableció se encontraban organizar el trabajo en torno a resultados en lugar de tareas, y capturar la información una sola vez, en el momento en que se genera.

‍

Hammer y James Champy ampliaron este argumento en su libro de 1993, Reingeniería de la empresa.

‍

Su tesis era que algunos procesos necesitaban ser reconstruidos desde cero, porque ajustarlos paso a paso nunca los convertiría en algo para lo que no fueron diseñados. La idea se extendió rápidamente durante esa década, al igual que su reputación de ser utilizada como excusa para realizar recortes, lo cual explica en parte por qué el término aún conserva esa asociación. El método en sí siempre se centró en la estructura del trabajo.

‍

La cuestión no ha perdido vigencia. Vuelve a surgir cada vez que aparece una nueva tecnología, porque la elección es la misma que describió Hammer: automatizar el proceso que ya tienes o rediseñarlo primero y automatizar solo lo que vale la pena conservar. Es la misma pregunta que las organizaciones se plantean ahora respecto a la IA.

‍

Reingeniería frente a mejora de procesos frente a optimización

‍

La reingeniería, la mejora de procesos y la optimización de procesos se sitúan en diferentes puntos de un mismo espectro, que va desde el reemplazo total de un proceso hasta el ajuste de un resultado específico dentro del mismo.

‍

‍

Elegir entre ellas depende de la magnitud de la brecha entre dónde se encuentra el proceso y dónde debería estar. Si una serie de pequeñas mejoras pudiera cerrar esa brecha de manera plausible, la reingeniería es la herramienta equivocada, ya que resulta costosa y disruptiva en comparación con lo que tales mejoras lograrían. Solo justifica su costo cuando la brecha es demasiado grande para cerrarla mediante ajustes.

‍

Una prueba práctica consiste en anotar el objetivo y luego enumerar las mejoras que podrían alcanzarlo de forma plausible. Si esa lista se queda corta respecto al objetivo, la brecha es estructural y vale la pena considerar seriamente un rediseño.

‍

Lean, Six Sigma y Kaizen se sitúan en el lado incremental de esa línea, perfeccionando un proceso mediante pasos pequeños y continuos. La reingeniería se ubica en el lado opuesto, el de empezar desde cero.

‍

La gestión de procesos de negocio se encuentra en otro eje: es la disciplina continua de ejecutar y gobernar procesos, mientras que la reingeniería es un rediseño puntual. Por último, optimizar un proceso existente es la acción más limitada de todas, enfocada en una sola métrica dentro de un único proceso.

‍

Las etapas de un programa de reingeniería

‍

Un programa de reingeniería se desarrolla en cinco etapas, y cada una genera resultados de los que depende la siguiente. Estos pasos de reingeniería de procesos de negocio son válidos para cualquier proceso.

‍

1. Definir el alcance y el resultado que debe ofrecer el rediseño
2. Establecer cómo funciona realmente el proceso actual
3. Diseñar el reemplazo
4. Realizar una prueba piloto en una parte limitada del trabajo
5. Implementar y medir los resultados frente a la línea base original

‍

A continuación, detallamos estas etapas:

‍

1. Definir el alcance y el resultado. Antes de rediseñar nada, establezca límites claros sobre lo que incluye el alcance y defina un resultado específico que el nuevo proceso debe entregar. Términos como "más rápido" o "mejor" no sirven, ya que nadie podrá determinar después si se han alcanzado. Un alcance demasiado amplio convierte el rediseño en un proyecto interminable sin una meta clara.

‍

2. Determine cómo funciona realmente el proceso actual. Aquí es donde la mayoría de los programas avanzan más rápido y donde deberían avanzar más despacio. Es tentador tratarlo como un mero trámite, una ronda de entrevistas y un mapa de procesos antes de empezar el verdadero trabajo de diseño. El mapa es un insumo útil, pero las excepciones, las soluciones improvisadas y los ciclos de retrabajo que consumen tiempo solo aparecen cuando se mide cómo se ejecutó el proceso, y la línea base capturada aquí es de la que depende toda comparación posterior.

‍

3. Diseñe el reemplazo. Con el estado actual medido en mano, diseñe el nuevo proceso abordando las brechas y puntos de falla reales. La prueba consiste en verificar si el diseño cierra la brecha definida en la primera etapa. Que se vea más limpio sobre el papel que el proceso anterior es una prueba mucho más débil, y muchos diseños la superan para luego fracasar en la práctica.

‍

4. Realice una prueba piloto en una parte limitada del trabajo. Ejecute el nuevo diseño en un ámbito limitado, como un equipo, una región o una línea de productos, antes de implementarlo por completo. Omitir la prueba piloto es lo que convierte un defecto de diseño en uno que afecta a toda la organización, ya que un problema que habría surgido en un solo equipo termina apareciendo en todos a la vez.

‍

5. Implemente y compare con la línea base original. Una vez que la prueba piloto sea exitosa, implemente el rediseño y compárelo con la línea base de la segunda etapa, medida de la misma manera durante un período comparable. Sin esa comparación, un programa costoso termina basándose en opiniones sobre si funcionó o no, sin que nadie pueda señalar un resultado concreto.

‍

Cómo se ve la reingeniería en la práctica

‍

Estos ejemplos de reingeniería de procesos de negocio se describen por función, porque la naturaleza del problema importa más que la organización en la que ocurrió. En cada caso, el rediseño elimina las transferencias, las esperas y el retrabajo del proceso.

‍

• Gestión de reclamaciones. Forma antigua: un caso pasa por recepción, triaje, investigación y aprobación, cada una con su propio equipo, cola y transferencia antes de llegar a una decisión. Rediseño: el proceso se reconstruye en torno al caso, de modo que se mueve a través de menos colas con menos esperas entre ellas. Haberlo hecho pasar por las mismas colas un poco más rápido habría dejado la estructura intacta.

• Incorporación de clientes. Modelo anterior: las verificaciones de identidad, crédito y cumplimiento se ejecutan de forma secuencial, esperando una a la otra, incluso cuando no dependen entre sí. Rediseño: las verificaciones independientes se ejecutan en paralelo, reduciendo el tiempo de decisión sin alterar lo que se verifica.

• De la adquisición al pago. Modelo anterior: una solicitud de compra rebota varias veces entre el equipo de finanzas y el equipo solicitante antes de ser aprobada; cada trayecto añade retrasos y aumenta la posibilidad de que la solicitud quede estancada. Rediseño: la aprobación se clasifica según el importe y el riesgo, lo que elimina el ir y venir en solicitudes de bajo riesgo y mantiene una revisión completa donde es necesario.

• Triaje del servicio de asistencia. Modelo anterior: las solicitudes se enrutan manualmente, a menudo llegando primero al equipo equivocado, y rebotan de un lado a otro antes de llegar al lugar correcto. Rediseño: la recepción captura desde el principio la información necesaria para tomar la decisión de enrutamiento, lo que elimina el retrabajo de pasar solicitudes entre equipos.

‍

Ninguno de estos rediseños funciona eliminando personal. Cada uno elimina una causa estructural de retraso: una dependencia secuencial innecesaria, un bucle de aprobación, una cola de espera o una decisión de enrutamiento tomada con información insuficiente.

‍

Cada rediseño cambió lo que se ejecuta en secuencia, dónde se toman las decisiones o cuándo se captura la información. Simplemente acelerar los pasos existentes habría dejado todo eso intacto.

‍

Por qué fracasan los programas de reingeniería

‍

Los programas de reingeniería suelen fracasar por cuatro razones específicas y evitables. La cifra de fracaso más conocida proviene de los propios Hammer y Champy, cuyo libro de 1993 describió como una estimación poco científica que entre el 50 y el 70 por ciento de las organizaciones que intentaban la reingeniería no lograban los resultados drásticos que buscaban.

‍

Más tarde, en 1995, Hammer enfatizó que esto era una descripción de lo que habían observado y que la reingeniería no tiene una tasa de éxito o fracaso inherente. Las razones detrás de esto son más útiles que el número en sí.

‍‍

1. El estado actual se describió, no se midió. Los talleres y las entrevistas producen el proceso que la gente cree que sigue, filtrado por la memoria y cierto optimismo sobre la consistencia con la que se cumple. El proceso real ha desarrollado excepciones, soluciones alternativas y bucles de retrabajo que nadie registra, por lo que el rediseño se construye sobre un punto de partida equivocado, y el coste real de los flujos de trabajo que nadie ha mapeado sale a la luz una vez que el nuevo proceso está en marcha.

‍

2. La ruta de excepción se diseñó sobre el papel, no en la práctica. Los rediseños se construyen en torno al caso ideal, la versión del proceso que funciona según lo previsto. En la mayoría de las operaciones, es en las excepciones donde realmente se pierde el tiempo, por lo que un proceso nuevo que no las tuvo en cuenta se topa con ellas el primer día sin ninguna respuesta.

‍‍

3. No existe una medición previa comparable. Sin una línea base capturada de la misma forma que la medición posterior, durante el mismo tipo de periodo y con el mismo nivel de detalle, el resultado puede afirmarse, pero no demostrarse. Así es como los programas costosos terminan sin un veredicto.

‍

4. El alcance abarcó toda la organización a la vez. Reingenierizar todo simultáneamente elimina cualquier posibilidad de aislar lo que funcionó y cualquier forma de detenerse cuando algo sale mal. Un programa que cambia un proceso a la vez puede hacer una pausa, aprender y aplicar la lección al siguiente. Un proceso único con un límite claro y un objetivo medible tarda más en empezar, pero es mucho más rápido de validar.

‍

No puedes rediseñar para salir de un proceso que nunca mediste. El reemplazo arrastrará las mismas excepciones, porque nadie sabía que estaban ahí.

‍

Establecer el estado actual del que te estás alejando al rediseñar

‍

Todos los fallos anteriores tienen un origen común: la falta de un estado actual que se pueda justificar. Para lograrlo, se necesitan cuatro elementos.

‍

• Refleja el camino que sigue el trabajo en la realidad. Esto incluye tanto las excepciones y el retrabajo como el flujo previsto. Un estado actual que solo muestra el caso ideal describe el proceso tal y como se diseñó, no como funciona.

• Se registra de la misma manera antes y después. Si el "antes" proviene de un taller y el "después" de un informe del sistema, cualquier diferencia podría deberse tanto a un cambio en el método de medición como a una mejora real en el proceso.

• Abarca un periodo de tiempo suficiente. El periodo debe incluir las variaciones normales, ya que una semana excepcionalmente fluida puede hacer que el proceso parezca mejor de lo que realmente es.

• Se basa en mediciones, no en autoinformes. Los autoinformes suelen describir el proceso tal y como se pretende que sea, por razones que no tienen nada que ver con la falta de honestidad.

‍

Los equipos suelen intentar lograrlo de dos formas, y ambas fallan a su manera. Los talleres capturan la intención, es decir, lo que la gente cree que es el proceso. Los registros del sistema solo capturan el trabajo que ocurre dentro de las plataformas y pasan por alto lo que sucede en un correo electrónico, una hoja de cálculo o una llamada telefónica entre dos pasos que no genera ningún registro.

‍

Reconstruir cómo se ejecutó realmente un proceso implica ver tanto lo que ocurrió dentro de los sistemas como lo que sucedió a su alrededor. Cualquier otra cosa hará que el rediseño trabaje con una visión incompleta. En la práctica, esto suele significar combinar fuentes: el registro del sistema donde existe y una medición del trabajo realizado fuera de él donde no existe.

‍

De dónde proviene la evidencia

‍

Todo lo anterior depende de un estado actual medido y de volver a medirlo de la misma manera después del rediseño.

‍

Insightful es una plataforma de datos de trabajo. Su Optimización del flujo de trabajo producto mapea un proceso de principio a fin y muestra la duración de cada etapa, el movimiento entre pasos y el trabajo repetido. Esto proporciona al rediseño un estado actual basado en cómo se ejecutó realmente el trabajo, y una medición comparable posterior para mostrar qué cambió con el rediseño.

‍

Insightful no es un servicio de rediseño ni de consultoría. No diseña procesos, no ejecuta programas de transformación ni implementa sistemas, y no participa en la decisión de cómo debería ser el nuevo proceso. Proporciona la evidencia de cómo funciona el proceso actual al principio, y el mismo tipo de evidencia después. Es un control fiable para sus esfuerzos de reingeniería.

‍

Debido a que se aplica la misma medición en ambas ocasiones, durante un período lo suficientemente largo como para incluir la variación normal, el antes y el después pueden compararse directamente. El rediseño en sí permanece en manos del equipo que lo lleva a cabo.

‍

Esto es lo más importante en dos puntos del programa anterior:

‍

En la segunda etapa, estableciendo cómo funciona realmente el proceso actual, incluyendo las rutas de excepción y los bucles de retrabajo que un taller suele pasar por alto.

‍

En la quinta etapa, midiendo el despliegue frente a esa misma línea base. El piloto también se beneficia, porque la misma medición muestra si el grupo piloto se comporta como se esperaba en el diseño antes de que se extienda a mayor escala.

‍

Conozca el proceso antes de reemplazarlo

‍

Un rediseño es tan bueno como la imagen del proceso actual sobre el que se basa. Si esa imagen se obtiene en un taller, el rediseño heredará todas las excepciones y soluciones improvisadas que nadie mencionó. Si se obtiene a partir de mediciones, el rediseño se construye sobre lo que realmente sucede.

‍

Las cinco etapas, la elección entre reingeniería y mejora, y los cuatro modos de fallo dependen de ese único factor. La imagen actual se mide o se asume, y el resultado del programa dependerá de esta elección. Por eso, la segunda etapa es el punto más económico para proteger todo el esfuerzo, ya que el tiempo dedicado a medir el proceso actual es mínimo comparado con el coste de rediseñar sobre una base equivocada.

‍

Workflow Optimization se encuentra actualmente en fase beta. Solicitar acceso a la beta para ver cómo funcionan realmente sus procesos antes de rediseñarlos.

‍

Preguntas frecuentes

‍

¿Qué es la reingeniería de procesos de negocio?

La reingeniería de procesos de negocio es el rediseño fundamental de un proceso desde cero, con el objetivo de lograr una mejora drástica en lugar de una incremental. Ajustar un proceso mejora pasos específicos dentro del mismo. La reingeniería deja de lado el proceso completo y diseña un reemplazo basado en los resultados que el negocio necesita.

‍

¿Cuáles son los pasos de la reingeniería de procesos de negocio?

Un programa de reingeniería consta de cinco etapas: definir el alcance y el resultado que debe ofrecer el rediseño, establecer cómo funciona realmente el proceso actual, diseñar el reemplazo, realizar una prueba piloto en una parte limitada del trabajo e implementar el cambio midiendo los resultados frente a la línea base original.

‍

¿Cuál es la diferencia entre la reingeniería de procesos de negocio y la mejora de procesos?

La reingeniería de procesos de negocio sustituye un proceso por un diseño nuevo creado desde cero. La mejora de procesos perfecciona el proceso existente mediante pasos pequeños y continuos. Utilice la reingeniería cuando los cambios incrementales no sean suficientes para cerrar la brecha entre el rendimiento actual y el necesario, y opte por la mejora de procesos cuando sí lo sean, ya que conlleva mucho menos coste y riesgo.

‍

¿Cuál es un ejemplo de reingeniería de procesos de negocio?

Un ejemplo común es la incorporación de clientes, donde las verificaciones de identidad, crédito y cumplimiento tradicionalmente se ejecutan de forma secuencial, esperando cada una a que termine la anterior. Una versión reingenierizada ejecuta las verificaciones independientes en paralelo, lo que reduce el tiempo de toma de decisiones sin cambiar lo que se verifica ni eliminar a nadie del proceso.

‍

¿Por qué fracasan los proyectos de reingeniería de procesos de negocio?

La mayoría fracasa porque el estado actual solo se describió, pero nunca se midió. Los talleres producen el proceso que la gente cree que sigue, sin las excepciones ni los ciclos de retrabajo que consumen el tiempo real. El rediseño se construye sobre esa imagen incompleta, por lo que el nuevo proceso se topa con las mismas excepciones y las arrastra consigo.

‍

¿Cuándo debería una empresa reingenierizar un proceso en lugar de mejorarlo?

Opte por la reingeniería cuando la brecha entre el rendimiento actual y el requerido sea demasiado grande para cerrarla mediante una serie de mejoras. Si cambios menores pudieran lograr el objetivo de manera plausible, la mejora es la mejor opción, ya que la reingeniería es más lenta, costosa y conlleva un mayor riesgo. El tamaño de la brecha es el factor decisivo.

‍