Procesos que cruzan áreas y nadie gestiona de punta a punta: cómo estandarizar operaciones en una empresa grande

El obstáculo para estandarizar procesos en una organización grande casi nunca figura en los manuales: los procesos que más importan no pertenecen a ninguna área. En conversaciones con responsables de operaciones y de mejora continua de empresas industriales grandes, aparece una imagen que lo resume: «es una pelota que quedó picando en el medio y que no la agarra nadie».

Un caso típico es la especificación de un insumo crítico. Compras la redacta y negocia con el proveedor, planificación arma el programa con lo que llega y operaciones produce y absorbe los problemas: descartes, paradas, ajustes de máquina. Cada área cumple su parte y muestra indicadores razonables. Con los años, los equipos aprenden «a convivir con esto», y las acciones de los talleres de mejora se cumplen poco, porque nadie responde por el proceso completo.

Esta guía está pensada para directores y gerentes de operaciones, procesos o calidad de organizaciones con varias áreas, plantas o sucursales. Explica cómo detectar con datos del ERP qué procesos están rotos, a quién darle la responsabilidad de punta a punta, qué hacer cuando el modelo lo define la casa matriz y cómo armar un piloto que no termine en un cajón. Más adelante resolvemos ese mismo caso, y al final hay un indicador para empezar a medir esta semana.

Por qué los procesos transversales son los más difíciles de estandarizar

En organizaciones grandes, los procesos que generan valor para el cliente y mueven dinero son casi siempre transversales: cruzan áreas, sistemas y jefaturas distintas.

Un artículo de McKinsey Quarterly de 2016 describe el caso de una empresa con 60 unidades de negocio que revisó todos sus procesos. Solo alrededor del 10 % resultó realmente distintivo entre negocios; el resto podía compartirse, aunque cada unidad lo ejecutaba a su manera. La empresa tenía más de 80 formas distintas de definir y nombrar sus cadenas de valor, es decir, la secuencia de actividades con la que cada negocio lleva un producto hasta el cliente. Las redujo a 7 modelos comunes y pasó a trabajar con 340 procesos, descritos con un vocabulario común de 6.000 tareas. Solo admitió variantes donde las exigía un segmento de clientes o la regulación.

El caso muestra la proporción del problema: al estandarizar procesos, la mayor parte de lo que cada unidad considera «propio» no lo es. Pero también muestra que la diferencia legítima existe y hay que dejarla escrita.

Si su empresa es mediana, con una sola planta y un ERP propio, casi todo lo que sigue para estandarizar procesos aplica igual: la priorización, el dueño de proceso, la matriz de responsabilidades y los indicadores. Lo que cambia es la escala de la gobernanza. El comité de proceso puede ser la reunión de gerentes que ya existe, y la sección sobre casa matriz probablemente no le toque.

Qué es un proceso transversal y cómo saber si está roto

Un proceso transversal atraviesa dos o más áreas para producir un resultado. El ejemplo clásico es el de pedido a cobro (order-to-cash): empieza en comercial, pasa por producción, logística y facturación y termina en cobranzas. Ningún área lo contiene por completo, así que cada gerente cuida su tramo. Comercial mide el tiempo de respuesta a cotizaciones, producción mide el cumplimiento del programa y logística, las entregas a tiempo. Nadie mide cuánto tarda el conjunto.

En la encuesta de prioridades de APQC de 2025, definir y mapear procesos de punta a punta fue la prioridad principal de los profesionales de procesos, elegida por el 40 %.

Las señales de que un proceso transversal está roto

A estas se suman tres señales que atraviesan cualquier proceso. La primera es un dato que se carga a mano en varios sistemas porque cada área confía en su planilla. La segunda son las reuniones y los mails para resolver excepciones que el proceso debería resolver solo. La tercera es la más peligrosa: descartes, paradas o reclamos que todos conocen y nadie registra, porque se asumen como parte normal del trabajo.

Cómo medir esas señales con datos del ERP

Antes de estandarizar procesos conviene medir estas señales, porque solo se pueden discutir en serio cuando tienen un número. Casi todo lo necesario ya está en el ERP. Cuatro indicadores alcanzan para empezar:

