Diseñando el mejor proceso posible

Este artículo analiza algunas de las herramientas más efectivas que los Lean Practitioners pueden implementar para diseñar procesos sólidos caracterizados por una secuencia efectiva de tareas y un enfoque en el valor del cliente.

En múltiples ocasiones, durante nuestro trabajo para apoyar a las organizaciones en sus esfuerzos lean, nos hemos tenido que enfrentar al reto de representar visualmente procesos que no podemos ver en funcionamiento, por ejemplo, porque representan un estado futuro que aún no existe. En tales circunstancias, sin la orientación proporcionada por el gemba, comprender cómo llevar a cabo un proceso puede resultar difícil.

Entre las situaciones entre las que nos podemos encontrar con esta dificultad se encuentran:

• Procesos no estructurados o definidos débilmente; en los que cada persona que participa en el proceso lo lleva a cabo de una manera diferente. Esto suele ser muy habitual en el entorno de procesos administrativos, en los cuales se ha permitido la personalización de la ejecución de los procesos adaptándose a las habilidades o requerimientos de los propietarios de los mismos. En estos casos, los resultados se vuelven más importantes que el proceso en sí mismo.
• Procesos requeridos por la introducción de un nuevo producto o servicio en nuestro catálogo (procedente, quizás, de otra planta de nuestra organización), o persiguiendo la diversificación del negocio. Los procesos pueden existir, pero no en el contexto de nuestra organización, como en el ejemplo de una organización que introduce un nuevo producto en una planta que era producido en otra diferente.
• Actividades relacionadas con el ámbito del desarrollo de productos o procesos, y de la gestión de proyectos en general, en el que la propia singularidad de cada uno de ellos (muy vinculados a la innovación y a la creatividad), hacen que sean difíciles de trazar.
• Rediseño completo de procesos.

Recuerdo un caso concreto de las situaciones mencionadas en el que participé para el mapeado del proceso de gestión de reclamaciones de clientes de una empresa que diseñaba y fabricaba componentes para otros industriales. La complejidad del sistema, debida a la participación de múltiples departamentos desconectados entre sí, y del uso de diferentes plataformas IT (el CRM, el MRP, el de planificación de la producción, el de gestión de la calidad, …), conducían a un proceso exageradamente complejo y difícil de monitorizar, y, desde la perspectiva del cliente, demasiado lento. El “ajustar” el proceso a una situación más acorde a las necesidades del cliente, parecía inviable y el equipo decidió rediseñarlo completamente, focalizándose en los requerimientos del cliente en vez de focalizarse en los recursos disponibles y el modus operandi existente en la organización. Como resultados, supuso una reducción de la cantidad de actividades necesarias para su ejecución de más de un 35% y una reducción del lead time del proceso de más de un 70% (también hubo varias llamadas de clientes preocupados interesándose por si les estaba pasando algo “extraño” en la organización …).

En cualquier caso, se trata de una situación lo suficientemente habitual como para necesitar una manera estructurada de enfrentarse a ella. No pretendo concluir que la propuesta que describiré en este artículo sea la mejor para enfrentarse a este problema, pero sí que he de admitir que siempre que la he usado, he obtenido resultados positivos tanto para el proceso en sí mismo como en el aprendizaje de las personas involucradas.

Está claro que, tal y como nos enseñan los expertos en el pensamiento Lean, cualquier iniciativa de resolución de problemas ha de comenzar con la identificación del valor esperado o requerido por el cliente (y, a su vez, a la identificación de los propios clientes) y, posteriormente, la secuencia de actividades que conducen a la consecución de este valor. Posteriormente, necesitamos encontrar una manera de establecer un flujo continuo y operado por un pull desde cliente, entrando en el ciclo de la mejora continua persiguiendo la excelencia en su ejecución. Esto es lo que Dan Jones y Jim Womack escribieron en Lean Thinking. En el contexto del Total Quality Management (TQM) existe una herramienta que relaciona a todos estos aspectos, conocida como SIPOC.

El SIPOC es una herramienta que permite la definición y estudio de un proceso a través de la identificación de los principales elementos requeridos para su ejecución, y cuyas iniciales, en inglés, determinan el nombre: Supplier – Input – Process – Output – Customer.

Esta herramienta, habitualmente utilizada en el ámbito del Six Sigma y de la gestión de proyectos, es muy sencilla y potente a la vez. Se inicia con el establecimiento del inicio y final del proceso; a continuación, se dibujan en un trozo de papel 5 columnas (una por cada uno de los 5 elementos mencionados).

En algunas versiones de esta herramienta, se intercalan 2 columnas adicionales correspondientes a los requerimientos específicos de los inputs para ejecutar el proceso y de los outputs para satisfacer al cliente. Esto nos ayudará a definir más claramente el proceso.

