«Nuestros procesos son demasiado pesados, demasiado burocráticos», «Copiamos la misma información en varios sistemas, ya que se utiliza para diferentes informes», «Aplicar proceso definido es como tener una vida paralela del trabajo diario. Por tanto, creamos todo el papeleo antes de las auditorías «, «Necesitamos procesos más ligeros», etc, etc.
¿Te suena alguna de estas frases?
¿Cómo resolvéis el dilema de tener procesos que cumplen con un modelo o norma, y al mismo tiempo mantenerles operativos?
Estaría encantada de conocer tu experiencia. Mientras tanto voy a compartir la mía contigo.
Muchos consultores de mejora de procesos te dirán que implementar o mejorar CMMI, SPICE o ISO se hace proceso por el proceso, es decir, centrarse en un grupo particular de prácticas (actividades, procedimientos) y decidir cómo deberían hacerse o arreglarse según la norma. Implementar los cambios y entrar al siguiente proceso.
Yo también hacia así que hace años. Aunque esto no es tan malo, es una mejora local, parcial, que no necesariamente tiene que demostrar un mejoramiento positivo de todo el flujo de trabajo. De hecho, esta es una de las razones principales para cargar los procesos con demasiado trabajo extra.
Añadir un poco de trabajo extra a un único proceso no es un problema. Sin embargo, sumando el trabajo extra para todos los procesos se convierte en un obstáculo para realizar el trabajo bien y rápidamente.
Por lo tanto yo aplico un enfoque diferente, Lean.
Primero trato de entender el flujo de trabajo de principio a fin, tanto las actividades que producen valor como las de gestión de la información. Junto con el equipo de personas de la empresa, para cada grupo de actividades dibujamos un diagrama SIPOC que muestra los pasos a seguir (P), la entrada (I) necesaria para la ejecución de estos y el resultado (O) obtenido. Comprobamos que la entrada está disponible o bien de otro proceso o persona (S) y que el resultado es necesario para algún otro proceso o persona/ cliente (C).
Esto asegura que los procesos producen sólo resultados necesarios, es decir, no hay sobre-procesamiento.
Centrándose y realizando únicamente el trabajo que se requiere, ahorramos esfuerzo del personal, otros recursos y reducimos el tiempo de entrega. Además, esto lleva una mayor eficiencia dado que los empleados están enfocados en las tareas que añaden valor que el cliente necesita y está dispuesto a pagar por él. Asimismo, las personas no se sienten frustrados con el desarrollo de resultados obsoletos.
Otra comprobación importante es asegurarse de que todos los procesos que intervienen en el flujo de trabajo están perfectamente integrados, es decir, la entrada inicial fluye suavemente a través de ellos, transformándose poco a poco en un resultado final.
Mejorar el flujo de trabajo consiste en hacer los caminos de transformación más cortos (menos transportación y movimiento) y más rápidos (menos espera).
Por último, pero no menos importante, para asegurarse de que no producimos papel obsoleto, llenamos en la siguiente tabla que resume las entradas y los resultados para cada proceso. Sólo si un resultado es un documento en papel, incluimos el nombre de la plantilla correspondiente. La ubicación es el lugar o el sistema en que está almacenado el documento o los datos.
Lo que comprobamos a fondo en este punto es que no hay información duplicada entre los documentos y los sistemas utilizados. También, donde tiene sentido, fusionamos algunos documentos para evitar tener demasiados trozos de documentación repartidos en diferentes sitios. Indudablemente, la automatización siempre es útil.
Los indicadores útiles de si hemos logrado una mejora real son, por supuesto, (1) la opinión del equipo que utiliza los procesos y (2) el rendimiento del flujo de trabajo completo.
Por lo tanto yo los escucho atentamente a ellos dos.
¿Cómo lo ves? ¿Cuál es tu experiencia?
Con este post intento ayudar a Esteban, una persona real y concreta. Pero también creo que las ideas podrían ser útiles para otras personas en situaciones parecidas.
Esteban se dedica al desarrollo de software. Proyectos para distintos clientes, todos con sus peculiaridades, temas críticos y urgentes para resolver. Nada sorprendente para una persona del mundo TI. Lo interesante está en la situación en la que se encuentra Esteban:
Lleva 5 proyectos y participa en otros 8 como Responsable Técnico del diseño de las soluciones
Todos los proyectos utilizan tecnologías nuevas en el dominio TI y también nuevas para las personas de sus equipos
Además de hacer sus propias tareas, Esteban da formación en las nuevas tecnologías a las personas involucradas en los proyectos, les ayuda resolver las dudas en su trabajo, arregla los errores que ellos no pueden corregir, habla con los clientes para aclarar funcionalidades (tanto implementadas como nuevas o modificadas), etc.
En términos más concretos esto significa que cada día atiende a unos 20-25 compañeros, comentando asuntos muy diferentes, cuando surjan, sin ningún orden o agenda, y dedicando unos 10-15 min a cada uno esto le come unos 5-6 horas de su jornada laboral, … entre las conversaciones intenta re-tomar su trabajo…. hasta la próxima interrupción. El resultado es el siguiente:
el trabajo sin cerrar de Esteban se va acumulando
la cola de los quienes esperan sus respuestas está aumentando
el descontento por parte de los clientes está creciendo porque sus problemas se resuelven lentamente
el Jefe de Esteban está descontento también porque Esteban se ha convertido en un “cuello de botella” y no “compagina” bien las diversas tareas.
¿Te suena una situación como esta?
¿Qué harías tú para resolverla?
Yo veo tres opciones e intentaré explicarlas y demostrarlas aquí. Mira esta botella.
Contiene el trabajo que debe pasar por el cuello de la botella, es decir el que Esteban tiene que hacer.
La primera opción es “No hacer nada”, o sea dejar los compañeros se arreglen entre ellos, con o sin la ayuda del Jefe y simplemente empujando fuertemente para que trabajo pase lo más rápido posible por el cuello de botella.En este caso se ha tardado unos 11:07 segundos en vaciar la botella (terminar el trabajo). Se ven las burbujas de aire que entran y que facilitan la salida del agua, pero también hacen que el flujo pare para que entre el aire y luego vuelva a fluir.
La segunda opción es de poner un poco de orden, por ejemplo, definir un periodo de tiempo en el día en el que Esteban se dedique a la resolución de las dudas de sus compañeros, establecer algunas reglas sobre qué tipos de preguntas se van a dirigir a Esteban y cómo tratar los asuntos verdaderamente urgentes que no pueden esperar hasta la hora de preguntas.Visualicemos esta opción:El agua circula dentro de la botella y esto representa el orden que ayuda que el trabajo pase más rápidamente por el cuello de botella.El cronometro también muestra una mejora. El agua tarda 7:93 segundos en salir de la botella. Unos 28% de reducción del tiempo de entrega comparando con el caso anterior.
La tercera opción es la siguiente (la demostramos primero)
¡La misma cantidad de trabajo pasa por el mismo cuello de botella en sólo 5:60 segundos! Otros 29% de reducción del tiempo, o un 49% más rápido comparando con el primer caso.
¿Cómo es posible?
El aire que entra por la pajita hace que el flujo del agua es más suave y uniforme, sin paradas y re-arranques (causadas por las burbujas de aire, como en la primera opción).
En el caso de Esteban ¿qué sería equivalente al aire que entra por la pajita?
Bueno, la respuesta de esta pregunta se puede encontrar únicamente con las personas directamente involucradas en la situación. Lo que yo puedo sugerir es lo siguiente:
Que visualicen el trabajo en curso en los proyectos para que todos los involucrados puedan hablar, priorizar y llegar a acuerdos sobre qué hay que hacer para que haya un flujo constante de resultados. ¡No que cada uno esté ocupado, sino que se vayan desarrollando resultados que aporten valor a los clientes!
El cuello de botella es un recurso valioso y en el mismo tiempo limita el flujo del agua. Por eso lo tenemos que utilizar inteligentemente, no desperdiciarlo. Es decir, que Esteban se dedique siempre a las tareas que requieran sus conocimientos y no pierda tiempo en otras que solo ralentizan el flujo de trabajo.
Buscar formas de hacer el cuello de botella más ancho, poco a poco haciendo que otras personas ayuden en los trabajos específicos. (esto requiere más tiempo y esfurzo)
Variaciónes «el acto, proceso o resultado de variar» o «un cambio en la forma, posición, condición, o la cantidad de algo.» [Diccionario Merriam-Webster]
La variación es inherente a cualquier proceso. Cada día tardamos un tiempo diferente en ir a trabajar todos a pesar de que vamos por el mismo camino, y aproximadamente a la misma hora. La preparación de un informe habitual también toma tiempo diferente cada vez que lo hacemos. Dos desarrolladores a los que hemos pedido que implementen la misma funcionalidad sencilla y en el mismo entorno necesitarán tiempo diferente también.
La variación en nuestro rendimiento afecta el tiempo de finalización de los proyectos o los servicios, la calidad de los resultados, la organización interna de las actividades de un equipo, la carga de trabajo de las personas, etc. Estoy segura de que puedes añadir mucho más ejemplos a esta lista.
Es importante reconocer la naturaleza de la variación para poder abordarla correctamente.
Causas de variación
Las causas de la variación pueden ser diferentes:
Recursos: un error en una aplicación podría causar que un procedimiento rutinario tome más tiempo de lo habitual; los diferentes niveles de capacidad personal hacen que el tiempo de prestación de servicios varíe; pasar una tarea a otra persona suele alterar el tiempo y la calidad de la terminación del trabajo.
Unidad de procesamiento: la complejidad de una petición del cliente afecta al tiempo de desarrollo / respuesta; diferentes herramientas necesitan diferentes tiempos de instalación y configuración; diferentes defectos requieren diferentes tiempos y esfuerzo de corrección en función de sus características.
Otros factores: errores en el envío telemático de las declaraciones de renta ocurren en la ‘temporada’ de hacer las declaraciones de renta; la mayoría de las llamadas de soporte acerca impresoras se producen durante el horario de trabajo; un cambio o una falta de disponibilidad de un miembro del equipo afecta al rendimiento del equipo; el retraso en recibir alguna información o material afecta a la prestación del servicio; la tasa de llegada de llamadas telefónicas / incidentes impacta la calidad de la respuesta y la satisfacción del cliente.
Las personas, independientemente de si están implicadas en un proceso como una unidad de procesamiento (por ejemplo, paciente o cliente) o como un recurso – actor, introducen una variación natural en el proceso , que es prácticamente imposible de evitar.
En el ámbito de los servicios el tiempo de respuesta y la previsibilidad son la clave para la satisfacción del cliente. Por lo tanto, es importante mantener la variación del proceso relativamente bajo e incluso reducirla para ser más competitivo.
Hablando de plazo de entrega, es interesante que el tiempo de espera suele ser el componente más grande del tiempo completo del servicio. Por ejemplo en un viaje desde Yerevan a Bilbao los vuelos toman sólo 52% del tiempo total del viaje, el resto es espera; en una visita al médico el tiempo de valor añadido es de unos 15 min ( la consulta en sí) dentro de unas 6 horas, digamos, entre pedir la cita y salir de la consulta, es decir un 96 % del tiempo es espera .
Haz un experimento tú mismo. Mide el tiempo efectivo de hacer algo (el tiempo que realmente trabajas en este), por ejemplo, corregir un error. Y mide el tiempo complete entre empezar y terminarlo. ¿Cuál es la relación entre las dos medidas?
Para comprender los efectos de la variación y cómo hacerse con ellos, echemos un vistazo a la siguiente imagen simplificada de tu organización:
Fig. 1 Sistema de colas (simplificado)
En este caso, representamos a tu organización como un sistema de colas: «los clientes llegan para un servicio determinado, esperan si el servicio no se puede iniciar de inmediato y se van después de ser servidos» o «el cliente pide la aplicación de un requisito, espera a que empiece su implementación y paga cuando se le entregue el requisito»
La fórmula de Sir John Kingman vincula los factores que determinan el tiempo que un cliente tendrá que esperar hasta que se procese su solicitud. Por eso a veces se llama la ley de los efectos de la variación. Dice lo siguiente:
Promedio de tiempo de espera = f (Variación de la llegada,
Utilización de los recursos, Tiempo efectivo del proceso)
Más precisamente, para un sistema de colas sencillo el tiempo medio de espera en la cola, depende de la variación en la llegada de peticiones, la utilización de recursos, y el tiempo de procesamiento de una petición.
Fig2. Dependencias entre el Tiempo de espera, la Utilización de recursos y la Variación de llegada
Efectos de la variación
Los dos efectos de la variación se pueden describir de la siguiente forma:
Mirando una curva sólo: Cuando la utilización de los recursos está cerca al 100 % un pequeño aumento en la carga de trabajo provoca un aumento exponencial del tiempo de terminación del trabajo.
Mirando dos curvas: Suponiendo que la utilización de los recursos es el la misma, cuanto mayor es la variación del proceso, más tiempo se tarda en completar un trabajo.
Lecciones prácticas para un gerente de proyecto o servicio
Cuanto mayor sea la utilización de los recursos, tanto más fuerte impacta la variación el tiempo de completar un servicio o un trabajo. Si la utilización es baja (~ 50 % o menos) , la variación en la llegada de peticiones tendrá un pequeño impacto en el rendimiento. Algo muy importante para las organizaciones enfocadas en asegurar que sus recursos estén siempre ocupados.
En el desarrollo de software y los servicios TI las personas son el recurso principal. Por eso la utilización es fuertemente afectada por los errores que generan la demanda artificial o re-trabajo. Por lo tanto, la reducción de la utilización de recursos es más importante que la reducción de la variación del tiempo.
Cuanto mayor sea el tiempo promedio del proceso, tanto más tiempo las peticiones estarán en espera y, a consecuencia, tanto más larga será la cola . Por lo tanto, la descomposición de un trabajo en partes más pequeñas que requieren menos tiempo para completarse, reduce el tiempo de procesamiento global. El desarrollo de varios servicios / tareas pequeños produce una menor variación que un desarrollo grande.
Dicho esto cómo reducir el tiempo de espera de una petición?
Reducción de la tasa de llegada incidentes/peticiones, por ejemplo mediante la mejora de la documentación del usuario, proporcionando un mejor soporte basado en la web, haciendo la interfaz de usuario más intuitiva, proporcionando formación, etc
Reduciendo el tiempo de servicio ( tiempo de procesamiento efectivo) mejorando la formación del personal técnico, la automatización del proceso , etc
Reduciendo la variabilidad del proceso mediante el análisis de los servicios de duración muy larga y la eliminación de las causas para esto, la introducción de políticas que faciliten la priorización y la ejecución de los servicios.
Cuanto más suave pase una petición a través del proceso (con menos paradas, re-arranques y los cuellos de botella), más corto es el tiempo de proceso y por lo tanto el tiempo de espera y la longitud de la cola . Por eso la eliminación de los cuellos de botella y otros impedimentos en el flujo de trabajo reduce el tiempo de espera así como y el tiempo total de procesamiento.
La reutilización reduce la variabilidad en el tiempo de finalización de un trabajo. Por lo tanto, siempre que sea posible y tiene sentido ha de reutilizar conocimientos y resultados de trabajo. He dicho «tiene sentido». Hace tiempo estaba trabajando con una empresa que admitía que estaban sufriendo el virus HAS (Hasta Agotar el Stock). Reutilizaban componentes de hardware antiguos hasta agotar el stock y esto les causaba un alto coste de corrección de defectos.
La variabilidad no necesariamente es mala. Lograr una alta previsibilidad y nivel de servicio es importante, sin embargo repetir siempre los mismos resultados también significa que no se crea nada nuevo. No es por casualidad que Henry Ford dijo:
» Si hubiera preguntado a la gente qué querían, me habrían dicho caballos más rápidos.»
Si Apple sólo estaban haciendo su trabajo habitual, tampoco habrían llegado al iPhone.
Más sobre el lado positivo de la variabilidad vendrá en otro post.
La ley del cuello de botella tiene su origen en la Teoría de las Limitaciones, creada por Dr Eliyahu Goldratt y publicada en el año 1984 en su libro “La meta”.
La ley dice que cada sistema, independientemente de cuánto de bien funciona, tiene por lo menos una restricción (un cuello de botella) que limita su rendimiento.
La ley permite deducir el tiempo de respuesta y los límites de rendimiento de un proceso – una información imprescindible para los servicios TI y los proyectos de desarrollos de software.
Centrar los esfuerzos de mejora en resolver el cuello de botella es el camino más rápido y más eficaz para la mejora de la rentabilidad.
Los cuellos de botella pueden involucrar personas, información, herramientas, procedimientos y pueden ser internos o externos para la organización.
El cuello de botella es la fase en el proceso en forma de sub-procesos o actividades individuales que limitan o bloquean el flujo. En el cuello de botella el rendimiento es más bajo. O bien, es la fase en la que una unidad de trabajo tarda más tiempo entre entrar y salir de la fase – el Lead time de esta fase es más largo.
Por ejemplo, miremos el proceso de “lavar la ropa – secarla – doblarla”.
El cuello de botella es la secadora porque en esta fase del proceso completo el Lead time es más grande.
Los procesos involucran distintas personas, actividades y herramientas y cada uno de estos tiene un rendimiento distinto. Por lo tanto, si las actividades de un proceso se deben ejecutar en un orden secuencial, por ejemplo lavar-secar-doblar registración para el vuelo – control de equipaje – embarque al avión tomar requisitos – análisis-diseño-implementación – pruebas – entrega,
siempre habrá un cuello de botella en el proceso completo, especialmente si las fronteras del sistema están establecidas relativamente ancho.
¿Cómo resolver un cuello de botella?
En el libro «Kanban: Successful Evolutionary Change for Your Technology» de David Anderson puedes leer en más detalles cómo resolver un cuello de botella en función de si está causado por una limitación en la capacidad o en la disponibilidad del recurso.
Aquí voy a resumir los métodos de resolución de un cuello de botella:
Utilizar lo máximo del recurso: hacer que el recurso se dedique sólo a las actividades propias de este y asignar el resto de las actividades a otros recursos
Por ejemplo, disponemos de un especialista en integración de software y debido a su participación en varios proyectos se convierte en un cuello de botella. Una opción será dejarle que se dedique explícitamente a las tareas de integración y asignar sus tareas de otro tipo a otros miembros del equipo.
Aumentar la disponibilidad del recurso – la frecuencia con la que el recurso está disponible aunque sea para un tiempo más corto.
Ejemplo: El especialista en integración puede dedicar un día a la semana a cada proyecto. Una solución más eficiente es que la persona dedique a cada proyecto media jornada dos veces a la semana, en lugar de una jornada completa sólo un día a la semana.
Automatizar parte de las actividades.
Aumentar el recurso – suele ser la solución más cara.
Siguiendo el ejemplo de antes esto es equivalente a contratar a otra persona con los conocimientos y la experiencia necesaria en integración de software.
El origen de la ley de Little es la Teoría de las Colas. Es quizás la ley más conocida en el modelado del rendimiento de los sistemas TI.
La ley demuestra las relaciones entre el Lead Time, el Trabajo en curso (WIP) y el Rendimiento (Throughput).
El Lead time: El período entre la entrada de un petición en el sistema (petición solicitada) y la recepción de la petición. Se mide por el tiempo transcurrido (minutos, horas, etc). La petición puede ser un requisito, una historia de usuario, una incidencia, material, una solicitud de un usuario, etc.
Trabajo en curso (WIP – Work In Process): el número de peticiones (unidades de trabajo) que se están procesando, es decir las que han entrado en el sistema, pero todavía no han salido.
Rendimiento(Throughput): el número de unidades de trabajo que salen del sistema en un tiempo determinado, p.ej., 3 historias de usuario por día.
Las conclusiones de esta ley son igual de interesantes e importantes:
Cuanto más grande es el WIP, más largo es el Lead time, es decir más tardamos en terminar el trabajo empezado. Dicho de otra manera, para cumplir los plazos de desarrollo o de los servicios, hay que reducir el trabajo en curso, o sea procurar de cerrar trabajos antes de abrir nuevos.
Sin embargo, en muchas ocasiones ocurre justo lo contrario: los equipos empiezan a trabajar sobre muchas tareas para que así el proyecto entero “avance” más rápidamente. Otra razón por la que se busca asegurar mucho trabajo en curso es conseguir una alta utilización de los recursos.
Independientemente del motivo, suponiendo que el rendimiento no cambia, el aumento del trabajo en curso aumenta también el tiempo necesario para su realización. Aunque parezca contra intuitivo, recuerda que reducir el trabajo en curso ayuda a cumplir los ANS y reducir los tiempos de desarrollo.
Enfocándose en reducir el Lead time ayuda identificar las actividades obsoletas que se están llevando a cabo. Eliminándolas tiene dos efectos positivos: (1) se eliminan desperdicios en los procesos, (2) se reduce el trabajo el curso total que resulta en un ciclo de desarrollo más corto y más eficiente.
Cuanto mayor es el Rendimiento, tanto más corto es el Lead time.
Existen diferentes formas de mejorar el rendimiento: automatizando las actividades de valor (automatizar actividades que no aportan valor es equivalente a automatizar la producción de desperdicios), mejorando los procesos o añadiendo más recursos. Si decides añadir más recursos, observa el Lead time porque en general los recursos adicionales añaden más trabajo en curso.
Cada iniciativa Lean procura de minimizar los desperdicios y de reducir los ciclos de producción. Reduciendo el ciclo de producción es equivalente a reducir el Lead time. Minimizar los desperdicios incluye un análisis del inventario actual y los pasos para reducirlos. Esto es equivalente a la reducción del WIP.
¿Por qué esta ley es importante para los Jefes de proyectos?
La ley de Little es una herramienta de conocer el rendimiento real de un equipo de operaciones o de desarrollo de software
Proporciona previsibilidaden el proceso.
P.ej., si tenemos que implementar 50 requisitos y la capacidad del equipo es de unos 5 requisitos por semana, el tiempo que necesitaremos es
50 requisitos/5 requisitos por semana = 10 semanas.
Demuestra que cuanto más grandes son los batches de trabajo, tanto más largo es el tiempo de su procesamiento, el Lead time.
Explicapor quélas multi-tareas retrasan en lugarde acelerarla terminaciónde trabajo.
Habitualmente las personas creen que trabajar sobre varias tareas en paralelo aumenta la productividad. Por eso asignar unas cuantas tareas a una persona es una práctica común en las empresas. Sin embargo, a diferencia de las máquinas, las personas no son tan buenas en la ejecución de procesos paralelos. Aumentando el Trabajo en curso aumenta también en tiempo de cambiar y re-tomar las tareas y por lo tanto reduce el Rendimiento. A consecuencia, el tiempo para ejecutar el proyecto resulta insuficiente, el trabajo empezado y no terminado empieza a acumularse.
En breve, la ley de Little ayuda a encontrar el punto de equilibrio entre el Trabajo en curso y el Lead time.
Proporciona los fundamentos para llegar a los óptimos límites de WIP. Si los límites de WIP están por debajo del nivel óptimo, hay recursos infrautilizados y el rendimiento es bajo. Si los límites WIP superan el nivel óptimo, entonces las unidades de trabajo empiezan a montar colas y el rendimiento baja.
Ayuda entender qué efectos tendrá sobre los plazos del proyecto o el servicio el bloquear un trabajo o tener que corregir errores. En ambos casos baja el rendimiento y de ahí aumenta el Lead time.
Condiciones importantes para que funcione la ley de Little
La ley de Little es muy útil, pero además de conocer la formula tienes que tener en cuenta las condiciones necesarias que se deben cumplir para que la ley de Little te sirva:
Se cogen valores medios de todos los parámetros: promedio del Lead time, promedio del trabajo en curso, y promedio del rendimiento
Las unidades deben ser coherentes, p.ej. si medimos el rendimiento en una semana, el lead time también tiene que ser en semana, así como el promedio del trabajo en curso
El sistema tiene que estar estable, es decir todo el trabajo que entra en el sistema, sale de este, el WIP total al inicio y al final del periodo es constante, la tasa media de llegada de trabajo es igual a la tasa media de salida de trabajo del sistema.
Para resumir, el uso correcto de la ley de Little ayuda conseguir un flujo de trabajo suave y estable, y a mejorar la previsibilidad de los proyectos y los servicios TI. El Trabajo en curso (WIP) es un factor clave para el rendimiento y el tiempo necesario para el desarrollo de software y/o la ejecución de los servicios. Limitar el trabajo en curso además de reducir el Lead time lleva a una reducción de los desperdicios en el flujo de trabajo.
Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos. Contiene enlaces a sitios web de terceros con políticas de privacidad ajenas que podrás aceptar o no cuando accedas a ellos. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos.
Más información