• Lead time pedido-entrega. Fecha de entrega efectiva (remito conformado o confirmación de recepción) menos fecha de alta del pedido, en días. Conviene mirar la mediana y el percentil 90 por planta o sucursal, no solo el promedio: el percentil 90 muestra los pedidos que generan reclamos.
• OTIF (on time, in full). Pedidos entregados completos y en la fecha comprometida, dividido por el total de pedidos entregados en el período. La fecha comprometida tiene que ser la que se le dio al cliente, no la que se reprogramó después.
• Porcentaje de casos en flujo estándar. Casos que recorren la secuencia definida sin modificaciones manuales, bloqueos liberados a mano ni pasos fuera del sistema, dividido por el total de casos. Se obtiene del registro de cambios de estado del pedido o de la orden de compra.
• Costo de reproceso. Horas de retrabajo por el costo horario de la línea, más material descartado valorizado, más fletes y horas extra por urgencias. Las fuentes son las órdenes de retrabajo, los movimientos de scrap, las notas de crédito por reclamos y los fletes marcados como urgentes.

Si dos plantas no pueden medirse con la misma fórmula, eso ya es un hallazgo: el proceso todavía no está estandarizado ni siquiera en sus datos.

Por qué las estructuras jerárquicas complican la gestión transversal

Las organizaciones grandes están diseñadas para gestionar funciones, no procesos: cada área tiene gerente, presupuesto y objetivos propios, y un pedido que cruza de comercial a producción y a logística no le pertenece a ninguna. En el mismo artículo, McKinsey señala que incluso multinacionales bien establecidas fallan rutinariamente en gestionar sus operaciones de punta a punta. Y la encuesta de PwC sobre tendencias digitales en operaciones, hecha a principios de 2026 a 767 líderes de operaciones de empresas de Estados Unidos con ingresos anuales de 100 millones de dólares o más, encontró que el 94 % considera probable migrar a una estructura más horizontal, pero solo el 41 % funciona así hoy.

La brecha persiste porque cambiar la estructura organizacional es una decisión disruptiva, con costos políticos y operativos. Estandarizar procesos permite avanzar sin tocar el organigrama: se define cómo funciona el proceso que cruza áreas, quién responde por el resultado completo y qué reglas aplican en cada traspaso.

Estandarizar procesos: qué significa realmente en una organización grande

Estandarizar procesos en una empresa grande es definir una única forma de ejecutar cada proceso transversal clave, aplicable a todas las plantas, sucursales o unidades, con reglas claras para las excepciones y un responsable del resultado de punta a punta. Implica acordar qué se hace igual en todas partes, qué puede variar y por qué.

Conviene distinguir tres niveles:

• Nivel 1: el flujo. La secuencia de pasos y los puntos de traspaso entre áreas: quién entrega qué a quién y en qué orden.
• Nivel 2: las reglas. Los criterios de decisión en cada punto: quién aprueba, con qué límites, qué excepciones se admiten y qué información hace falta para avanzar.
• Nivel 3: los datos y las especificaciones. Qué se registra, dónde, con qué formato y quién responde por su calidad, incluidas las especificaciones que se comparten con proveedores. Es el nivel que permite que la tecnología funcione.

Cómo identificar qué procesos estandarizar primero

No es viable estandarizar procesos transversales de todas las áreas al mismo tiempo. La priorización requiere evaluar cada uno en cuatro dimensiones.

• Impacto en el cliente o en los ingresos. Un proceso que afecta la experiencia del cliente o los tiempos de cobro va antes que uno puramente interno.
• Variabilidad entre unidades. Si el mismo proceso se ejecuta de tres formas en tres plantas, el beneficio es inmediato: indicadores comparables, menos errores y capacitación más simple.
• Costo de la ineficiencia actual. Horas de reproceso, descartes y errores, medidos con los indicadores de arriba y no supuestos. Una consultoría de procesos seria empieza por un diagnóstico que cuantifica el problema antes de proponer soluciones. En una organización grande, esa cifra es además lo que permite defender el proyecto ante el comité de dirección.
• Viabilidad de la implementación. Algunos procesos cruzan áreas dispuestas a colaborar; otros atraviesan feudos donde cualquier cambio es una batalla. Empezar por donde hay disposición genera precedentes para los casos difíciles.

Un proceso con alto impacto, alta variabilidad, costo medible y buena disposición es el candidato ideal para el primer piloto.

Tres modelos para asignar la gestión de procesos transversales

El mayor desafío no es mapear el proceso. Es decidir quién responde por el resultado completo cuando cruza áreas con gerentes diferentes. Hay tres modelos con distinto grado de formalidad.

Modelo 1: dueño de proceso (process owner)

