Reingeniería de procesos de negocio (BPR): pasos y ejemplos

La reingeniería de procesos de negocio es lo que se hace cuando ajustar un sistema roto ya no es suficiente. En lugar de solucionar problemas uno por uno, BPR (business process reengineering) plantea una pregunta más difícil: si empezáramos hoy desde cero, ¿cómo diseñaríamos este proceso?

Esa pregunta suena simple. Pero actuar sobre la respuesta requiere verdadero valor, porque la respuesta casi siempre significa desechar gran parte de lo que ya existe.

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

La reingeniería de procesos de negocio es el rediseño fundamental y radical de los procesos centrales de negocio para lograr mejoras drásticas en medidas críticas de desempeño como costo, calidad, velocidad y servicio. La definición proviene de Michael Hammer y James Champy, quienes introdujeron el concepto en su libro de 1993 Reengineering the Corporation.

Cuatro palabras en esa definición cargan con todo el peso:

• Fundamental significa cuestionar por qué se hacen las cosas, no solo cómo se hacen.
• Radical significa llegar a la raíz de los procesos, no hacer ajustes superficiales.
• Drástico significa apuntar a ganancias de un orden de magnitud, no mejoras del 10%.
• Procesos significa enfocarse en el flujo de trabajo de principio a fin, no en tareas individuales o departamentos.

BPR no se trata de mejorar lo que existe. Se trata de reemplazarlo.

Datos clave

• Una revisión de 2019 de la literatura sobre BPR (Al-Mashari y Zairi, Business Process Management Journal) encontró que entre el 50 y el 70 por ciento de las grandes iniciativas de BPR no logran alcanzar sus objetivos declarados, la mayoría de las veces debido a una mala gestión del cambio y falta de patrocinio ejecutivo.
• La emblemática reingeniería de Ford Motor Company de su función de cuentas por pagar a principios de la década de 1990 redujo la plantilla de ese departamento en un 75 por ciento, pasando de 500 empleados a alrededor de 125, al eliminar por completo la factura y pasar a un pago basado en recepción.
• Hammer y Champy estimaron que solo entre el 10 y el 50 por ciento de las empresas que intentaban BPR en esa época lograban alcanzar las mejoras drásticas que buscaban, subrayando que el rediseño en sí es la parte fácil.

BPR frente a mejora continua (kaizen) frente a BPM

Las personas a menudo agrupan tres enfoques distintos para cambiar la forma en que se realiza el trabajo. No son lo mismo, y confundirlos lleva a elegir la herramienta equivocada.

Si su proceso necesita cirugía mayor, BPR es la opción correcta. Si necesita fisioterapia, use kaizen. Si necesita un sistema de gestión para gobernar todo, eso es gestión de procesos de negocio.

Los principios de la reingeniería

Hammer y Champy establecieron varios principios rectores en Reengineering the Corporation. En términos sencillos, esto es lo que significa cada uno en la práctica:

Organizar en torno a resultados, no a tareas. Diseñe el proceso para producir el resultado, no para mantener ocupados a roles individuales. Un solo equipo debe ser dueño de todo el resultado, no traspasar el trabajo entre cinco departamentos.

Que quienes usan el resultado realicen el proceso. Si el equipo de compras necesita datos financieros, déjelo acceder directamente en lugar de solicitar un informe a finanzas. Elimine a los intermediarios.

Tratar los recursos dispersos geográficamente como centralizados. La tecnología de la información permite combinar los beneficios de escala de las operaciones centralizadas con la flexibilidad de los equipos locales. No necesita un departamento separado en cada oficina.

Vincular actividades paralelas en lugar de integrar sus resultados. En vez de ejecutar dos flujos de trabajo separados y conciliar sus resultados al final, coordínelos durante todo el proceso. Esto reduce el tiempo de ciclo y disminuye el retrabajo.

Ubicar el punto de decisión donde se realiza el trabajo. Otorgue a los trabajadores de primera línea la autoridad y la información para tomar decisiones en el momento. No escale cada excepción por la cadena de mando.

Capturar la información una sola vez y en la fuente. Si un cliente ingresa sus datos, no le pida a otro departamento que vuelva a ingresar los mismos datos. Las bases de datos compartidas y el acceso directo eliminan los errores de reingreso.

Beneficios de BPR

Cuando BPR funciona, los resultados son difíciles de discutir:

Reducción drástica de costos. Eliminar pasos redundantes, traspasos y retrabajo puede reducir los costos operativos más rápido que cualquier programa de eficiencia. El rediseño de cuentas por pagar de Ford es el caso de manual, pero resultados similares aparecen en logística, servicio al cliente y cumplimiento de pedidos.

Tiempos de ciclo más rápidos. Los procesos construidos en torno a resultados en lugar de la estructura departamental tienden a completarse mucho más rápido. Menos esperas, menos aprobaciones y menos pasos de conciliación se suman.

Mejor experiencia del cliente. Cuando un solo responsable es dueño de un resultado de principio a fin, el cliente trata con un único punto de contacto en lugar de ser transferido de un lado a otro. Los tiempos de respuesta bajan y los errores disminuyen.

Posicionamiento competitivo. Algunas industrias tienen jugadores que ya han rediseñado sus procesos en torno a la TI. Las empresas que no lo han hecho compiten en un terreno desigual. BPR puede cerrar esa brecha en un solo movimiento en lugar de a través de años de esfuerzo incremental.

Claridad organizacional. El proceso de rediseño obliga a los equipos a enfrentar la lógica real de cómo fluye el trabajo. A menudo, reglas y traspasos de larga data resultan no tener ninguna base racional. Eliminarlos simplifica las líneas de reporte, reduce la política interna y hace más clara la rendición de cuentas.

Riesgos y por qué fracasan los esfuerzos de BPR

BPR conlleva una tasa de fracaso que nadie debería ignorar. El propio Hammer lo reconoció. Esto es lo que realmente impulsa los fracasos:

La alta dirección no se mantiene comprometida. BPR necesita campeones ejecutivos que absorban la resistencia política de la gerencia media, cuyos puestos y bases de poder a menudo se ven amenazados por el rediseño. Cuando el liderazgo delega el proyecto y sigue adelante, gana la resistencia.

El alcance se expande o se reduce. Comenzar demasiado pequeño mantiene la iniciativa dentro de un solo departamento y produce ganancias marginales. Comenzar demasiado grande sin suficientes recursos o un objetivo piloto claro no produce nada. Definir bien el alcance es genuinamente difícil.

Se trata a la TI como el objetivo, no como el facilitador. Instalar software nuevo no es BPR. Muchas organizaciones llaman "reingeniería" a una implementación de ERP porque es costosa y disruptiva. Pero si solo automatiza el proceso antiguo, obtiene una versión más rápida del mismo sistema roto.

Se olvida a las personas. Cada proceso es ejecutado por personas. Rediseñar el flujo sin planificar la capacitación, los cambios de rol y la realidad emocional del desplazamiento laboral crea resistencia activa.

No hay medición previa. Si no conoce sus métricas de referencia (tiempo de ciclo, tasa de error, costo por transacción), no puede saber si el rediseño funcionó. Muchos proyectos de BPR reportan "éxito" porque no se midió nada de antemano.

Se omite la fase piloto. Implementar un proceso rediseñado en toda la organización sin un piloto controlado es una receta para el fracaso en cascada. Los pilotos exponen suposiciones que parecían correctas en una pizarra.

Cómo reingenierar un proceso

Paso 1: Identificar el proceso a rediseñar

No todo proceso merece un esfuerzo de BPR. Comience seleccionando un proceso que sea estratégicamente crítico y que esté claramente roto. Los buenos candidatos tienen alto costo, tiempos de ciclo largos, quejas frecuentes de clientes, o están directamente vinculados a una desventaja competitiva. Evite abordar demasiados procesos a la vez.

Paso 2: Formar el equipo de reingeniería

Un equipo de BPR necesita una mezcla multifuncional: personas que realmente ejecutan el proceso (saben dónde falla), representantes de TI (saben qué pueden hacer los sistemas) y al menos un líder senior con suficiente autoridad para tomar decisiones reales. Esto no es un comité. Es un grupo de trabajo con un mandato para actuar.

Paso 3: Mapear el estado actual

Antes de poder rediseñar cualquier cosa, necesita comprender el flujo actual con honestidad y detalle. Use el mapeo de procesos de negocio o el mapeo de flujo de valor para documentar cada paso, traspaso, punto de decisión y demora. No omita este paso porque el proceso parezca obvio. El mapa del estado actual casi siempre revela sorpresas, incluidos pasos que existen sin ninguna razón actual.

Para una documentación estructurada del estado actual frente al futuro, un mapa de estado actual vs. futuro le da al equipo un anclaje visual compartido para la conversación de rediseño.

Paso 4: Establecer una visión audaz del estado futuro

Este es el paso de la hoja en blanco. Ignore las restricciones actuales y pregunte cómo se ve el resultado ideal. Defina el éxito en términos medibles: reducir el tiempo de ciclo en un 60%, reducir la tasa de error a menos del 1%, reducir la plantilla de esta función en un 40%. Un objetivo vago como "mejorar la eficiencia" no impulsará las decisiones difíciles que requerirá el rediseño.

Los diagramas de carriles (vea diagrama de carriles) son útiles aquí para mapear las responsabilidades entre los roles rediseñados antes de construir nada.

Paso 5: Rediseñar y pilotar

