Gamers ahora disponen en Latam de SSD más fría
Los esfuerzos de optimización con demasiada frecuencia entran en conflicto con un principio esencial: para optimizar el todo, debe suboptimizar las partes.
Por Bob Lewis | Original de IDGN
Como CIO, mucho de lo que haces es diseñar cosas. Y eso es cuando no estás supervisando a otras personas que diseñan cosas. O cuando no se está asegurando de que las cosas que todos diseñan encajen como deberían.
Hay algunas reglas universales que gobiernan el buen diseño, sin importar lo que se esté diseñando.
El más famoso es, probablemente, el dicho del gran arquitecto Louis Sullivan de que la forma sigue a la función.
Menos conocido, pero igual de importante (al menos para nuestro contexto) es uno presentado por W. Edwards Deming: para optimizar el todo debemos suboptimizar las partes.
Esto es importante, independientemente, de lo que se diseñe: ya sea un dispositivo, un software, una organización o un proceso.
Y es la clave para comprender por qué tantos CIO se equivocan en la optimización.
De cola en cola: el cuello de botella oculto del proceso
Si los CIOs pudieran ganarse la vida con un solo truco, probablemente sería la optimización de procesos.
Es vital que TI desempeñe bien su propia función, y gran parte de lo que hace para ganarse la vida es ayudar a los gerentes comerciales a optimizar sus procesos también.
Los optimizadores de procesos, dentro y fuera de TI, tienen una gran cantidad de marcos y metodologías a su disposición.
Lean se encuentra entre los más populares, así que usemos eso para ilustrar el punto.
Quizás la contribución más importante pero menos reconocida que ha hecho el pensamiento Lean al mundo de la optimización de procesos es señalar que estos no son colecciones de tareas que fluyen de un cuadro a otro.
En cambio, son tareas que fluyen de una cola a otra.
La diferencia puede parecer sutil pero es una de las razones por las que la optimización de un todo ofrece resultados diferentes a los de la optimización de sus partes.
Esto puede sonar como un hoo-ha académico o un koan de TI, pero comprender esta diferencia es clave para dominar la optimización de procesos.
Escúchame.
Imagine que está administrando un proyecto que necesita un nuevo servidor para continuar, suponiendo que, por el momento, TI no se haya ido completamente a la nube y aún posea tanto servidores como un centro de datos.
Siga el procedimiento y envíe una solicitud a la cola de solicitudes de TI.
Simplificando un poco, la vista de cuadro a cuadro de lo que sigue es un flujo directo.
Los equipos responsables de cada paso optimizaron hace mucho tiempo los procedimientos para abordar sus responsabilidades.
El esfuerzo total y el tiempo del ciclo del proceso son los mismos. Para este ejemplo hipotético, calcule unas ocho horas o un día en el cronograma del proyecto.
Pero la visión de caja a caja del proceso es incorrecta.
Cada paso del proceso se gestiona como una cola FIFO (primero en entrar, primero en salir).
Los equipos trabajan en solicitudes solo cuando la solicitud ha fluido a través de la cola y ha salido para su procesamiento.
El esfuerzo total es el mismo que se estima en la vista de caja a caja.
Pero el tiempo del ciclo incluye tanto el tiempo de trabajo como el tiempo en cola: para este proceso modelado, cinco días más o menos.
El análisis real es más complicado que esto.
Por lo general, un paso termina siendo un cuello de botella: el trabajo se acumula en su cola mientras que otras colas se agotan, contrarrestado por todas las colas que reciben solicitudes de más de una fuente.
Pero eso no cambia el principio, solo la complejidad de la simulación.
Esto es real, no solo teoría.
No hace muchos años, un cliente, cuyos tamaños de cola eran un poco más largos que el promedio, experimentó retrasos en el proyecto de varios meses mientras sus equipos esperaban la instalación de los servidores aprobados de los que dependían, aunque un servidor típico no requería más esfuerzo del que ya hemos señalado para:
- Adquirir
- Configurar
- E instalar
¿La causa principal? Los gerentes responsables de:
- Adquisiciones
- Administración de redes
- Instalación de software
- Garantía de calidad
- E iImplementación
… habían organizado el trabajo de sus departamentos para maximizar la utilización y el rendimiento del personal.
Ellos, las partes, se habían optimizado a expensas del todo. Del proyecto.
Eliminar externalidades
La solución que los devotos de DevOps reconocerán y aceptarán de inmediato es incluir analistas de infraestructura de TI en el equipo central del proyecto y, lo que es más importante, incluir tareas de infraestructura como:
- Configurar servidores en el plan de trabajo de cada proyecto
- Asignar fechas de inicio
- Y de vencimiento…
… fechas basadas en cuándo se necesitarían sus productos de trabajo.
Con este cambio, las compilaciones de servidores se convirtieron en parte del cronograma del proyecto en lugar de ser externalidades sobre las cuales el administrador del proyecto no tenía control.
A cambio, el CIO tuvo que aceptar que si los proyectos iban a entregar sus resultados a tiempo y dentro de sus presupuestos, el resto de la organización de TI tendría que permitir cierta holgura en la gestión de su trabajo.
Los objetivos de utilización del personal no se acercarían ni deberían acercarse al 100%. (Consejo profesional: invierta algo de tiempo investigando la metodología de gestión de proyectos de la Cadena Crítica de Eliyahu Goldratt para obtener una comprensión más profunda de este punto).
El colapso de MBO
El problema de optimización/suboptimización se aplica a mucho más que el diseño de procesos.
Tomemos, por ejemplo, la compensación de la gerencia.
En el pasado, la administración por objetivos (MBO, por sus siglas en inglés) era una teoría popular sobre cómo sacar el máximo provecho de la organización sacando el máximo provecho de cada gerente de la organización.
Su defecto fatal fue también la falta de reconocimiento de las consecuencias inevitables – pero no intencionadas – de optimizar las partes a expensas del todo.
La forma en que funcionó (no funcionó es una mejor manera de decirlo) fue que, como su nombre lo indica, los ejecutivos de la empresa asignaron a cada gerente uno o más objetivos.
Los gerentes, dada la mayor claridad sobre lo que se suponía que debían lograr, se dedicaron a lograrlo con un fervor monomaníaco, sin obstáculos por las distracciones de lo que cualquier otro gerente de la organización necesitaba para lograr sus propios objetivos.
Las organizaciones modernas que sufren de lo que sus habitantes llaman “pensamiento de silo” con su incapacidad para colaborar son vestigios de la era MBO.
Ayudar sin poder hacer nada por la Mesa de ayuda (Heldesk)
Como alguien dijo una vez o, en realidad, como casi todos los gerentes han dicho cada vez que surge el tema: no hay organigramas perfectos.
El principio de optimización/suboptimización de Deming es un contribuyente clave a las imperfecciones de los organigramas.
Tome al Heldesk (Mesa de ayuda) clásico y su posición dentro del diseño organizacional de TI.
Tiene objetivos de nivel de servicio para la demora entre el primer contacto con el usuario final y la respuesta inicial de la mesa de ayuda.
También un objetivo con respecto al tiempo necesario para resolver el problema del usuario final.
En algún lugar también existe el objetivo de minimizar el costo por incidente.
Imagínese que el manejo de cada incidente informado incluye el tiempo dedicado a registrarlo y el tiempo dedicado a intentar resolverlo o el tiempo dedicado a deshacerse de ellos entregándolos a un equipo de TI diferente.
La forma más fácil para que la Mesa de Ayuda cumpla con su nivel de servicio de respuesta inicial es hacer lo menos posible durante la primera respuesta, entregando cada incidente lo antes posible.
Esto mantiene a los analistas de helpdesk libres para responder la siguiente llamada y evitar que se atasquen tratando de resolver problemas para los que no están preparados.
Mejor aún, al dirigir los problemas a los departamentos con más experiencia, los incidentes se resolverán más rápido que si los analistas de la mesa de ayuda trataran de resolverlos por su cuenta.
Lamentablemente, este enfoque también garantiza que los analistas de la mesa de ayuda nunca aprendan a manejar problemas similares en el futuro.
Y, si bien también mantiene bajos los costos de Helpdesk, lo hace a expensas de distraer a los talentos más costosos de su conjunto actual de prioridades que, desde la perspectiva del valor general, probablemente sean más importantes.
La optimización de la mesa de ayuda termina como un ejercicio de transferencia de costos y responsabilidades sin restricciones.
El costo total de la gestión de incidentes aumenta en proporción a cuánto disminuyen los costos propios de la Mesa de Ayuda.
Para optimizar el todo, hay que suboptimizar las partes.
Es posible que esta guía no suene concreta y pragmática, pero no deje que sus connotaciones esotéricas lo desanimen.
Si desea los mejores resultados, asegúrese de que todos los involucrados en la entrega de estos sepan lo que se supone que deben ser.
También que nadie será penalizado por colaborar para hacerlos realidad.