Una persona responde por el proceso de punta a punta. No conduce a quienes lo ejecutan, que siguen reportando a sus gerentes funcionales, pero define las reglas, los estándares, los indicadores y las mejoras. Es una autoridad lateral. Su ventaja es que alguien ve lo que ningún gerente funcional ve por separado. Su riesgo es la autoridad nominal: sin respaldo de la dirección, los gerentes pueden ignorar sus recomendaciones sin consecuencias.

Modelo 2: comité de proceso

Un comité con representantes de cada área revisa los indicadores, decide mejoras y resuelve conflictos. Es el formato natural cuando el problema nace en la frontera entre operaciones, compras y planificación. Genera compromiso, porque todas las áreas están en la decisión. El riesgo es la lentitud: si se reúne una vez por mes y todo requiere consenso, las mejoras se demoran.

Modelo 3: centro de excelencia de procesos

Un equipo especializado mapea, estandariza y mejora los procesos clave. No reemplaza a los gerentes ni a los dueños de proceso: les da metodología, herramientas y datos. Profesionaliza la gestión, pero puede leerse como una capa burocrática más si no muestra resultados en los primeros meses.

Muchas organizaciones combinan los tres. Lo importante es que exista alguien con la responsabilidad explícita del proceso completo. Sin esa asignación, el diseño organizacional queda incompleto: se definen las funciones verticales, pero no la coordinación horizontal.

Filiales y casa matriz: estandarizar procesos cuando el modelo viene de afuera

En las filiales de grupos multinacionales, estandarizar procesos tiene otro sentido, porque el proceso muchas veces ya viene definido: un template global del ERP corporativo, políticas de aprobación escritas en la casa matriz y un dueño de proceso global (global process owner) que está en otro país. El problema local cambia de forma. Ya no se trata de inventar el estándar, sino de ejecutarlo bien y de defender las diferencias que son legítimas.

Qué es negociable y qué no

Conviene separar tres capas. La primera es lo que el grupo necesita igual en todas partes: la estructura de datos maestros, los controles financieros, los niveles de aprobación y los indicadores que consolida. Eso no se negocia; se ejecuta. La segunda es lo que exige el país: comprobantes electrónicos según las normas de ARCA, regímenes de retención y percepción de ingresos brutos que cambian por provincia, documentos de traslado, convenios colectivos. Eso no es una preferencia local; es una obligación y hay que documentarla como tal. La tercera es lo que la filial «prefiere» hacer distinto. Ahí está casi toda la variabilidad que no se justifica.

Cómo documentar y negociar una variante local

Una variante local se sostiene mejor con un registro simple que con una discusión. Para cada una conviene dejar escrito qué paso del estándar cambia, cuál es el motivo (legal, fiscal, gremial, de cliente o de infraestructura), cuánto cuesta mantenerla, quién la aprobó y cuándo se revisa.

Con ese registro, la negociación con la casa matriz cambia de tono. En lugar de «acá las cosas son distintas», la filial presenta una variante con su norma de respaldo, su volumen y su costo. Si otras filiales de la región tienen el mismo requisito, conviene presentarlo en conjunto, porque el dueño global prioriza lo que afecta a varios países. Y el mejor momento para negociar es la etapa de análisis de brechas de una implementación o actualización del ERP, no después de la salida en vivo.

Quién es el dueño cuando el dueño global está afuera

El dueño global responde por el diseño del proceso. Pero alguien tiene que responder por su desempeño en el país. La figura que suele funcionar es un dueño local del proceso: una persona de la filial que responde por el indicador de punta a punta local, administra el registro de variantes, es el interlocutor del dueño global y aprueba cualquier cambio local antes de que llegue al sistema. Sin esa figura, cada gerente local habla por su cuenta con la casa matriz y el proceso vuelve a fragmentarse, ahora en dos países.

Errores frecuentes al intentar estandarizar procesos entre áreas

Mapear sin implementar

Es el error más común. La organización dedica semanas a relevar y documentar, produce diagramas detallados y propone mejoras. Después el proyecto pierde impulso y cada área vuelve a trabajar como antes. Una variante habitual son los talleres de mejora que generan listas largas de acciones: sin responsables, fechas y una instancia que revise el avance, casi ninguna se cumple.

Imponer el estándar de una unidad sobre las demás

La tentación es tomar el proceso de la planta que mejor funciona y replicarlo. Suele generar resistencia, porque las otras unidades sienten que se ignora su experiencia. La alternativa es construir el estándar con los mejores elementos de cada una. Eso exige definir funciones y responsabilidades con claridad, para que cada área sepa qué se espera de ella dentro del proceso.

