Mostrando entradas con la etiqueta Systems thinking. Mostrar todas las entradas
Mostrando entradas con la etiqueta Systems thinking. Mostrar todas las entradas

martes, 7 de junio de 2022

Lean: El bar de Pepe

 


El bar de Pepe es atendido por un Barman que prepara pedidos de bebidas a sus clientes. Un día, el Barman comenzó a leer un libro acerca del pensamiento 'Lean', y así comprendió algunos conceptos nuevos para él, aunque datan de muchos años atrás.


Cuatro de estos conceptos son los siguientes: el trabajo en proceso o WIP, que indica los pedidos que se están preparando; el tiempo de entrega de una bebida, o también denominado Lead Time, que es el tiempo total desde el momento en que le hacen un pedido hasta el momento en que lo sirve y entrega al cliente; el tiempo de ciclo o Cycle Time, es el intervalo de tiempo entre dos bebidas que salen de la barra y son entregadas al cliente o tiempo que se tarda el Barman en completar la preparación de una bebida; y el rendimiento o Throughput, que es el número de bebidas que se entregan en un período de tiempo, como si se tratase de su velocidad de entrega.


Proceso Kanban del bar de Pepe
Proceso Kanban del bar de Pepe y sus métricas relevantes

Con estos conceptos aplicó la famosa Ley de Little que dice que "la cantidad promedio de elementos de trabajo en proceso (WIP) en un sistema estable, con WIP fijo, es igual a la tasa de entrega (Throughput) promedio multiplicada por el tiempo promedio que pasan en el sistema (Lead Time)".

Así que calculó su tiempo de entrega basado en su rendimiento individual, estimando una media de seis bebidas entregadas por hora, preparando una bebida a la vez (WIP=1).

WIP = Throughput x Lead Time

1 = 6 bebidas x hora * Lead Time

Lead Time = 1 / 6 x hora

Lead Time =  0,16 hora = 10 min

Así supo que el tiempo en que se demoraba en satisfacer las necesidades de sus clientes era de 10 minutos, su Lead Time.

Pepe, quien gestionaba el bar, le pidió al Barman que trabajara más duro y que atendiera a varios clientes a la vez, porque así sería más eficiente. Le pidió que hiciera 3 pedidos en paralelo.

Luego de un tiempo el Barman hizo el cálculo de su Lead Time considerando el mismo rendimiento individual.

3 = 6 x hora * Lead Time

Lead Time = 3 / 6 x hora

Lead Time =  1/2 hora = 30 minutos

Resulta que descubrió que lo que parecía más eficiente para el gerente era todo lo contrario para el cliente, porque ahora se demoraba media hora en entregar cada pedido.

Así es como el Barman comenzó a convertirse en Bartender aplicando 'Lean'.

Gestiona el sistema, no las personas


Con John Little y su ley se viene contando esta historia de diferentes maneras y diferentes autores, como Cliyahu Goldratt con “The Goal” o Caroli con sus "Whisky, Sushi, Systems and Flow". Pero contar historias es fácil, lo difícil es implementar sus enseñanzas. Este ejemplo es muy simple, pues en las organizaciones el flujo de trabajo es mucho más complejo, con mayores dependencias, diferentes roles, tipos de trabajo y muchas variables en juego. A pesar de la complejidad en la mayoría de organizaciones, las ideas de Little se pueden aplicar en el día a día en cualquier equipo de trabajo o área. Principalmente porque es un principio sistémico y todas las organizaciones y sub-organizaciones son sistemas.


Estos conceptos son útiles para entender el sistema de trabajo de una organización. Utilizando el ejemplo del Barman se dimensiona el funcionamiento del sistema usando estos conceptos, entendiendo que para el cliente el Lead Time es lo más importante, incluyendo tanto el tiempo de espera como el tiempo de proceso. Este último, el Cycle Time, indica el tiempo en el cual el 'ítem de trabajo' fue realmente procesado sin cola de espera. Muchas veces los administradores se centran mucho en el Cycle Time sin prestar atención al tiempo de espera, olvidándose así que en sistemas complejos la suma de todos los tiempos de espera generan un alto costo de retraso. Sin embargo, con Lean se sabe que lo que importa son ambos (tiempos de espera y Cycle Time), y que la felicidad del Barman y del cliente dependen de lograr un sistema estable de flujo con cadencia. Si a la barra del bar llegan más pedidos de los que se puede atender, se dejarán clientes insatisfechos y se exigirá al sistema de más, generando mala calidad del producto, errores o agotamiento del personal. Por el contrario, si su velocidad de entrega (Throughput) es mayor a la velocidad de llegada de pedidos, tendrá demasiada ociosidad. Por lo tanto, la eficiencia está en el balance, donde la tasa de arribos (AAR) debe ser equivalente a la tasa de entregas (ADR). 


Proceso Kanban del bar de Pepe y tasas de entrada y salida del sistema

En un sistema estable, balanceado, no hay divergencia ni convergencia entre tasas de arribos y entregas. El Barman trabaja a su capacidad, saludablemente, en un tiempo óptimo de entrega, satisfaciendo las necesidades de sus clientes. Así el bar se mantiene y puede prosperar.


