¿Cómo medir la utilización humana?


15

En The Phoenix Project, el gráfico único en todo el libro muestra que a medida que la carga de trabajo de una persona aumenta al 90%, el tiempo de espera aumenta exponencialmente. De hecho, en el libro afirma que:

Tiempo de espera = (Porcentaje ocupado / Porcentaje libre)

Entonces, si un recurso está ocupado durante 35 de 40 horas por semana, entonces:

Wait Time = 0.875/0.125  = 8

Sin embargo, si un recurso está ocupado durante 39 de las 40 horas por semana, entonces:

Wait Time = 0.975/0.025  = 39

Esto se multiplica por el número de esperas en el flujo de trabajo. ¡Obviamente es algo que queremos vigilar!

Entonces, dado todo esto, es obviamente vital que mantengamos la utilización de las personas a un nivel razonable. Dada la insistencia del libro en la importancia de esta fórmula, ofrece pocos consejos prácticos sobre cómo medir estos valores. Mi pregunta es, ¿cómo puedes medir prácticamente el porcentaje de personas ocupadas?


2
Esto merece una respuesta que cita el libro Slack amazon.com/dp/0767907698 . El mito de la eficiencia al quemar recursos al 100% también es el tema principal en Teoría de las restricciones.
Evgeny

2
Antes de que tenga tiempo de escribir una respuesta completa, solo agregaré que en ToC abandonas las eficiencias en todas partes, para enfocarte en la eficiencia solo en la restricción. Porque eso permite que en cualquier otro lugar absorba variedad y evite generar desperdicio (cite Lean aquí. Como sobreproducción, demasiado inventario, etc.) ya que eso es actividades sin valor agregado (cite nuevamente Lean).
Evgeny

2
La restricción rara vez es humana, incluso en The Phoenix Project, Bret fue primero una restricción, pero su "trabajo" es la restricción real.
Evgeny

1
@Evgeny esperando la respuesta completa!
Liath

2
Una respuesta aquí también debería usar "No se puede medir la productividad" de Martin Fowler - martinfowler.com/bliki/CannotMeasureProductivity.html
David Bock

Respuestas:


6

TL; DR : No es correcto medirlo. Al medir y aumentar la utilización de los empleados en todos los ámbitos, crea problemas en el sistema y reduce el rendimiento general .

Contabilidad de rendimiento

Lo que realmente quiere medir es el rendimiento, el inventario y los gastos operativos, todos juntos e intente reducir el inventario y reducir los gastos operativos al mismo tiempo que maximiza el rendimiento. Este método se conoce como contabilidad de rendimiento .

En el desarrollo de software, el inventario es el trabajo en progreso que aún no brinda beneficios para el cliente. Todo lo que se haya hecho, pero no publicado. El rendimiento es la cantidad de trabajo útil para el cliente que se está lanzando. Cualquier trabajo realizado que no sea directamente útil para el cliente se contabiliza como gasto operativo.

Sistema simple

En un sistema simple con un solo humano o múltiples humanos trabajando independientemente con un equipo independiente tanto como cada uno aumentará directamente el rendimiento de todo el sistema . Esto lleva a la idea errónea común que es la base de esta pregunta de que aumentar la utilización humana conducirá a un mayor rendimiento en todos los sistemas. Pero aún mide el rendimiento del sistema, el inventario y los gastos operativos .

Sistema complejo

En un sistema complejo, incluso con tan solo dos dependencias, una mayor utilización de una parte del sistema puede conducir directamente a una disminución de la utilización en el cuello de botella, lo que disminuye el rendimiento de todo el sistema. Cualquier aumento en la productividad fuera del cuello de botella es un espejismo .

Ejemplo:El equipo de ingenieros de software tiene todo el código revisado por el arquitecto de software, que también hace planes para nuevas funciones. Esta persona es un cuello de botella, el código no revisado por el arquitecto simplemente aumentará el inventario, si el arquitecto no tiene tiempo, no se planificarán correctamente las nuevas características. Si comienza a medir la utilización de los ingenieros de software, cada uno intentará hacer más cambios, en lugar de mejores cambios. El tiempo que el arquitecto necesitará dedicar a cada cambio aumentará y el tiempo total dedicado a la revisión aumentará aún más por la mayor cantidad de cambios hasta un punto en el que no quedaría tiempo para planificar nuevos cambios. Finalmente, todo el sistema se detiene. Si, por otro lado, disminuyen la utilización, incluso pasan tiempo inactivo, pasan más tiempo en cada cambio o revisión por pares, Esto podría conducir a una disminución del tiempo requerido para las revisiones y eventualmente aumentar el rendimiento. Este es solo un equipo con 2 dependencias. Los ingenieros dependen del arquitecto para planear nuevos cambios y para revisar los cambios.

Claramente, los beneficios se obtienen al administrar adecuadamente el cuello de botella y tratar de ganar productividad en el cuello de botella , donde la hora ganada es la hora de rendimiento de todo el sistema .

Este es el verdadero mensaje de The Phoenix Project y proviene directamente de Theory of Restraints de Eliyahu M. Goldratt. También puede leer un artículo sobre pensamiento de utilización vs pensamiento de rendimiento . También sugeriría leer más sobre la gestión del proceso de cadena crítica .

Recuerde: lo que mide es lo que obtiene . Y definitivamente NO QUIERES obtener una mayor utilización individual. Un camino al infierno está pavimentado con buenas intenciones.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.