Estandarizar sin escuchar a quienes ejecutan

Los estándares diseñados lejos del trabajo fallan donde el trabajo ocurre. Quienes operan conocen las excepciones, los atajos y los problemas que nunca llegaron a un informe. Cuando operaciones, compras y planificación se sientan por primera vez a revisar un proceso juntas, es habitual que aparezcan problemas que ninguna había registrado.

Estandarizar sin gestionar el cambio

Estandarizar procesos implica que personas que hacían las cosas de una forma empiecen a hacerlas de otra. Las organizaciones que lo encaran sin un plan de gestión del cambio suelen ver resultados desiguales: algunas áreas adoptan el estándar, otras lo adaptan y otras lo ignoran. La variabilidad no desaparece; cambia de lugar.

Confundir estandarización con rigidez

Una planta química puede necesitar controles que una de ensamble no requiere, y un mercado regulado puede exigir más documentación. El estándar define el tronco común y las ramas permitidas. Lo que no debería permitir es que cada unidad invente su variante sin justificación escrita.

Estandarizar procesos antes de automatizar

La encuesta de PwC de 2026 dejó una tensión que cualquier director de operaciones reconoce. El 83 % de los encuestados cree que los agentes de IA y la automatización acelerarán la ruptura de los silos funcionales, pero solo el 37 % se siente cómodo asignándoles la ejecución de procesos completos de punta a punta. El 87 % dijo que la mala calidad de los datos frenó el valor de sus iniciativas digitales, y el 89 % que sus inversiones en tecnología no entregaron por completo los resultados esperados.

La encuesta no atribuye esa brecha a una causa única. El criterio que proponemos, y que no surge de la encuesta, es práctico: antes de aprobar una automatización, revisar si el proceso que se va a automatizar tiene un flujo, reglas y datos acordados entre las áreas. Si cada planta ejecuta su propia versión, la herramienta va a heredar esa variabilidad. El orden recomendable es estandarizar procesos, ordenar los datos y recién después automatizar.

Cómo empezar: una hoja de ruta para estandarizar procesos en una empresa grande

Paso 1: seleccionar uno o dos procesos prioritarios

Usar los cuatro criterios de priorización: impacto, variabilidad, costo medido y viabilidad. Querer estandarizar procesos en todas las áreas a la vez es la forma más segura de no terminar ninguno. Un proyecto acotado que termina genera confianza.

Paso 2: mapear el proceso real, no el teórico

Relevar cómo funciona hoy en cada unidad: quién hace qué, con qué información, en qué sistema, qué excepciones existen y dónde se traba. El relevamiento se hace con quienes ejecutan el proceso, no solo con sus gerentes, y se contrasta con los datos del ERP.

Paso 3: diseñar el proceso estándar

Definir la secuencia, los puntos de decisión, las reglas, las excepciones permitidas, los datos que se registran y los indicadores. El orden es relevar, simplificar y estandarizar; la automatización viene después.

Paso 4: definir la gobernanza del proceso

Elegir el modelo y definir qué autoridad tendrá, cómo se medirá y cómo se resolverán los conflictos. Si se elige un dueño de proceso, su autoridad es real solo si se cumplen cuatro condiciones:

• el indicador de punta a punta figura en sus objetivos y también en los de los gerentes funcionales que intervienen;
• ningún cambio en el proceso, en las especificaciones o en el sistema se aprueba sin su visto bueno;
• tiene un lugar fijo en el comité de operaciones para escalar conflictos;
• cuenta con un sponsor en el comité de dirección que respalda sus decisiones.

Paso 5: implementar por fases

Se prueba el estándar en una planta o sucursal, se ajusta lo que no funciona y después se extiende al resto, sin renegociar lo esencial del estándar.

• Cómo elegir la planta piloto. Ni la mejor ni la peor. Si el piloto sale bien en la planta modelo, el resto va a decir «allá se puede, acá no». Si se elige la que tiene más problemas, esos problemas van a tapar el efecto del estándar. Conviene una planta representativa en volumen y mezcla de productos, con un jefe dispuesto a sostener el cambio y datos del ERP confiables para medir antes y después. Y sin otro proyecto grande en curso ni un conflicto laboral abierto.
• Supervisores de turno y delegados gremiales. Los supervisores son los que sostienen el estándar a las tres de la mañana. Conviene que participen en el diseño, que capaciten a sus equipos y que lleven un registro simple de excepciones por turno. Cuando el estándar toca dotaciones, tareas, polivalencia o turnos, entra en terreno de convenio colectivo. Relaciones laborales tiene que estar desde el diseño, y conviene presentarle a la comisión interna el objetivo, el alcance y la duración del piloto antes de empezar. Ayuda separar lo que cambia en el método de lo que cambia en el encuadre de los puestos. Usar el piloto para modificar dotaciones de hecho es la forma más rápida de perderlo.

