002. Agile y TOC contra el caos operativo
Introducción de la página
¿Es posible que una empresa cuente con equipos técnicos 'ágiles' pero que, como organización, siga siendo desesperadamente lenta? En este segundo episodio, nos sumergimos en una de las paradojas más comunes y frustrantes de los servicios IT modernos: la coexistencia de metodologías ágiles a nivel de equipo con estructuras burocráticas a nivel corporativo.
Basándonos en el libro “Cómo transformar empresas de servicios con Agile, Scrum y TOC” de José Manuel Hernández Agudo, desglosamos cómo el Manifiesto Ágil y la Teoría de las Restricciones (TOC) ofrecen un marco de pensamiento superior para identificar no solo dónde falla el código, sino dónde falla el sistema. El autor, con su enfoque pragmático nacido de décadas de liderazgo real, nos enseña que la eficiencia local de un departamento puede ser el mayor enemigo de la fluidez global de la compañía.
Acompaña a José Manuel en este viaje donde aprenderemos a detectar los muros invisibles de la burocracia, a entender el desplazamiento de los cuellos de botella y a aplicar una cultura de mejora continua que no se detenga en las puertas del departamento técnico. Es hora de dejar de 'hacer Agile' para empezar a 'ser' una organización fluida y resiliente.
Escucha el episodio
Te invitamos a escuchar este análisis profundo sobre la eliminación del caos operativo. Un contenido esencial para responsables de servicio, líderes de equipo y directores de IT que buscan resultados reales.
https://www.ivoox.com/002-menos-burocracia-mas-flujo-agile-y-audios-mp3_rf_169722349_1.html
Resumen ejecutivo del episodio
El episodio 002 se centra en la intersección crítica entre la agilidad organizacional y la gestión de restricciones. El punto de partida es la revisión del Manifiesto Ágil, no como un conjunto de rituales (reuniones, post-its), sino como un cambio profundo de valores que prioriza a los individuos y la entrega de valor real sobre los procesos rígidos.
Puntos clave analizados:
• La Agilidad más allá de IT: Se explora el concepto de 'Agilidad Organizacional'. No sirve de nada que un equipo de desarrollo entregue en dos semanas si el proceso de contratación o de compras tarda tres meses.
• La Teoría de las Restricciones (TOC) en la Operativa: Se explica cómo identificar el cuello de botella actual del sistema. El episodio advierte sobre la 'Paradoja del Éxito Operativo': al optimizar el departamento técnico, el cuello de botella suele desplazarse hacia áreas de soporte como Finanzas, Legal o Recursos Humanos.
• Reducción del Desperdicio: Se analiza cómo la burocracia genera 'trabajo innecesario'. La simplicidad operativa consiste en maximizar el trabajo no realizado para que el equipo pueda centrarse en lo que el cliente realmente valora.
• Liderazgo Facilitador: El papel del líder cambia. Su misión principal deja de ser el control detallado para convertirse en la eliminación sistemática de los bloqueos que impiden el flujo de valor.
Qué aprenderás en este episodio
A aplicar los 4 pilares del Manifiesto Ágil en entornos de servicios de alta complejidad.
La importancia de la optimización global frente a la optimización local: por qué un departamento 'perfecto' puede hundir a la empresa.
Herramientas para detectar el desplazamiento del cuello de botella hacia departamentos no técnicos.
Estrategias para negociar la colaboración con el cliente por encima de la rigidez de los contratos.
Cómo reducir el WIP (Work In Progress) para acortar el tiempo de entrega y mejorar la calidad del servicio.
Ideas clave del episodio
'La agilidad organizacional es la capacidad de mover a toda la empresa al ritmo del cliente'.
'Un proceso que no añade valor es burocracia; un proceso que bloquea el valor es un peligro'.
'El éxito de IT puede ser el fracaso de Finanzas si no hay alineación estratégica'.
'En servicios, las personas resuelven los problemas que los procesos no prevén'.
'TOC te da el foco; Agile te da la velocidad de adaptación'.
'El líder operativo es un barrendero de obstáculos, no un capataz de tareas'.
'No empieces más cosas, termina lo que tienes entre manos'.
'La simplicidad es la máxima sofisticación en la gestión de servicios IT'.
Desarrollo didáctico del contenido
Este episodio profundiza en la transición del pensamiento tradicional al pensamiento sistémico. Se divide en tres grandes ejes formativos:
El Manifiesto Ágil como Guía Ética y Operativa
Se diseccionan los valores fundamentales aplicados a servicios IT. Por ejemplo, 'Individuos e interacciones sobre procesos y herramientas' se explica no como una falta de orden, sino como la comprensión de que en IT los problemas son cognitivos y requieren comunicación humana fluida, no solo tickets en una plataforma. Se enfatiza que un 'Software que funciona' (o un servicio que resuelve) es la única métrica de progreso real.
La Teoría de las Restricciones (TOC) y el Flujo de Valor
Se utiliza la analogía de la tubería: el flujo total está determinado por la sección más estrecha. El episodio enseña que si ensanchamos la tubería en IT (Agile/Scrum), el agua simplemente se acumulará con más presión frente a la siguiente estrechez (Burocracia corporativa). Se explica el proceso de 5 pasos de TOC: Identificar, Explotar, Subordinar, Elevar y Repetir.
Gestión de la Incertidumbre (VUCA y BANI)
Se conecta el contenido con el marco BANI. En un entorno incomprensible y no lineal, la única defensa es la agilidad. Se explica cómo los ciclos cortos de feedback permiten a la empresa 'aprender' del servicio mientras lo ejecuta, reduciendo el riesgo de grandes fallos sistémicos.
Relación con el libro “Cómo transformar empresas de servicios con Agile, Scrum y TOC”
Este episodio desarrolla específicamente el capítulo sobre el Manifiesto Ágil y la implementación de TOC en la estructura de servicios que José Manuel Hernández Agudo detalla en su obra. El autor utiliza este contenido para aterrizar la teoría del libro a casos de 'trinchera', demostrando que las restricciones más difíciles de romper no son las de presupuesto, sino las culturales y políticas dentro de la propia organización.
Aplicación práctica en empresas de servicios IT
- Gestión de Incidencias: Cómo evitar que el 'ping-pong' entre departamentos N1, N2 y N3 se convierta en un cuello de botella burocrático.
- Soporte Técnico: Implementación de reuniones diarias de flujo (no de estatus) para detectar bloqueos inmediatos.
- SLA y Contratos: Cómo diseñar acuerdos de nivel de servicio que incentiven la resolución real en lugar de la manipulación de métricas.
- Liderazgo Operativo: Ejercicios para que los mandos intermedios identifiquen sus propias tareas 'tapón' y deleguen autoridad para liberar el flujo.
Transcripción
00:00:00 Marta
Bienvenidos a una nueva exploración en profundidad sobre la mesa.
00:00:04 Marta
Hoy tenemos un material sumamente interesante.
00:00:08 JM
Hola, encantado de estar aquí para diseccionar todo esto.
00:00:11 Marta
Igualmente, bueno, a ver, se trata del libro Cómo transformar empresas de servicios con Agile, Scrum y TOC, que está escrito por José Manuel Hernández Agudo.
00:00:22 Marta
Además, vamos a integrar en este análisis varios anexos prácticos del autor que son conocidos como los bonus tracks.
00:00:29 Marta
Y también los principios fundamentales del manifiesto ágil.
00:00:33 JM
Es una combinación de fuentes muy potente, la verdad.
00:00:36 Marta
Lo es, pero hay que dejar algo muy claro desde el principio.
00:00:40 Marta
La misión de la sesión de hoy no es recitar teoría académica ni hacer un resumen de manual aburrido.
00:00:46 Marta
El objetivo es diseccionar un problema real, diario y, bueno, para ser sinceras, bastante doloroso que este marco de trabajo intenta resolver en el complicado mundo de los servicios.
00:00:57 JM
Haití, claro.
00:00:59 JM
Ese enfoque es absolutamente necesario, o sea, en el sector de los servicios tecnológicos y el trabajo del conocimiento.
00:01:06 JM
La teoría limpia de los libros choca constantemente contra la cruda realidad de las operaciones diarias.
00:01:12 Marta
Totalmente.
00:01:13 Marta
Para visualizar esa realidad, es muy fácil pintar un escenario que resultará tremendamente familiar para quienes lideran equipos o gestionan departamentos de servicio hoy en día.
00:01:23 JM
Sí, esa imagen típica del caos.
00:01:26 Marta
Exacto.
00:01:26 Marta
Imaginemos un equipo de soporte técnico de nivel 2 o un departamento de desarrollo de software.
00:01:32 Marta
Los ordenadores echan humo, hay una montaña de tickets acumulados, ese trabajo en curso que parece no tener fin y que además crece cada hora.
00:01:40 JM
Y las urgencias, claro.
00:01:41 Marta
Sí, las prioridades cambian a las 9:00 de la mañana, vuelven a cambiar después de comer y existe esa sensación constante, verdaderamente agotadora, de estar simplemente apagando fuegos.
00:01:52 JM
Es estar en la rueda de hámster.
00:01:54 Marta
Eso es, se corre de una urgencia a otra, sin un solo segundo de margen para respirar, planificar o hacer las cosas bien.
00:02:02 Marta
Es el caos absoluto convertido en rutina.
00:02:05 JM
Fíjate que esa imagen describe con total precisión lo que en el texto de Hernández Agudo se denomina la trampa de la reacción constante.
00:02:13 Marta
Reacción constante.
00:02:15 JM
Sí, cuando un departamento llega a ese punto de saturación.
00:02:19 JM
El instinto natural, que es casi un reflejo de supervivencia corporativa, suele ser intentar trabajar más duro.
00:02:25 Marta
Trabajar más horas, pedir un esfuerzo extra a la plantilla.
00:02:29 JM
Exactamente, se piden horas extra al equipo, se presiona para cerrar más incidencias por hora o, y esto es muy clásico, la alta dirección decide que la solución es imponer más normas, más burocracia, más procedimientos de control y más burocracia para intentar gobernar el desorden.
00:02:46 JM
Sin embargo,
00:02:47 JM
El argumento central que se extrae de estos materiales plantea un cambio de paradigma radical.
00:02:52 Marta
Que trabajar más duro no significa avanzar mejor.
00:02:55 JM
Efectivamente, el problema que sufren estos equipos no es únicamente de capacidad operativa, es un problema fundamental de enfoque.
00:03:02 Marta
Es decir, que intentar solucionar el caos simplemente corriendo más rápido en esa rueda de hámster no lleva a ninguna parte.
00:03:09 Marta
La rueda gira más deprisa, pero el equipo sigue en el mismo sitio, cada vez más cansado.
00:03:15 JM
Totalmente de acuerdo.
00:03:16 Marta
Para entender por qué tantas empresas de servicios viven atrapadas en esta inercia, el material adicional del autor hace un diagnóstico del entorno que resulta muy revelador.
00:03:26 Marta
Para dejar de culpar exclusivamente a la supuesta mala gestión interna, se introducen 2 acrónimos que explican el contexto en el que operan.
00:03:33 JM
Los servicios hoy en día, los famosos entornos VUCA y BANI, esos mimos.
00:03:39 Marta
A ver, comprender esos 2 conceptos es el paso previo a cualquier intento de transformación.
00:03:45 Marta
VUCA describe un entorno volátil, incierto, complejo y ambiguo.
00:03:50 Marta
Es un marco que viene del ámbito militar originalmente, pero que encaja perfectamente en la tecnología.
00:03:56 JM
Como anillo al dedo, sí.
00:03:58 Marta
Y luego tenemos Vani, que da un paso más allá y añade una dimensión que afecta directamente al estado de ánimo de los equipos.
00:04:05 Marta
Define un entorno frágil, ansioso, no lineal e incomprensible.
00:04:10 JM
Ansioso, esa es la palabra clave, claro.
00:04:13 Marta
No se puede transformar un servicio de atención o un equipo de desarrollo si antes no se asume que el terreno sobre el que se pisa se mueve constantemente.
00:04:21 JM
Vamos a aterrizar esos conceptos con situaciones cotidianas, porque es que ocurren todos los días en cualquier oficina técnica.
00:04:28 Marta
Adelante, pon un ejemplo, mira, un entorno volátil e incierto es ese cliente que cambia de opinión y redefine por completo los requisitos de un proyecto de software cuando el código ya estaba.
00:04:40 Marta
Teóricamente cerrado y a punto de entregarse.
00:04:42 JM
Un clásico absoluto.
00:04:44 Marta
O un entorno frágil y no lineal que se manifiesta cuando un pequeño parche de actualización en un servidor secundario tumba, como si fuera una ficha de dominó, toda la pasarela de pagos y.
00:04:56 JM
Deja a la empresa sin facturar durante horas.
00:04:58 Marta
Exacto.
00:04:59 Marta
El pánico o la incomprensibilidad y ambigüedad, que puede ser simplemente una instrucción técnica mal redactada en un correo electrónico por parte de un gerente
00:05:09 Marta
que se malinterpreta y desata el caos en el equipo de guardia de fin de semana Todo esto genera esa ansiedad operativa crónica que menciona el modelo BANI.
00:05:18 JM
Y claro, frente a este nivel de inestabilidad es imperativo reconocer los síntomas de que un sistema está intentando defenderse de manera equivocada.
00:05:26 Marta
Porque lo intentan, claro, pero mal.
00:05:29 JM
Exacto Una señal de alarma inconfundible es lo que se conoce como la mejora continua que no mejora nada.
00:05:36 Marta
¡Qué buena frase.
00:05:37 JM
Es un patrón destructivo pero muy común.
00:05:40 JM
Ante la pérdida de control, la dirección decide implementar nuevos formularios obligatorios.
00:05:45 JM
Añade métricas interminables sobre tiempos de respuesta y convoca, no sé, tres reuniones de seguimiento semanales adicionales.
00:05:53 Marta
Que al final solo quitan tiempo de trabajar.
00:05:56 JM
100% Se invierte una energía inmensa en intentar someter el caos mediante la rigidez o la microgestión.
00:06:02 JM
El resultado final de esta estrategia es que el equipo sigue igual de saturado.
00:06:06 JM
Las incidencias siguen acumulando retrasos y, lo que es peor, la moral de los profesionales cae en picado.
00:06:12 Marta
Porque sientan que están sepultados bajo procesos que no aportan ningún valor real al usuario final.
00:06:18 JM
Exactamente eso.
00:06:19 Marta
La comprusión de ese punto es que intentar ponerle puertas al campo solo genera más frustración.
00:06:26 Marta
La ansiedad operativa devora a los profesionales cuando el entorno es un torbellino y la organización no proporciona un marco de trabajo estable que permita digerir esa incertidumbre.
00:06:35 JM
Es que añadir control y rigidez a un entorno que es inherentemente caótico no funciona.
00:06:41 Marta
Entonces, si añadir más control no funciona, ¿qué camino queda?
00:06:45 Marta
Aquí es donde entra en juegos una herramienta conceptual muy potente de la que habla el libro.
00:06:49 JM
La teoría de las restricciones.
00:06:51 Marta
Eso es, conocida como TOC por sus siglas en inglés y desarrollado originalmente por el Yahoo M Golrat.
00:06:58 Marta
Tradicionalmente, cuando se menciona un cuello de botella, la mente viaja a una fábrica de los años 80.
00:07:03 JM
Sí, a una máquina ensambladora de coches o algo así.
00:07:06 Marta
Exacto.
00:07:07 Marta
Una máquina que va más lenta que el resto de la cadena de montaje.
00:07:11 Marta
Pero la verdadera innovación de este enfoque es trasladar esa lógica de la fábrica directamente a los servicios IT y al trabajo del conocimiento.
00:07:20 JM
Y fíjate que en el mundo del conocimiento puro, la aplicación de TOC revela realidades bastante incómodas.
00:07:27 JM
La mayor restricción de un flujo de trabajo
00:07:29 JM
verdadero cuello de botella que frena a toda la empresa.
00:07:32 JM
Rara vez es un servidor con poca memoria RAM o un software de gestión anticuado.
00:07:37 Marta
Suele ser algo mucho más humano.
00:07:39 JM
Exacto.
00:07:40 JM
La restricción suele tener nombre y apellidos, o al menos forma de comportamiento humano.
00:07:45 JM
Hablamos de elementos intangibles como el miedo al cambio ante una nueva directriz, una decisión presupuestaria que se retrasa durante semanas en la mesa de un director y paraliza a 10 desarrolladores.
00:07:56 Marta
O la clásica y perjudicial falta de comunicación entre departamentos que trabajan en silos estancos.
00:08:02 JM
Los famosos reinos de taifas corporativos.
00:08:05 Marta
Sí, el factor humano como el gran cuello de botella del sistema.
00:08:09 Marta
Hay un escenario clásico en el mantenimiento de sistemas que se menciona en los anexos y que ilustra esta fragilidad a la perfección.
00:08:17 Marta
El caso del héroe, sí, el empleado héroe.
00:08:20 Marta
Imaginemos un servicio de soporte técnico que de cara al cliente funciona de maravilla.
00:08:25 Marta
Los tiempos de respuesta son rápidos y el servicio parece muy robusto, pero hay una trampa oculta.
00:08:31 Marta
Todo ese éxito sostenido depende de una sola persona clave, el héroe del departamento.
00:08:36 Marta
Ese mismo, esta persona gestiona integraciones críticas mediante hojas de cálculo con macros que no están documentadas en ningún sitio y configuraciones de red que solo están en su cabeza.
00:08:48 Marta
Todo va bien hasta que un día de agosto.
00:08:51 Marta
héroe se marcha de vacaciones dos semanas a una cabaña aislada en la sierra.
00:08:55 JM
Sin cobertura ni wifi.
00:08:57 Marta
Exacto, y localizable.
00:08:59 Marta
De repente, una incidencia menor ocurre y al departamento entero entra en pánico absoluto porque nadie sabe cómo funciona esa macro.
00:09:09 Marta
El servicio literalmente colapsa.
00:09:12 JM
Ese escenario es la materialización de la fragilidad que mencionábamos en el entorno BANI, un sistema que aparenta ser sólido, pero
00:09:20 JM
pero que internamente está sostenido por un hilo invisible.
00:09:24 JM
Al analizar esta situación bajo la óptica de la teoría de las restricciones, emerge una lección innegable.
00:09:30 Marta
Que la fortaleza del sistema es igual a la de su eslabón más débil?
00:09:35 JM
Efectivamente.
00:09:36 JM
La fortaleza de cualquier sistema equivale única y exclusivamente a la capacidad de su eslabón más débil.
00:09:42 JM
Si la restricción del departamento es esa persona clave que atesora todo el conocimiento, la solución tradicional siempre se equivoca.
00:09:50 Marta
Se le suele dar todavía más trabajo?
00:09:52 JM
Se tiende a darle todavía más trabajo complejo a esa persona, precisamente porque es quien resuelve los problemas más rápido.
00:09:59 JM
La paradoja es que la solución real para estabilizar el sistema no es sobrecargar a ese héroe, sino protegerlo a toda costa.
00:10:06 Marta
Claro.
00:10:07 JM
El objetivo primordial debe ser extraer su conocimiento, documentarlo de forma colaborativa y eliminar esa dependencia crítica.
00:10:14 JM
Solo así el sistema deja de ser vulnerable.
00:10:17 Marta
Proteger el cuello de botella en lugar de ahogarlo con más peticiones.
00:10:20 Marta
Queda claro el diagnóstico.
00:10:22 Marta
Los equipos viven en un caos volátil.
00:10:24 Marta
Reaccionar con más rigidez no lo soluciona.
00:10:27 Marta
Y las verdaderas restricciones suelen ser bloqueos humanos o de conocimiento.
00:10:31 JM
La gran pregunta es cómo ejecutar la salida de este laberinto?
00:10:34 Marta
Exacto.
00:10:36 Marta
el material propone estructurar esta transformación integrando tres grandes pilares metodológicos: TOC, Agile y Scrum.
00:10:44 Marta
No compiten entre sí por ser la metodología dominante, sino que forman un sistema interconectado.
00:10:50 JM
Una especie de tridente de gestión.
00:10:52 Marta
Para visualizar cómo operan juntos estos tres elementos, el experto y autor usa una metáfora muy visual que nos ayuda mucho.
00:11:00 JM
La metáfora de la autopista.
00:11:02 Marta
Eso es.
00:11:02 Marta
Y
00:11:03 Marta
Imaginemos que el flujo de trabajo del departamento informático es una autopista de tres carriles muy transitada.
00:11:09 Marta
De repente, hay un atasco monumental.
00:11:12 Marta
Los coches están parados y la gente toca el claxon desesperada.
00:11:15 JM
Y allí entra TOC, la teoría de las restricciones.
00:11:19 JM
Es el helicóptero de tráfico que sobrevuela la zona y localiza exactamente qué camión volcado está bloqueando los carriles.
00:11:25 JM
Identifica el origen real del problema.
00:11:27 JM
el cuello de botella, evitando que nos centremos en los coches que tocan el claxon kilómetros más atrás.
00:11:33 Marta
Y luego está Agil.
00:11:35 JM
Por su parte, Agile proporciona la mentalidad de respuesta adecuada.
00:11:39 JM
En lugar de diseñar un plan de obras a cinco años para construir una nueva autopista para Leia, Aya insta a buscar la manera de aportar valor hoy mismo.
00:11:48 Marta
Adaptándose a la situación para lograr que al menos la gente llegue a casa de forma segura.
00:11:53 JM
Y finalmente, Scrum.
00:11:55 JM
el protocolo de emergencia estructurado.
00:11:58 JM
Marca los pasos exactos y el ritmo que seguirán los equipos de rescate para apartar el camión y reabrir los carriles de manera ordenada y metódica.
00:12:06 Marta
Pero espera, pongámonos por un momento en la piel de alguien que lidera un equipo y está escuchando esto.
00:12:11 Marta
Para cualquiera que viva en ese caos diario de un servicio Haití saturado, oír la palabra "scrum" puede provocar sudores fríos.
00:12:19 JM
Sí, tiene mala fama.
00:12:20 Marta
En algunos sectores, es habitual pensar que introducir scrum en un entorno que ya está al límite de su capacidad es sinónimo de añadir más reuniones matutinas, más burocracia de planificación, más roles extraños y quitarle a los técnicos el poco tiempo que les queda para teclear y resolver problemas reales.
00:12:40 JM
Es un miedo lógico.
00:12:41 Marta
¿Cómo se evita que esta solución teórica se convierta en una trampa burocrática en la práctica?
00:12:48 JM
Es una preocupación muy real y justificada.
00:12:51 JM
El error de muchas empresas es implementar Scrum como si fuera un dogma religioso, obligando a cumplir cada ceremonia al minuto sin entender el propósito real de por qué se hace.
00:13:00 Marta
¿Hacerlo por hacerlo.
00:13:02 JM
Exacto.
00:13:03 JM
El enfoque correcto, que está respaldado por la mentalidad agile, es que Scrum no debe añadir burocracia, sino establecer un ritmo y una estructura para gestionar la incertidumbre.
00:13:13 JM
Las reuniones diarias, las dailies, no son para que el jefe controle a qué hora llegó cada empleado.
00:13:18 JM
Para nada.
00:13:19 JM
Son sesiones de 15 minutos de "microsincronización" para detectar quién está bloqueado y necesita ayuda urgente.
00:13:26 JM
Si se aplica correctamente, Scrom actúa como un escudo que protege al equipo de las interrupciones constantes.
00:13:32 Marta
Permitiendo un enfoque profundo en tareas concretas durante períodos cortos o sprints.
00:13:38 Marta
Para ilustrar esta integración del tridente metodológico, hay un caso de estudio en los materiales sobre un equipo de soporte encargado del mantenimiento de impresoras corporativas que resulta muy clarificador.
00:13:51 JM
Es un ejemplo fantástico.
00:13:52 Marta
Pongamos en contexto el problema: los tiempos de respuesta del servicio técnico son altísimos y la tasa de resolución en la primera visita es bajísima.
00:14:02 Marta
Esto significa que un técnico va a la oficina, mira la impresora, dice que lo ha arreglado.
00:14:07 Marta
Cierra el ticket y al día siguiente el usuario vuelve a abrir otra queja porque la impresora sigue atascando el papel.
00:14:13 JM
El cliente, lógicamente, está furioso por el mal servicio y el retrabajo es constante.
00:14:19 Marta
Si ante ese panorama la dirección aplica la reacción inercial clásica, la orden será inmediata.
00:14:26 JM
Necesitamos contratar a más técnicos urgentemente o hay que exigir al equipo actual que cierre al menos un 20% más de tickets por hora.
00:14:34 JM
Presión pura y dura.
00:14:35 Marta
Pero al aplicar el análisis con TOC, el diagnóstico cambia por completo, se observa el flujo de trabajo y se descubre que la restricción real del sistema no es la escasez de personal en plantilla.
00:14:47 JM
No faltan manos.
00:14:49 Marta
El verdadero cuello de botella es que la empresa ha adquirido recientemente una flota de modelos nuevos de impresoras y los técnicos carecen de los manuales técnicos actualizados y no han recibido formación específica.
00:15:01 JM
Están intentando reparar máquinas complejas completamente a ciegas, basándose en intuiciones.
00:15:06 Marta
De ahí el enorme volumen de tickets reabiertos.
00:15:11 Marta
No reparan la máquina correctamente a la primera porque sencillamente no saben cómo funciona el nuevo mecanismo por mucha prisa que se den.
00:15:18 JM
Y una vez que TOC ha localizado ese camión volcado en la autopista, que es la falta de conocimiento técnico, entra en acción la estructura de Scrum combinada con la mentalidad Agile.
00:15:28 Marta
¿Cómo se aplica ahí?
00:15:29 JM
Pues en lugar de decir.
00:15:31 JM
Hoy todo el mundo a intentar arreglar más impresoras al azar, el equipo detiene la rueda, se organiza un sprint, un ciclo corto de trabajo, cuyo objetivo innegociable, el famoso Sprint Goal, se enfoca en resolver esa limitación específica.
00:15:45 Marta
Se centran sólo en eso?
00:15:47 JM
Durante esa semana, el equipo dedica su esfuerzo a crear un repositorio centralizado con todos los manuales de los nuevos modelos, o a impartir una capacitación interna intensiva.
00:15:58 JM
La mentalidad Agile respalda esta decisión temporal.
00:16:02 JM
Asume que dedicar tiempo hoy a entregar ese conocimiento tiene un valor incalculable para estabilizar el servicio de cara al cliente mañana.
00:16:10 Marta
Detienen un momento la rueda del hámster para engrasar el engranaje.
00:16:14 Marta
Dejan de perseguir síntomas superficiales para atacar directamente la enfermedad.
00:16:18 Marta
Esta dinámica nos lleva al siguiente punto fundamental del análisis, que trata sobre los hábitos de los propios profesionales.
00:16:26 JM
Hábitos muy arraigados.
00:16:28 Marta
Quienes trabajan en primera línea de Haití están tan brutalmente condicionados a reaccionar bajo presión que muchas veces saltan directamente a aplicar un parche rápido sin entender verdaderamente la raíz del problema.
00:16:40 JM
Ven una alerta roja en el monitor, reinician el servidor, el sistema vuelve a funcionar, cierran el ticket y cruzan los dedos para que no vuelva a caerse en su turno.
00:16:50 Marta
Tal cual.
00:16:51 Marta
Romper ese ciclo de inercia donde el parcheo constante sustituye a la ingeniería requiere un cambio en el liderazgo.
00:16:57 Marta
La responsabilidad de quien lidera no es dar órdenes técnicas, sino fomentar el uso de herramientas cognitivas, herramientas para pensar mejor.
00:17:05 JM
Y el libro destaca, a través de los anexos, un par de técnicas vitales que estructuran este tipo de pensamiento analítico.
00:17:12 JM
La primera es la técnica de los cinco porqués, habitualmente combinada con el análisis de causa raíz.
00:17:18 Marta
Detengámonos en los cinco porqués.
00:17:20 Marta
La idea no es simplemente quedarse en la superficie de la excusa.
00:17:24 Marta
Pongamos por caso una penalización en el servicio.
00:17:27 Marta
La pregunta inicial es ¿por qué falló el SLA?
00:17:30 Marta
Ese acuerdo de nivel de servicio que establecía el tiempo máximo de resolución prometido al cliente.
00:17:35 JM
La respuesta instintiva del equipo siempre será la misma.
00:17:38 Marta
Porque nos faltó tiempo.
00:17:40 JM
Exacto.
00:17:41 JM
Ahí es donde el análisis debe profundizar.
00:17:43 JM
La indagación no puede detenerse en la falta de tiempo, porque el tiempo es una constante.
00:17:48 JM
Se debe preguntar iterativamente.
00:17:50 Marta
Empecemos al juegos.
00:17:52 Marta
¿Por qué falló el SLA?
00:17:54 JM
Porque la base de datos principal se bloqueó y ralentizó las consultas de todos los usuarios.
00:17:59 Marta
Bien.
00:17:59 Marta
Segundo ¿por qué?
00:18:01 Marta
Porque se bloqueó la base de datos.
00:18:03 JM
Porque un proceso de respaldo programado consumió toda la memoria disponible del servidor.
00:18:07 Marta
Tercer ¿por qué?
00:18:08 Marta
¿Por qué se programó ese respaldo masivo a las 10 de la mañana en pleno pico de trabajo?
00:18:13 JM
Porque el sistema de programación horaria se reseteó por defecto tras un microcorte eléctrico y nadie lo revisó.
00:18:19 Marta
Y así sucesivamente.
00:18:21 Marta
Tirando del hilo hasta encontrar el origen operativo real.
00:18:25 Marta
Lo crucial de esta técnica es que debe basarse siempre en datos objetivos y hechos comprobables.
00:18:33 JM
Erradicando por completo las opiniones emocionales o la destructiva búsqueda de culpables personales.
00:18:38 JM
No se trata de señalar a nadie con el dedo.
00:18:41 Marta
Se trata de hacer de detective dentro de los procesos de la propia compañía, auditando los sistemas y no a las personas.
00:18:50 Marta
Y junto a esta técnica, la segunda gran herramienta de pensamiento analítico mencionada es el análisis de Pareto, la universalmente conocida regla del 8020.
00:19:00 JM
Que merece la pena darle el peso que tiene, porque en el análisis de datos de incidencias los resultados suelen ser asombrosos.
00:19:07 Marta
¿Cómo funciona exactamente aquí?
00:19:09 JM
Refutable.
00:19:10 JM
Al volcar y analizar los datos de un mes de soporte, es extremadamente común descubrir que un grupo muy reducido de causas, apenas el 20% de los elementos.
00:19:20 JM
Está generando el 80% de todo el volumen de quejas, interrupciones o caídas del servicio.
00:19:26 Marta
Claro, a lo mejor el equipo está agobiado por 1000 tickets distintos que parecen un mundo.
00:19:31 JM
Pero el análisis revela que 800 de esos tickets provienen de 2 únicas actualizaciones de software defectuosas instaladas semanas atrás.
00:19:39 Marta
Ese análisis proporciona el criterio exacto para saber dónde enfocar los limitados recursos de ingeniería y, casi más importante aún, proporciona la evidencia necesaria para saber.
00:19:49 Marta
¿A qué peticiones decir que no de forma temporal?
00:19:51 JM
Aprender a decir no es vital.
00:19:53 Marta
Y esto enlaza con una enseñanza crítica sobre el rendimiento organizacional que nos dejan estos textos, la imperiosa necesidad de medir el éxito con métricas que reflejen la realidad y no la mera actividad.
00:20:06 Marta
Es una equivocación estratégica tremenda medir la productividad de un servicio por la cantidad de horas extra trabajadas o
00:20:12 JM
perseguir la quimera de que todo el personal técnico esté ocupado al 100 * 100% de su capacidad en todo momento.
00:20:19 JM
Mantener a todo el equipo saturado y tecleando sin pausa no es un indicador de eficiencia, sino una garantía matemática de atasco.
00:20:27 Marta
Es como la autopista que mencionábamos.
00:20:29 JM
Justo.
00:20:30 JM
Si retomamos la metáfora, una autopista donde el cien por cien del asfalto está ocupado por coches es, por definición, un embotellamiento masivo donde nadie avanza ni un metro.
00:20:40 JM
El éxito de un servicio no se mide por la cantidad de sudor invertido ni por el volumen de trabajo acumulado en las bandejas de entrada.
00:20:47 Marta
Se debe medir exclusivamente por cómo fluye ese trabajo a través del sistema, desde que entra la petición hasta que se resuelve y por el valor real que finalmente se entrega al cliente.
00:20:58 JM
100 * 100%.
00:20:59 JM
Si un profesional está dedicando 10 horas al día a tareas que no alivian el cuello de botella principal detectado por TOC, todo ese tremendo esfuerzo es, a efectos prácticos de la salud del sistema, puro desperdicio.
00:21:11 Marta
Pasar de medir la cantidad de esfuerzo bruto a medir la calidad del flujo y la entrega de valor es sin duda un cambio de mentalidad gigantesco.
00:21:20 Marta
Recapitulando todo el recorrido de este análisis de las fuentes, la principal lección es que la aplicación conjunta de estos marcos de trabajo no da como resultado un simple manual teórico de buenas prácticas.
00:21:32 JM
Representa una auténtica guía de supervivencia táctica para el día a día en el mundo de los servicios tecnológicos.
00:21:38 Marta
A través de la evidencia práctica, se demuestra que el caos y la volatilidad inherentes a los entornos VUCA y BANI nunca se van a solucionar trabajando a ciegas ni imponiendo modelos de control autoritario.
00:21:52 JM
La salida pasa por identificar con precisión quirúrgica qué bloquea realmente la capacidad productiva utilizando TOC y, posteriormente, desplegar una estructura organizativa flexible y orientada a las personas, como la que proporcionan Scrum y Agile.
00:22:07 Marta
Es la única forma de que los equipos logren adaptarse, aprender de los errores y avanzar de forma iterativa, recuperando por fin el enfoque, el criterio y un ritmo de trabajo saludable.
00:22:19 JM
Esa síntesis captura el espíritu completo del modelo propuesto.
00:22:23 Marta
Gracias.
00:22:24 JM
Pero para cerrar esta sesión, resulta muy interesante rescatar un concepto que emana del quinto paso fundamental de la teoría de las restricciones, que advierte textualmente evitar que la inercia se convierta en una nueva limitación.
00:22:37 Marta
Esto es fascinante porque plantea un escenario casi irónico que suele observarse en organizaciones que alcanzan la madurez en estas prácticas.
00:22:45 JM
Sí, imaginemos el éxito total.
00:22:48 JM
Un equipo de servicios IT logra asimilar, interiorizar y dominar plenamente Agile, Scrum y TOC.
00:22:55 Marta
Se vuelven equipos extremadamente rápidos, eficientes, resolutivos y con un flujo de entrega perfecto.
00:23:02 Marta
Todo funciona como un reloj suizo.
00:23:04 JM
Pero ante ese escenario edílico surge un nuevo conflicto.
00:23:08 JM
Es altamente probable que la nueva y fulgurante agilidad del departamento de tecnología deje expuesta de forma muy evidente la lentitud paralizante de otros departamentos más tradicionales de la compañía.
00:23:20 Marta
Claro, el problema se traslada.
00:23:22 JM
Pensemos en un departamento de finanzas que tarda un mes entero en aprobar la compra de una licencia de software que los desarrolladores necesitan para un ciclo de dos semanas.
00:23:34 JM
o en un departamento de recursos humanos que requiere meses de trámites para contratar el perfil específico que el equipo técnico exige para el proyecto actual.
00:23:44 Marta
El problema no ha desaparecido del todo.
00:23:47 Marta
El cuello de botella organizacional simplemente se ha desplazado a otro lugar de la empresa.
00:23:52 JM
Es la paradoja del éxito operativo.
00:23:55 JM
Solucionar el caos y lograr la máxima eficiencia en un departamento Haití es solo la primera batalla.
00:24:01 JM
El verdadero reto aparece cuando el resto de la maquinaria corporativa no está preparada para rodar a esa misma velocidad.
00:24:08 Marta
Nos despedimos aquí, esperando que esta exploración en profundidad haya arrojado luz sobre el desafío de gestionar servicios complejos y haya aportado herramientas útiles para quienes lidian con estos problemas a diario.
00:24:20 JM
Ha sido un placer desgranar todo esto.
00:24:23 Marta
Dejamos una pregunta en el aire para la reflexión diaria de quienes nos escuchan.
00:24:28 Marta
Si mañana mismo un equipo técnico lograra duplicar su velocidad de resolución y entrega, ¿qué otro departamento de la empresa colapsaría primero?
00:24:37 Marta
Hasta la próxima exploración.