Construya el nuevo diseño de proceso y pruébelo en un entorno controlado antes del despliegue completo. El alcance del piloto debe ser lo suficientemente real como para sacar a la luz problemas genuinos, pero lo suficientemente contenido como para que los fallos puedan corregirse rápidamente. Documente lo que falla y ajuste el diseño.

El trabajo de estandarización de procesos también ocurre aquí: el proceso rediseñado debe documentarse en procedimientos operativos estándar para que pueda capacitarse y hacerse cumplir.

Paso 6: Implementar y medir

Implemente el proceso rediseñado por fases si el alcance es grande. Mida contra sus objetivos del Paso 4 desde el primer día. Reporte los resultados con transparencia. Asigne una responsabilidad clara para el desempeño continuo. Y planifique el lado humano: comuníquese temprano con los equipos afectados, brinde capacitación real y tenga un plan para los cambios de rol antes de la fecha de lanzamiento, no después.

Ejemplos de reingeniería de procesos de negocio

Los tres ejemplos comparten el mismo patrón: el rediseño no se trató de trabajar más duro o agregar personal. Se trató de repensar quién hace qué, en qué orden y qué información necesita para hacerlo.

Mejores prácticas

Hacer:

• Asegurar un patrocinador ejecutivo antes de comenzar, no después de haber encontrado resistencia.
• Medir rigurosamente el proceso de referencia antes de tocar nada.
• Usar un piloto para validar suposiciones antes del despliegue completo.
• Diseñar el nuevo proceso en torno al resultado del cliente, no a la lógica del organigrama interno.
• Planificar la transición de las personas (roles, capacitación, comunicación) con tanto cuidado como el diseño del proceso.
• Combinar BPR con automatización robótica de procesos o automatización de flujos de trabajo para consolidar las ganancias y reducir el reingreso manual.

No hacer:

• Llamar "BPR" a una implementación de ERP. Instalar software sobre un proceso roto le da un proceso roto costoso.
• Dejar que el alcance se expanda sin un aumento correspondiente de recursos y autoridad.
• Omitir el mapeo del estado actual porque "todos saben cómo funciona esto". No es así. No completamente.
• Intentar reingenierar todo a la vez. Elija un proceso crítico y demuestre el modelo.
• Tratar BPR como un proyecto único. El proceso rediseñado sigue necesitando gobernanza continua para mantenerse saludable a lo largo del tiempo.

Preguntas frecuentes

¿Qué es la reingeniería de procesos de negocio en términos simples? BPR es empezar desde cero para rediseñar cómo funciona un proceso central de negocio. En lugar de corregir problemas en el proceso actual, se pregunta cómo se vería el proceso si se construyera hoy sin restricciones heredadas. El objetivo es una mejora drástica, no ganancias incrementales.

¿En qué se diferencia BPR de la mejora de procesos? La mejora de procesos (incluyendo kaizen y métodos lean) trabaja dentro de la estructura del proceso existente y la va mejorando paso a paso. BPR desecha la estructura existente y construye una nueva. El alcance y el riesgo son fundamentalmente diferentes. BPR es apropiado cuando el proceso actual está estructuralmente roto; los métodos de mejora son apropiados cuando es básicamente sólido.

¿Quién introdujo BPR? Michael Hammer y James Champy popularizaron el concepto en su libro de 1993 Reengineering the Corporation. Hammer había publicado previamente el artículo fundacional "Reengineering Work: Don't Automate, Obliterate" en la Harvard Business Review en 1990.

¿Por qué fracasan tantos proyectos de BPR? La mayoría de los fracasos se remontan a una de tres causas: un liderazgo que pierde interés o voluntad política a mitad de camino, subestimar la gestión del cambio humano requerida, o tratar la implementación de TI como un sustituto de un verdadero rediseño de procesos.

¿Cuándo debería una empresa usar BPR frente a un evento kaizen? Use BPR cuando un proceso esté fundamentalmente roto, entregue resultados muy por debajo de los estándares de la industria, o bloquee un objetivo estratégico que la mejora incremental no pueda resolver en un plazo razonable. Use un evento kaizen cuando necesite una mejora enfocada y rápida en un problema específico dentro de un proceso que sea estructuralmente sólido.

---

BPR no es para toda situación. Pero cuando un proceso está fundamentalmente roto y los riesgos competitivos son altos, la mejora incremental es simplemente un fracaso lento. Las empresas que rediseñaron sus procesos en torno a resultados en lugar de organigramas en la década de 1990 construyeron ventajas que a sus competidores les tomó una década cerrar. La misma lógica se aplica hoy, particularmente a medida que la IA y la automatización elevan el techo de lo que un proceso rediseñado puede lograr.

Para los equipos que buscan sentar las bases, comience con una documentación honesta del proceso y un mapeo claro de dónde falla el flujo actual. Esa es la base sobre la que se construye todo esfuerzo exitoso de BPR.