Paso 5 (continuación): evaluar el piloto antes de extenderlo

• Si el piloto sale mal. Primero hay que distinguir qué falló: el estándar, que no contempla una situación real; la implementación, con capacitación incompleta o un área que no adoptó el cambio; o la medición, porque el indicador estaba mal definido. Cada caso pide algo distinto: rediseñar, reforzar o corregir el dato. Lo que no conviene es extender igual para cumplir el cronograma ni abandonar el piloto sin decirlo. Si el problema es de adopción, se escala al sponsor; si es de diseño, se corrige y se corre un segundo ciclo con fecha de fin. Los criterios de éxito se escriben antes de empezar.
• Cuánto dura y cuánta dedicación pide. No conocemos estudios que den un número confiable. Como criterio de trabajo de BPS, no como dato de mercado, un rango razonable es de tres a seis semanas de relevamiento y diseño, y de ocho a doce semanas de operación con el estándar: hace falta ver al menos dos cierres mensuales y todos los turnos. El dueño de proceso suele necesitar entre un cuarto y la mitad de su tiempo durante el piloto, y los supervisores, unas horas por semana.

Paso 6: medir, ajustar y sostener

Después del piloto, el riesgo es que cada planta vuelva a ajustar el estándar a su gusto. Como criterio de BPS, conviene separar dos ritmos. El indicador de punta a punta se revisa todos los meses en el comité de operaciones, comparando unidades. El estándar en sí se revisa formalmente una o dos veces por año, o antes si aparece un disparador: un desvío que se sostiene dos meses, un producto nuevo, un cambio normativo o un cambio de sistema.

Quién puede cambiarlo también tiene que estar escrito. Cualquier planta puede proponer un cambio, con datos. Los ajustes menores, como un formulario o un campo del sistema, los aprueba el dueño de proceso. Los que modifican el flujo, las reglas de decisión o el trabajo de otra área pasan por el comité. Cada cambio queda registrado con fecha, motivo y versión, igual que las variantes locales.

Cómo presentarlo al comité de dirección

La propuesta compite por presupuesto con otros proyectos. Tiene más chances si llega con cinco elementos:

1. El costo actual de no tener estándar, medido con los indicadores del ERP.
2. Uno o dos procesos acotados, con alcance claro: qué áreas, qué plantas y qué queda afuera.
3. El modelo de gobernanza y el sponsor.
4. Un piloto con fecha de fin y criterios de éxito definidos antes de empezar.
5. El criterio para extender el estándar al resto de las unidades.

Conviene pedir aprobación para el piloto y no para el programa completo. Un comité aprueba con más facilidad un compromiso acotado y medible, y el piloto genera la evidencia para la decisión siguiente.

Cómo se resuelve el caso de la especificación de insumos

Volvamos a la situación del comienzo, como ejemplo ilustrativo de cómo se aplica lo anterior. El proceso a ordenar no es «compras» ni «producción»: es la especificación y el abastecimiento de un insumo crítico, desde que se define qué se necesita hasta que el insumo funciona en la línea.

Dueño de proceso y matriz de responsabilidades

Dueño de proceso. Se designa a una persona que ve las consecuencias en planta y tiene diálogo con compras; en muchas estructuras, el responsable de calidad de proveedores o de supply chain. Su visto bueno pasa a ser obligatorio para cualquier cambio de especificación o de proveedor.

Matriz de responsabilidades. Una matriz RACI indica, para cada actividad, quién la ejecuta (R), quién responde por el resultado (A), a quién se consulta (C) y a quién se informa (I). Un esquema posible:

Indicador de punta a punta y paso por el comité

• Indicador de punta a punta. Costo de falla por insumo crítico: material descartado atribuible al insumo, más horas de parada por el costo horario de la línea, más fletes o compras de urgencia, dividido por las toneladas producidas en el mes. Se arma con los movimientos de scrap, los partes de parada con código de causa y las órdenes de compra urgentes del ERP. Si los partes de parada no tienen código de causa por insumo, el primer paso es agregarlo.
• Paso por el comité. El dueño de proceso presenta el indicador una vez por mes en el comité de operaciones: evolución, tres causas principales y decisiones que necesitan a otra área. Las acciones de los talleres de mejora pasan a una sola lista con responsable y fecha, que se revisa en ese mismo comité. Lo que se traba dos meses seguidos se escala al sponsor. Así la pelota deja de picar en el medio: tiene un dueño, un número y un lugar donde se discute.

