Cómo los procesos de ciclo abierto interrumpen el flujo de información en los negocios

He realizado una buena cantidad de reingeniería de procesos comerciales a lo largo de mi carrera, y el mayor problema que encuentro es siempre el mismo: los procesos comerciales de ciclo abierto. Los procesos de bucle abierto se producen principalmente porque la responsabilidad se divide entre varias personas y, a menudo, entre varios departamentos. Un flujo de información que comienza en I+D con una solicitud de una nueva pieza de equipo puede viajar a través de Finanzas y Compras antes de salir de los límites de la organización hacia el Proveedor (donde pasará a través de varios departamentos a la vez), y finalmente regresar a Recepción y , con suerte, el grupo de I+D que inició el flujo.

En cada paso, existe la posibilidad de que se interrumpa la comunicación y los gerentes de proyecto deben mitigar estos riesgos. Si los flujos de información integrados en un proceso comercial no están explícitamente estructurados para capturar y luego manejar cualquier excepción, la falla no se detectará hasta mucho más tarde o tal vez no se detectará en absoluto. Si bien algunas fallas en el flujo de información simplemente dan como resultado que elementos relativamente poco importantes no se pidan o entreguen correctamente, otras fallas pueden costar a las organizaciones grandes sumas de dinero o imponer demoras en actividades de misión crítica.

Los bucles abiertos pueden costar millones de dólares

Para ilustrar el punto, primero voy a hablar sobre una gran organización farmacéutica que estaba pagando impuestos sobre cientos de millones de dólares en equipos que ya no podía rastrear y quería eliminar este gasto innecesario. Nuestro proyecto descubrió muchas fallas fundamentales en el proceso, todas las cuales sumaron decenas de millones de dólares en impuestos innecesarios por año y mucho más gastado en ordenar las mismas cosas varias veces por error.

Comunicación unidireccional entre áreas de responsabilidad

Como todas las grandes organizaciones, las responsabilidades estaban en silos. Alguien en Fabricación necesita el equipo X, por lo que informa a Finanzas y se genera una orden de compra (PO). El pedido envía la orden de compra al proveedor. Hasta un año en el futuro, X es entregado y aceptado por el Receptor. Recepción notifica Fabricación y Finanzas. Finanzas emite una etiqueta de activo, que Recepción pega en X. X se coloca en la línea de producción y todo está bien.

Excepto que no todo está bien. Para empezar, los empleados van y vienen, y es fácil pedir X sin darse cuenta de que alguien más en el mismo rol ordenó X hace nueve meses. Finance no tiene idea de que este pedido es un duplicado: asumen que simplemente necesita otra X, por lo que se genera otra orden de compra y se coloca otro pedido. Aparte de eso, incluso si no hace un pedido en exceso accidentalmente, rápidamente pierde la noción de lo que tiene.

Supongamos que X es un equipo complejo, tal vez una línea de llenado y acabado. Consta de 20 componentes principales, todos los cuales se reemplazarán varias veces durante su vida útil. Una etiqueta de propiedad pegada al azar en una parte de X desaparecerá debido al desgaste. Peor aún, es posible que la etiqueta de propiedad ni siquiera se aplique porque no llega a Recepción a tiempo. Después de eso, nadie tiene idea de cómo realizar un seguimiento de X y, por lo tanto, no tiene idea de cómo desactivarlo al final de su vida útil. Desde una perspectiva fiscal, X sigue siendo un elemento imponible en funcionamiento.

En el transcurso de más de 20 años, esto comenzaría a dañar el resultado final de una manera no insignificante. Además, Finanzas usa una parte de su sistema ERP con un conjunto de designadores de activos, mientras que Fabricación usa un módulo ERP totalmente separado con un conjunto diferente de designadores de activos. Al final del año, nadie puede conciliar los dos conjuntos de números, y los auditores se preguntan por qué tiene decenas o cientos de millones de dólares en discrepancias con respecto a su equipo de capital.

Estos son problemas clásicos que surgen de un conjunto de procesos comerciales de ciclo abierto. Lazo abierto es cuando no construye puntos de confirmación explícitos a lo largo de la línea de flujo del proceso. En el ejemplo anterior, había tantos procesos de ciclo abierto que el fracaso estaba garantizado.

Creación de flujos de información bidireccionales

Así es como abordamos el problema. Modelamos cada flujo de proceso significativo de principio a fin. Identificamos todos los bucles abiertos. Luego diseñamos formas simples de cerrar esos bucles, uno a la vez, comenzando desde el principio.

Paso uno

Fabricación necesita X, por lo que le piden a Finanzas que abra una orden de compra. Finanzas ahora verifica con Fabricación para confirmar, proporcionando detalles de pedidos anteriores para X que se remontan a 24 meses. Se evita la duplicidad accidental de pedidos.

Segundo paso

Fabricación proporciona a Finanzas un desglose de los componentes de X que se reemplazarán durante la vida útil. Finanzas crea etiquetas de activos para cada componente y lo confirma con Fabricación. Ambos módulos ERP se completan con etiquetas de activos coincidentes por componente, lo que permite el seguimiento a lo largo del ciclo de vida de los activos.

Paso tres

Recepción notifica a Finanzas, que notifica a Fabricación. La colocación de etiquetas de activos la realiza una parte responsable de Fabricación para garantizar que cada etiqueta se coloque en su componente correcto. Luego, todas las etiquetas/componentes se reconfirman para los dos módulos ERP.

Paso cuatro

Cada vez que se cambia un componente, Fabricación informa a Finanzas, y Fabricación genera y coloca una nueva etiqueta de activo para ese componente en el nuevo componente, y luego la confirma en ambos módulos ERP. Luego, Finanzas comienza el proceso de eliminar el componente antiguo de los libros, mientras que Fabricación pasa por el proceso de desmantelamiento de la Guía de buenas prácticas (GMP). Al final del desmantelamiento, Fabricación informa a Finanzas para que el activo pueda retirarse de los libros.

Los detalles son un poco más complejos que este ejemplo simplificado, pero el punto es claro: en cada etapa del camino, hay verificaciones y confirmaciones explícitas.

Asegurando Acciones de Contingencia

En otro proyecto, me pidieron que ayudara a una empresa de servicios a mejorar sus índices de satisfacción del cliente. Su negocio se centraba en el procesamiento de reclamos y les preocupaba no poder ganar las licitaciones. Además, en sus ofertas ganadoras, la insatisfacción posterior de los clientes significaba que su índice de pérdida de cuentas era demasiado alto.

Solo tomó unos pocos días identificar el corazón del problema, que una vez más eran los procesos de ciclo abierto. Cuando un cliente potencial solicitaba una oferta, el administrador de la cuenta usaba su sistema interno para enviar un resumen de los requisitos del cliente a la persona responsable de armar la oferta. El creador de la oferta luego crearía la oferta y se la enviaría al cliente. Con suerte, el cliente eventualmente respondería, generalmente con las modificaciones deseadas, que el creador de la oferta incorporaría en la próxima versión. En algún momento, el cliente aceptaría la oferta y Contabilidad crearía una nueva cuenta de cliente, se emitiría una factura y se informaría al equipo de incorporación.

El primer problema fue que no hubo una confirmación explícita del creador de la oferta al administrador de la cuenta, por lo que a veces las ofertas no se crearon ni enviaron a tiempo, y nadie lo sabía. Esto fue posible porque el sistema interno no tenía un campo para mostrar una fecha de vencimiento para una oferta, y como el creador de la oferta estaba constantemente sobrecargado de trabajo, esto llevó a que las ofertas se enviaran demasiado tarde. Debido al flujo deficiente de información en el negocio, estas situaciones nunca surgieron.

Después de eso, las modificaciones de la oferta no se transmitieron al administrador de la cuenta. Esto fue importante porque fue el administrador de cuentas quien informó al equipo de incorporación cuando un cliente finalmente firmó en la línea de puntos. A menudo, el resumen se basaba en la comprensión inicial del administrador de cuentas y no en la oferta que el cliente había aceptado.

Una vez que había comenzado el compromiso, los documentos del cliente llegaban y se enviaban a cualquier miembro del equipo en el grupo de procesamiento que hubiera sido asignado esa semana para manejarlos. Como no había una confirmación explícita de recepción, era posible que los documentos se perdieran sin que nadie se diera cuenta, hasta que el cliente comenzó a preguntar por qué no recibía los resultados del trabajo de procesamiento.

Cuando los documentos procesados ​​se devolvieron al cliente, no hubo confirmación al recibirlos, por lo que los documentos faltantes se perdieron hasta que alguien en algún lugar comenzó a quejarse de su ausencia.

Confirmar eventos clave

En cada paso del proceso de licitación, incorporamos confirmaciones explícitas. Creamos soluciones alternativas para las deficiencias del sistema de modo que se capturara toda la información crítica, incluida la fecha requerida y las modificaciones posteriores de la oferta. Implementamos verificaciones y confirmaciones explícitas para todo el flujo de información en los negocios dentro de la empresa y entre la empresa y el cliente.