Finalmente, se rellenan las columnas indicando las relaciones entre los diferentes elementos incluidos en la tabla. Tradicionalmente se propone POCIS como el orden a seguir:

De hecho, recientemente está tomando fuerza una variante de este proceso que cambia el orden de ejecución de la misma y que responde a las siglas COPIS. De esta manera se enfatiza la importancia que tiene el cliente en la propia definición del proceso.

Entonces, comenzamos identificando a los clientes interesados en el proceso, y se deben incluir a los usuarios, compradores, y clientes internos. En algunos casos, necesitamos reflejar clientes como la Administración pública o la Sociedad (por ejemplo, para procesos molestos, insalubres, nocivos o peligrosos que pueden impactar negativamente en la sociedad). Si somos capaces de identificar a todos los clientes interesados, nos resultará más sencillo averiguar qué esperan obtener del proceso.

Cada tipo de cliente puede mostrar unas necesidades específicas del proceso. Por ejemplo, el cliente “usuario” en un producto como puede ser “bocadillo” se centrará en aspectos de seguridad alimentaria, calidad, y precio; mientras que el propietario del proceso (el vendedor en este caso) mirará por los márgenes, precios de venta y la penetración en el mercado que presente dicho producto. Una buena caracterización del proceso debe contemplar a ambos tipos de cliente con el fin de asegurar que seamos su proveedor favorito. Por lo tanto, debemos especificar los outputs requeridos por los clientes, es decir, el valor que esperan. Se deben de concretar en aspectos medibles y objetivos con el fin de asegurar que la ejecución del proceso resultará en la consecución de estos parámetros.

Para definir el valor de cliente existen muchas herramientas como el VOC (voice of customer), las encuestas, los estudios de mercado, …, y en muchas ocasiones, los propios resultados de un análisis riguroso de las reclamaciones recibidas de los clientes y del propio comportamiento del "embudo" de ventas. A la hora de incluir cualquier aspecto de valor en la tabla, es importante relacionarlo con el cliente que requiere de ese aspecto. De esta manera tendremos más control sobre el sistema y siempre podremos verificar la vigencia del requerimiento (recordemos que nos encontramos en un contexto VUCA que conduce a la variación continua de los requerimientos del cliente).

Ahora es el momento de definir el proceso. Para ello, empezamos por el producto final y vamos identificando cada una de las actividades necesarias para conseguir el propósito mostrado en la columna de Outputs. En este punto es importante que la definición de las actividades sea a alto nivel sin bajar demasiado en los detalles, porque en este caso se complicaría mucho su representación gráfica y por tanto limitaría la potencialidad de esta herramienta. En cualquier caso, empezamos a conectar las actividades una tras otra hasta que somos capaces de asegurar la obtención de todos los outputs identificados en el SIPOC.

En este momento, hay que tener en cuenta de que nos pasará lo siguiente (en un proceso muy simplificado para que se pueda mostrar la idea): 

La interconexión de las actividades, provoca que una determinada actividad (por ejemplo, la P3) sea parte del proceso (una de las “n” etapas por las que está formada), sea cliente (de la actividad P2, con sus requerimientos específicos I3 que serán parte de las O2) y, simultáneamente, proveedor de la actividad P4. Es muy habitual que puedan aparecer outputs intermedios requeridos por los clientes internos (etapas siguientes) pero que no hayan sido identificadas en un estudio preliminar de los clientes del proceso global. En el SIPOC esta situación se materializará apareciendo outputs en determinadas actividades que posteriormente se transformarán en inputs de etapas sucesivas. Es precisamente por esto por lo que se recomienda realizar este proceso etapa a etapa, desde el final al principio y mediante el empleo de "sticky notes" sobre un trozo de “papel marrón” ó papel kraft colgado en una pared, que nos permitan modificar el resultado fácilmente.

En esta etapa, para cada actividad incluida en el proceso, necesitamos identificar los requerimientos específicos para asegurar el logro del resultado operativo definido por los Inputs (o al menos minimizar el riesgo de variación en los resultados).

Finalmente, para cada input detectado que proceda del exterior del sistema (que no sea el output de una etapa anterior), hemos de identificar al “mejor” proveedor que nos lo pueda suministrar en las condiciones establecidas en los requerimientos.

La siguiente figura muestra un ejemplo muy simplificado del SIPOC correspondiente a la preparación de café para el desayuno de una familia mediante una cafetera de filtro de papel:

Hay que resaltar que la propia mecánica de ejecución de esta herramienta favorece y promueve el trabajo en equipo y la participación de todos a través del simple proceso de pegado de sticky notes en un panel y de la propia discusión a medida que la tabla se va rellenando.