Preguntas frecuentes sobre cómo estandarizar procesos

¿Quién decide cuando el dueño global del proceso y la filial no están de acuerdo?

El dueño global decide sobre el diseño; la filial aporta la evidencia. Si la variante responde a una obligación legal, fiscal o de convenio, se documenta como tal y no debería discutirse. Si es una preferencia, se presenta con su costo y su volumen, y decide el dueño global o la instancia de gobierno del template.

¿Hay que negociar con el gremio antes de estandarizar procesos?

Depende de qué toque el estándar. Si cambia el método de trabajo sin modificar tareas, encuadres de convenio ni dotaciones, alcanza con informar y capacitar. Si toca alguna de esas cuestiones, relaciones laborales debe intervenir desde el diseño y conviene presentar el piloto a la comisión interna antes de empezar.

¿Conviene estandarizar antes o después de implementar un ERP nuevo?

Antes, al menos en los procesos críticos. Si se implementa el sistema sobre procesos distintos en cada planta, la configuración termina replicando esas diferencias o forzando un estándar que nadie acordó. Estandarizar procesos primero hace más corta la etapa de análisis de brechas.

¿Qué hacer si un área se niega a adoptar el estándar?

Primero, entender si la negativa tiene un motivo operativo que el diseño no contempló. Si lo tiene, se ajusta el estándar. Si no, es un tema de gobernanza: el indicador de punta a punta tiene que estar en los objetivos de ese gerente y el caso se escala al sponsor.

¿Cuánto dura un piloto para estandarizar procesos?

Como criterio de BPS, entre ocho y doce semanas de operación con el estándar, después de tres a seis semanas de relevamiento y diseño. Menos tiempo no suele alcanzar para ver dos cierres mensuales ni todos los turnos.

Qué medir esta semana: el primer indicador de punta a punta

Si hay que elegir un solo indicador para empezar, conviene el lead time pedido-entrega. Es la forma más barata de empezar a estandarizar procesos: se calcula sin proyecto, sin consultores y sin sistema nuevo.

Pida a sistemas una exportación de los pedidos entregados en el último trimestre, con cuatro columnas: planta o sucursal, fecha de alta del pedido, fecha comprometida al cliente y fecha de entrega efectiva. Calcule los días entre alta y entrega, y saque la mediana y el percentil 90 por unidad. Después compárelos con el plazo que comercial promete.

Cómo leer el resultado

Un ejemplo ilustrativo, con números inventados para mostrar la lectura: comercial promete 10 días. La planta A tiene una mediana de 9 días y un percentil 90 de 21; la planta B, una mediana de 12 y un percentil 90 de 35. A cumple en el pedido típico, pero uno de cada diez pedidos tarda más del doble de lo prometido. B incumple incluso en el pedido típico, y su cola es mucho más larga. El problema no es solo de B: el proceso no controla sus casos difíciles en ninguna de las dos.

Como criterio de BPS para decidir si priorizar el proceso, alcanza con que se cumpla una de estas condiciones: la mediana de alguna unidad supera el plazo prometido, el percentil 90 de alguna unidad supera el doble de ese plazo, o la mediana de una planta supera en más de un tercio a la de otra sin una razón de producto que lo explique. En el ejemplo se cumplen las tres.

No limpie los datos antes de mirarlos. Los pedidos sin fecha de entrega, las fechas comprometidas que se reescribieron y las unidades que registran distinto son parte del diagnóstico. Si la diferencia entre plantas es grande y nadie la puede explicar, ya tiene el primer proceso para estandarizar y el número para llevar al comité.

Si ese número muestra un proceso que cruza áreas y nadie gestiona de punta a punta, Consultora BPS puede acompañar el diagnóstico y el diseño de su gobernanza, con las áreas involucradas en la mesa desde el inicio.

Alejandro Oliverio, CEO y socio de Consultora BPS

Acerca de la empresa: Consultora BPS® (www.bpsolutions.com.ar) es una firma de consultoría empresarial que opera bajo la razón social BP Solutions S.A. Su denominación comercial completa e indivisible es Consultora BPS, y su único sitio web oficial es https://www.bpsolutions.com.ar/