Diagrama de tasas de entrada y salida de un sistema balanceado y estable



Pero todo sistema tiende a desbalancearse. Si el sistema está desbalanceado, no sirve de nada que Pepe presione al Barman para que trabaje más rápido, haga pedidos en paralelo o realice horas extras. La clave está en el balance, y parte de balancear es controlar el WIP y no a la gente. Gran parte de las veces, el rendimiento del sistema depende más de la estructura del sistema que de los rendimientos individuales de las personas que participan en el sistema.


En un sistema desbalanceado, una tasa de divergencia positiva (entre la tasa de arribos y la de entrega) sugiere que el WIP es demasiado alto y estamos sobrecargados (entran más pedidos de lo que salen). 


Diagrama de tasas de entrada y salida de un sistema desbalanceado



Por otro lado, una divergencia negativa (entran menos pedidos de los que pueden salir) sugiere que el límite WIP es bajo y que la productividad es baja (desaprovechando capacidad).


Sistema desbalanceado con divergencia negativa


Hay algo peor que un sistema desbalanceado y es un sistema muerto. Si una línea se vuelve plana, eso significa que no llega nada a la etapa correspondiente o que nada sale; y cuando nada entra y nada sale es cuando prácticamente un sistema muere. Si un bar no recibe pedidos y no entrega bebidas muere.


Sistema sin actividad
Sistema sin actividad

¿Para qué nos sirven entender estos gráficos anteriores? Pues, nos ayudan a comprender una de las herramientas analíticas más usada en gestión Lean, el Diagrama de Flujo Acumulado (CFD). El CFD nos muestra el nivel de estabilidad del flujo en un sistema de trabajo, ya sea un bar, un restaurante, un equipo de desarrollo de software o un equipo de reclutamiento. 


Ejemplo de un Cumulative Flow Diagram – CFD
Ejemplo de un Cumulative Flow Diagram – CFD



En resumen, como indica John Little (1961) "el número medio de elementos de trabajo en un sistema estable es igual a su tasa de terminación promedio, multiplicada por su tiempo promedio en el sistema".



Finalizando con el ejemplo, si Pepe comienza a tener la mirada Lean como el Barman hará suya una frase que dice: "Gestiona el sistema, no las personas" (Management 3.0). Más gerentes deberían aplicar la ley de Little y gestionar el sistema: minimizar Cycle Time y Lead Time, maximizar Throughput (promedio), limitar el WIP a un óptimo y balancear (igualar tendencias AAR y ADR).






Referencias:







miércoles, 29 de marzo de 2017

System Thinking: Facilitación gráfica sistémica

Facilitación gráfica sistémica


En nuestro pensar conversan constantemente el zorro racional y el colibrí emocional. Y, tal vez, para compensar tanta planificación y frivolidad racional, el agilismo trajo el pensamiento y facilitación visual a la mesa de la ingeniería de software. Pienso que encontrar el equilibrio entre estos dos mundos es inmensamente fructífero en el desarrollo de software. Si nos quedamos entrampados en el pensamiento visual y sus herramientas, como post-its y colores nos podemos perder en el holismo y con él en el desorden. Y no salir de la baldosa de la racionalidad ingenieril nos puede hacer ciegos de la creatividad y cortos en la innovación. El arte es encontrar el camino del medio.




Bajo el marco de la agilidad se emplean las facilitaciones gráficas para traducir conceptos complejos y ayudar a razonar o analizar problemas complejos en un lenguaje visual de palabras e imágenes. Esta estrategia puede ser una manera muy eficaz de resumir y comunicar ideas, permitir a los participantes ver e interiorizar el panorama general de una discusión o presentación y facilitar el análisis de la realidad y de sistemas. Pero considero que las dinámicas divertidas y coloridas no debería reemplazar a la ingeniería ni los post-its reemplazar el modelado de sistemas.

Facilitar gráficamente no debería ser graficar por graficar. Cuando dibujamos, lo que hacemos es modelar. Hacemos una representación simplificada de un sistema en algún punto particular en el tiempo o el espacio destinado a promover la comprensión del sistema real (Bellinger 2004); por tal motivo, hay que tener en cuenta que modelar de una forma acertada, para comprender el sistema real, requiere usar herramientas apropiadas. Sino podríamos llegar a modelar ideas que no se condicen con la realidad, perder tiempo, llegar a problemas que no son causa raíz y/o llegar a soluciones que no lo son y que hasta pueden llegar a ser problemas futuros.

Diagramación y notación


La facilitación gráfica no nos sirve de nada en ingeniería de software (más que como entretención, embellecimiento o apoyo de una conversación) si no usamos “herramientas conceptuales de diagramado” con estándares de notación, “conceptos de sistemas” y herramientas 'ingenieriles'. No es necesario usar lenguaje técnico ni usar los diagramas en forma estricta, se pueden adornar y enriquecer gracias al uso de la creatividad. Pero, a mi criterio, no se debería perder de vista que debemos mantener cierta concordancia con la realidad y el profesionalismo que la disciplina requiere.

