¿Pueden coexistir BPM y RPA? ¿Qué hacen de manera diferente?

Recientemente, tuve la oportunidad de presentar BPM y FireStart en un webinar, y el tema de la presentación justo antes que la mía era sobre RPA y cómo las organizaciones pueden usar bots para automatizar procesos. Naturalmente, cuando era mi turno de presentar, la pregunta anterior se preguntó antes de empezar. Un gran transición casi imperceptible, entre los dos temas, y una pregunta que me piden bastante a menudo en las conferencias.

Mi corta respuesta: Sí, las dos pueden coexistir por qué las dos resuelven dos diferentes problemas.

Hay muchos sitios web que entran en detalles y discusiones sobre las diferencias entre RPA y BPM, y en algunos casos estas pueden ser discusiones muy animadas sobre si uno puede hacer el trabajo del otro. Muchos de estos artículos son escritos por practicantes y expertos en ambos campos, y están llenas de jerga y terminología de la industria. Para alguien que acaba de mojarse los dedos en este tema, puede ser confuso.

Por lo tanto, este no es otro artículo tan lleno de jergas. Este es un artículo sobre McDonald´s.
 

En 1940, los hermanos Richard y Maurice McDonald abrieron su primer restaurante “barbecue drive-in” en California. Este era el tiempo en el cual los “drive-ins” estaban obteniendo popularidad, y los “car-hops” dejaban comida directamente en los automóviles de su cliente. Como sea, los tiempos de producción se mantenían altos, las entregas no eran puntuales, y los clientes casi no recibían su comida caliente. En ese entonces, solo había una solución para ese problema: un “short-order cook”. Los “short-order cooks” son especializados cocinando comida que no dure mucho tiempo preparándose. Ellos mandarían una estación de asar grande y podrían procesar muchas ordenes diferentes al mismo tiempo. Puesto que esto requirió habilidad y entrenamiento, los buenos cocineros “short-order” estuvieron en alta demanda gracias a la cantidad de “drive-ins” ubicados en California, y eran difíciles de encontrar y caros de contratar.

Reconociendo ese asunto, los hermanos McDonald cerraron su restaurante y trabajaron en un nuevo proceso que llamaron “Speedee Service System”, modernizando su modelo de restaurante basado en una línea de montaje del automóvil. En vez de usar mano de obra especializada, tales como los “short-order cooks”, el sistema “Speedee” emplea una gran cantidad de trabajadores no calificados, cada uno con un pequeño pero específico paso  en los procesos de producción. El proceso por sí solo era increíblemente LEAN en vez de hacer una larga variedad de comidas, el proceso fue diseñado para hacer unos cuantos artículos más rápidamente. Ellos abrieron sus nuevos restaurantes de “comida rápida”- y el resto es historia famosa. Sus procesos ahora han sido copiados, usados y envueltos en cada cadena de comida rápida de todo el mundo. 

¿Qué tiene que ver esto con BPM y RPA?

Me gusta usar la analogía de McDonald´s cuando discutimos sobre BPM y RPA. Probablemente hayan mejores comparaciones, pero la primera vez que alguien me preguntó sobre la pregunta de BPM vs RPA, yo estaba bebiendo un café en un McDonald´s después de haber terminado un Egg McMuffin. De hecho, había ordenado mi desayuno usando uno de los kioscos automático: deslicé mi tarjeta de credito, y procedí a recoger mi comida en el mostrador.
El proceso detrás de escenas era el usual, los empleados de McDonald´s estaban montando sandwiches, friendo “Hash Browns” y preparando ingredientes. Pero el cajero había sido remplazado por un robot.

El McBPM:

Inicio > El cliente pide la orden > La cocina recibe la orden, prepara la comida > La cocina coloca la comida en la bandeja de calentamiento > El cajero dispensa las bebidas > El cajero provee la comida y las bebidas al cliente > Fin.

Hay un proceso aquí, e incluso sub-procesos en los cuales algunos de esos pasos se podrían romper. Si monitoreamos este proceso, podemos encontrar espacio para mejorar y reducir el desperdicio. Como parte de BPM, podemos implicar la automatización de procesos en vez de tener al cajero gritando la orden a la cocina (mala calidad de datos) o imprimiendo y pegando un papel en la cocina (gasto de tiempo y material), el sistema de pedidos rellena una pantalla en la cocina, que permite informar a los empleados qué productos ocupan preparar. En vez de que el cajero sirva los refrescos, ahora, muchos de los restaurantes de comida rápida le dan un vaso al cliente y señalan las máquinas de auto-servicio de refrescos.

Las papas RPA:

El trabajo específico del cajero era escuchar la orden del cliente e introducirla en el sistema, recoger el dinero, proveer el cambio y luego proveer la comida al cliente. Bueno, si podemos robotizar la mayoría de esas funciones, la única tarea que un humano tendría que hacer sería traer la comida de la cocina y entregarla al cliente. Por ahora.

BPM es sobre sus procesos en general, “end-to-end”. Usted puede concentrarse en tareas específicas si usted así lo quisiera, pero usted realmente debería buscar el contexto de la tarea. ¿Cuáles datos son requeridos para realizar la tarea, y cómo se entrega al usuario? ¿Cuáles datos salen de la tarea, dónde se necesita y cómo llegar allí?

RPA es sobre la tarea. ¿Cuáles funciones repetitivas pueden ser automatizadas? ¿Puede un humano enseñar a un robot a ser parte de su trabajo diario?

En la analogía de McDonald´s, automatizar el cajero fue el RPA. Sin embargo, la digitalización de la transferencia de la información de la orden del cajero a la cocina cae bajo BPM. Ambas funciones son elementos clave para la mejora del rendimiento y ambos pueden definitivamente coexistir.

Si usted está empezando por el camino de la transformación digital, ¿Cómo  debe empezar? Personalmente, yo empezaría con BPM. BPM le ayudará a establecer y mejorar sus procesos en primer lugar, y a automatizar eventos y tareas. Una vez que esto está en lugar, es más fácil analizar las tareas “human-centric” que permanecen y ver cómo se puede utilizar el RPA para optimizar aún más procesos.

Entonces, ¿a usted le gustarían las papas fritas en ese “combo”?

Este artículo fue publicado originalmente por Shyamal Addanki el 26 de Setiembre del 2017.
Todos los derechos de autor y propiedad de las marcas mencionadas en este artículo pertenecen a sus respectivos dueños.
Blackberry&Cross es aliado de ProLogics.

---

Original: Jueves 4 de Enero, 2018.