Los procesos a los que habitualmente nos enfrentamos, son mas complicados que lo descrito hasta ahora. tan sencillos como los discutidos hasta ahora. Una de las mayores dificultades que presentan es identificar la secuencialidad de las propias actividades. No existe una única secuencia que conduzca al resultado pretendido. Entonces, ¿qué secuencia representamos? ¿Cómo saber que hemos escogido la adecuada? Para responder a estas preguntas podemos echar mano de otra herramienta habitualmente empleada en el contexto de la gestión de proyectos: el diagrama de precedencias. Se trata de una herramienta gráfica que permite representar todas las maneras posibles en las que se puede llevar a cabo un proceso, derivadas de las diferentes secuencias posibles que conducen al mismo resultado.

Como ejemplo, imaginémonos un proceso muy sencillo que todos conocemos, “levantarse para ir a trabajar cada día”. Este proceso comienza cuando suena el despertador y termina cuando estamos listos para salir de casa para llegar al trabajo puntualmente. Estas son las actividades que necesitaremos llevar a cabo:

• A: Levantarse
• B: Preparar el desayuno
• C: Desayunar
• D: Recoger el material del desayuno
• E: Ducharse
• F: Secar el pelo
• G: Ir al baño
• H: Lavar los dientes
• I: Averiguar la situación del tráfico
• J: Vestirse
• K: Coger la mochila/bolso y las llaves del coche
• L: Ponerse los zapatos y la chaqueta
• M: Hacer la cama
• N: Salir de casa

La secuencia mostrada no es la única y tampoco tiene porqué ser la mejor para todos nosotros. El diagrama de precedencias nos presenta a cada una de estas actividades mostrándonos sus relaciones de dependencia, y cuáles se han de llevar a cabo antes que otras. Necesitamos preparar el desayuno antes que podamos comerlo.

Podemos clasificar la dependencias en:

• Obligatorias son inherentes a la naturaleza de la propia actividad y no podemos cambiarla.
• Discrecionales que, sin haber requerimientos obligatorios, se prefieren en un orden específico atendiendo a diversos criterios coyunturales.
• Externas son las que aparecen derivadas de condicionantes externos sobre los que no es habitual actuar, por ejemplo, la disponibilidad de un determinado tipo de recurso.

Recomiendo comenzar teniendo únicamente en cuenta las obligatorias ya que las otras dependencias pueden ser susceptibles de decisiones no fundamentadas (“¡siempre lo hago así!”, y no podremos actuar sobre él sin un conocimiento profundo del proceso. Así podemos obtener este diagrama:

Lo que nos muestra el diagrama, es que el proceso siempre ha de comenzar con la actividad de “levantarse”. A partir de ahí, tenemos varias opciones: podemos empezar por “preparar el desayuno”, o por “ducharse”, o por “ir al baño”, o por “lavar los dientes”, o por “averiguar el estado del tráfico”, o por “hacer la cama”; pero no podríamos continuar por “desayunar” porque requiere que esté preparado previamente. Y así sucesivamente. Usando este diagrama podemos obtener las diferentes posibles secuencias de las actividades dependiendo de lo que queramos obtener. Por ejemplo, no “cogeré la mochila y las llaves del coche” hasta que esté dispuesto a salir (es decir la colocaré como penúltima actividad). ¿Por qué? Porque si lo hago en cualquier otro momento me molestará e incordiará para ejecutar adecuadamente el resto de las tareas.

Entonces, para reducir desplazamientos innecesarios, cuando entremos en el lavabo, llevaremos a cabo todas las tareas que se realizan allí. De la misma forma, puedo evitar una espera haciendo la cama mientras la cafetera prepara el café. En ambos casos, estaríamos actuando sobre el lead time y el coste del proceso. Con el diagrama de precedencias podemos controlar cómo llevamos a cabo el proceso y adaptarlo a los cambios de circunstancias fácil y rápidamente.

Una vez que hayamos definido la secuencia de tareas que necesitamos para obtener el resultado deseado, podemos traducirlo a nuestro mapa de flujo de valor para continuar con nuestro análisis y mejora del proceso en general, con la única condición de que sin acceso a un gemba todos los datos relacionados con las operaciones y el trabajo en progreso deben provenir de la estimación (pero esa es otra historia).

Combinando el SIPOC con el diagrama de precedencia y análisis de valor, podremos diseñar un proceso que podemos mejorar y aprovechar al máximo, mientras desarrollamos conocimiento sobre el trabajo para entregar constantemente el máximo valor a los clientes con el mínimo uso de recursos.

Extraído de: Planet Lean