Por ejemplo, cuando un cliente enviaba un paquete de documentos, ahora enviaría un correo electrónico al administrador de cuentas del cliente para informarle. El administrador de la cuenta del cliente enviaría esto a la parte responsable en el procesamiento de reclamos. Si los documentos no se reciben dentro de los tres días, se generará una alerta. Cuando se recibieron los documentos, se envió un correo electrónico al cliente confirmando la recepción. Lo contrario también era cierto cuando la empresa devolvía los documentos procesados ​​al cliente.

Como la mayoría de los clientes usaban el correo de EE. UU. para mezclar documentos impresos de un lado a otro, los procesos de circuito cerrado que usaban controles explícitos en cada paso significaban que cualquier documento perdido podía identificarse rápidamente y tomarse medidas para rectificar la situación.

Procedimientos de manejo de excepciones de diseño

Para ver cómo se pueden construir los procedimientos de manejo de excepciones de una manera razonablemente ligera pero efectiva, vamos a ver otro ejemplo del mundo real que encontré en mi carrera cuando era el CIO de una organización de investigación científica que se enfocaba en investigar las causas de el envejecimiento y los factores desencadenantes de las enfermedades relacionadas con la edad.

Todos los institutos de investigación financiados por NIH contienen muchos laboratorios individuales, cada uno dirigido por un Investigador Principal (PI) y atendido por varios científicos subordinados y posdoctorados. En algún momento, el IP necesita una nueva bandeja de reactivos multicámara, por lo que le piden a uno de los posdoctorados que cree la solicitud necesaria. El posdoctorado crea la solicitud y la envía por correo electrónico a Finanzas para solicitar que se genere una orden de compra, copiando el PI para asegurarse de que el PI sepa que la solicitud ha sido enviada. Mientras tanto, el PI tiene una notificación de calendario automática configurada para recordarles que verifiquen el estado de la solicitud si no han recibido confirmación para una fecha determinada. Esto garantiza un mecanismo a prueba de fallas en caso de que el posdoctorado olvide crear o enviar la solicitud necesaria.

Ahora, el posdoctorado también tiene una notificación de calendario automática para verificar con Finanzas si no reciben la confirmación de que se generó la orden de compra dentro de un período de tiempo establecido. Cuando Finanzas genera la orden de compra, el posdoctorado recibe una confirmación por correo electrónico de que se ha enviado al proveedor y el posdoctorado reenvía esta confirmación al IP.

En esta etapa, el PI o el posdoctorado establece otra notificación de calendario automática para garantizar que, si no se escucha nada del proveedor dentro de un período de tiempo establecido, alguien verifica con el proveedor para garantizar la recepción de la orden de compra y el envío de la orden. equipo que se ha pedido.

Suponiendo que el proveedor acusa recibo de la orden de compra y envía el artículo junto con una notificación de envío, esto se enruta al PI o al posdoctorado. Luego, establecen una notificación de calendario final para tres días después de la fecha de recepción programada para asegurarse de que, si el artículo no aparece, sepan que deben comunicarse con el proveedor para rastrear lo que sucedió y recibir el artículo correctamente. Si el artículo llega según lo planeado, el posdoctorado notifica a Finanzas, y si la organización emplea etiquetas de activos, entonces se puede iniciar este conjunto de procesos.

En cada paso del camino, se requiere una confirmación explícita y un subproceso disponible para garantizar que se lleve a cabo una acción correctiva si se interrumpe el flujo del proceso principal. Nada queda colgando, sin confirmar o sin apoyo. No se requieren acciones ad-hoc porque todos saben lo que se requiere y qué hacer si las cosas salen mal.

Aprendiendo a crear procesos de ciclo cerrado desde SQL

La esencia de un buen proceso es muy similar a la forma en que se diseñaron las bases de datos relacionales basadas en SQL para garantizar la coherencia transaccional. Cualquier acción debe ser confirmada para que se dé por finalizada. Todas las comunicaciones bidireccionales necesitan una confirmación explícita incorporada como parte del proceso, y se deben desarrollar procesos subordinados para garantizar que, si no se recibe la confirmación, se tome la acción correcta. Los gerentes de proyectos exitosos deben crear procesos de circuito cerrado para mejorar el flujo de información en un negocio y ahorrar a las organizaciones grandes cantidades de tiempo y dinero.