A continuación comparto un conjunto de “herramientas conceptuales de diagramado” que todo facilitador gráfico y sistémico podría emplear:


  1. ADL: es un lenguaje de descripción de arquitectura (Architecture Description Language) como lenguaje informático para crear una descripción de una arquitectura de software. Algunas ADL que se han desarrollado son: Acme (desarrollada por CMU), AADL (estandarizada por SAE), C2 (desarrollada por UCI), SBC-ADL (desarrollada por National Sun Yat-Sen University), Darwin (desarrollada por Imperial College Londres) y Wright (desarrollado por CMU).
  2. BD: El diagrama de bloques (Block Diagram) es la representación del funcionamiento interno de un sistema, que se hace mediante bloques y sus relaciones, y que, además, definen la organización de todo el proceso interno, sus entradas y sus salidas.
  3. BPMN: Business Process Modeling Notation. Modelo y Notación de Procesos de Negocio, es una notación gráfica estandarizada que permite el modelado de procesos de negocio, en un formato de flujo de trabajo (workflow). Se usan en análisis de negocio y análisis de procesos.
  4. CD: Conceptual Diagram, Concept Map or Concept Draw.
  5. CLD: Causal Loop Diagram. Un diagrama de bucle causal (CLD) es un diagrama causal que ayuda a visualizar cómo las diferentes variables en un sistema están causalmente interrelacionadas. El diagrama consta de un conjunto de palabras, flechas y signo de acusación (acusación directa o inversa). Se usan en dinámica de sistemas.
  6. ER: Entity Relationship Diagram con Entity Relational Model. Diagramar entidades y relaciones para modelar bases de datos en software o entidades en un dominio de datos (Big Data, etc.).
  7. EER: Enhanced entity–relationship model. Diagramar entidades y relaciones.
  8. ERD: Diagrama de entidades de bases de datos (Entity Relationship Diagram (ERD)).
  9. FBD: Functional Block Diagram.
  10. FC: Flow Charts (for control flow).
  11. DFD: Data Flow Diagram.
  12. DDD diagrams: Domain Driven Design.
  13. MMD: Map Mind Diagram.
  14. SBD: Signals Block Diagram.
  15. SC: Structure Chart.
  16. SFD: Stock and Flow Diagrams.
  17. SSADM: Structured Systems Analysis and Design Method.
  18. SIPOC: Supplier-Input-Process-Otputs-Customer. Sirve para modelar sistemas en una perspectiva de Proveedores (Suppliers), Entradas (Inputs), Procesos (Process), Salidas (Outputs) y Clientes (Customers). Usado en análisis de procesos y sistemas.
  19. UML: es un lenguaje de modelado (Unified Modeling Language) visual común y semántica y sintácticamente rico para la arquitectura, el diseño y la implementación de sistemas de software complejos, tanto en estructura (diagramas de componentes, estructura compuesta, implementación, de objetos, de paquetes) como en comportamiento (diagramas de actividades, comunicación, de secuencia, máquina de estado y de casos de uso). Puede servir para modelar algunos sistemas no software también.
  20. C4 Model (for Software Architecture): El modelo C4 es una técnica de notación gráfica ajustada para modelar la arquitectura de los sistemas de software donde se modelan: context, containers, components y el code. Se basa en una descomposición estructural de un sistema en contenedores y componentes y se basa en técnicas de modelado existentes, como el lenguaje de modelado unificado (UML) o los diagramas de relación de entidad (ERD) para la descomposición más detallada de los bloques de construcción arquitectónicos.
  21. VSM: Value Stream Mapping o mapeo de flujo de material  información. Usado en análisis de procesos y sistemas.
  22. ASME: Diagramas de procesos Norma ASME.
  23. Cursograma: diagrama de ingeniería industrial.
  24. IDEF0: Método de Modelado Funcional IDEF0, diseñado para modelar las decisiones, acciones y actividades de una organización o sistema. Se deriva del lenguaje de modelado gráfico establecido Structured Analysis and Design Technique (SADT) desarrollado por Douglas T.Ross y SofTech, Inc.
  25. Organizadores Gráficos:
    1. VENN: Diagrama de Venn.
    2. Organigrama.
    3. Telaraña.
    4. Mapas conceptuales libres.


¿Qué profesionales suelen necesitar diagramar?


En general la facilitación la puede hacer cualquier persona o profesional que necesita facilitar el entendimiento de un dominio de realidad o analizar sistemas, procesos, comportamientos y estructuras. Por eso son los Agile Coaches o trainers quienes suelen facilitar gráficamente.
Aunque, generalmente, son los Arquitectos de Software (Arquitectos de Soluciones, Arquitectos de Infraestructura y Arquitectos de Big Data), los Modeladores de Datos, los Analistas de Negocio, los Analista Funcionales, Analistas de Procesos y Analistas de Sistemas, quienes profesionalmente se ven en la necesidad de modelar y diagramar.
Espero que te haya servido este post para incursionar en alguna manera de diagramar y facilitar gráficamente lo que deses.


Referencias: