P006| LA IMPORTANCIA DE LA INTEGRACIÓN EN LAS OPERACIONES (#in)

¿Cómo es posible que haya empresas que denominan Operaciones, a sucedáneos -que lejos de ser OPEX- no llegan ni a una mera integración de las áreas que intervienen en uno de los 3 principales procesos, de cualquier empresa? algunos ejemplos de los que he podido ser testigo de ineficiencia, en el proceso de FULFILLMENT:

• Áreas de ingeniería que proponen optimizar cajas, alterando su altura, sin avisar al almacén que tendrá que recepcionarlo (que no digo que deba “no motivarse” el cambio, sino ¡que se debe coordinar!)
• Compras optimiza el coste de adquisición, por encima del de tenencia, generando grandes ocupaciones en almacenes (¡porqué cabe, dicen!), y por ende grandes obsolescencias, mientras Gerencia fuerza a reducciones de personal, para equilibrar la cuenta de resultados (¿estamos locos?). ¿Qué comité de empresa puede entenderlo? hay que ser consistente/ coherente por encima de todo.
• Deptos. de Informática sin el más mínimo interés en comprender que las dificultades en un flujo, inciden en costes, porque la lentitud, es sinónimo de incrementar capacidades (=coste). Que escuchan las quejas de usuarios, como cantos de sirena…..si un usuario dice que la línea/ pc, va lento, como mínimo se deberá verificar, ¿o soy marciano?
• El análisis de demanda -lo saben hasta los más noveles- contra más detalle, mayor imprecisión (falta de accuracy), por tanto perder el tiempo en detalle, ¡es eso! pérdida de tiempo. La demanda, es mejor agregarla, y trabajar el acierto, estudiando el despliegue hacia la SKU, como un coeficiente a adicionar al valor agregado (“la llave del despliegue”)
• ¿Cómo es posible que haya empresas, que teniendo oportunidades de gestionar el negocio, tipo PULL, lo haga todavía tipo PUSH? Posponement ya no es una práctica novedosa. ¿Cómo es posible que todavía la misma referencia, se personalice (SKU), o por cliente, o por mera sku (PUSH), generando altos niveles de ocupación, cuando podría conservarse en bulk y aplicar posponement con el pedido en mano (PULL)? ¿estamos locos?
• Si además, de trabajar en PUSH, nos aprovisionamos de fuentes ubicadas en “larga distancia” ¿qué es lo que queremos? simple y llanamente: fracaso de nuestras operaciones.
• Organizaciones dónde el Customer Service, está en manos de diferentes rpbles. el Front y el Back-office. El que maneja el aprovisionamiento, no está conectado con el centro de distribución (ni mucho menos, motivado, a “no generar ruido”), hasta el punto que el centro desconozca los días de llegada de los proveedores.
• Promociones comerciales, poco elaboradoras, que dan pie, a que los vendedores “propongan excepciones” que no hacen más que: consumir recursos administrativos (que después de sobre-dimensionan para “dar servicio al cliente”), y ralentizar la cadena.
• Los Deptos. soporte, se limitan a vivir en la inopia, persiguiendo solventar sus problemas, en lugar de priorizar que los procesos sean ágiles y eficientes. Los procesos clave, generan valor, mientras que los de soporte, simplemente coste (“mal necesario”). Cuando eso se invierte, ¡la organización es un despropósito!

¿Cuando consideramos que un proceso es eficiente? cuando asumiendo que el que tenemos, lo es (eficiente), le aplicamos velocidad (más inputs por la misma unidad de tiempo), y éste (el proceso) sigue siendo eficiente (sin OPEX, adelanto que es poco usual, que aplicándole más velocidad, permanezca estable).

¿Dónde se evidencia que un proceso pasa a ser “menos estable”? generalmente downstream (=aguas abajo), y cuando ahí se aplican soluciones (=parches) se diagnostica que esa área NO FUNCIONA (ja, ja!), cuando en realidad lo que no funciona está upstream (=aguas arriba) en la cadena.