Los esfuerzos de optimización con demasiada frecuencia entran en conflicto con un principio esencial: para optimizar el todo, es necesario suboptimizar las partes.

Como CIO, mucho de lo que realiza consiste en diseñar cosas, y eso ocurre cuando no está 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. Acaso la más famosa es la que dijo el gran arquitecto Louis Sullivan: “la forma sigue a la función”. Menos conocida, pero igual importante (al menos para nuestro contexto) es otra pronunciada por W. Edwards Deming: “Para optimizar el todo, debemos suboptimizar las partes”.

Estas reglas importan 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.

El cuello de botella oculto del proceso

Si los CIO pudieran ganarse la vida con un solo logro, probablemente sería la optimización de procesos. Es vital que el área de TI desempeñe bien su propia función, y gran parte de lo que TI 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 es uno de los más populares, así que usemos eso para ilustrar el punto.

Quizás la contribución más importante, pero menos reconocida que el pensamiento Lean ha hecho al mundo de la optimización de procesos es que los procesos no son conjuntos de tareas que fluyen de un cuadro a otro.

En cambio, son tareas que fluyen de una fila 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 las partes de un todo. 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.

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 servidores y 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 se vería como la siguiente figura:

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. El proceso real se parece más a la siguiente figura:

Cada paso del proceso se gestiona como una cola FIFO (primero en entrar, primero en salir). Los equipos trabajan en solicitudes sólo 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 fila: 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 fila eran un poco más largos que los que se muestran arriba, 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 para adquirir, configurar e instalar que lo que se muestra arriba.

¿La causa principal? Los gerentes responsables de adquisiciones, administración de redes, instalación de software, control de calidad e implementació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 de cada proyecto.

Eliminando externalidades

La solución, que los devotos de DevOps reconocerán y aceptarán de inmediato, fue 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 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 cadena crítica de Eliyahu Goldratt para comprender más a fondo 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 a la mesa de ayuda

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.

Considere la mesa de ayuda clásica 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 para el 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 él entregándolo 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 respuesta inicial, entregando cada incidente lo más rápido posible. Esto mantiene a los analistas de la mesa de ayuda 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 la mesa de ayuda, 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, son probablemente 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 obtener los mejores resultados, asegúrese de que todos los involucrados en la entrega de esos resultados sepan lo que se supone que deben ser.

También que nadie será penalizado por colaborar para hacerlos realidad.

Bob Lewis, CIO.com