CIO

Optimización: por qué los CIO entienden mal este concepto

Los esfuerzos de optimización a menudo incumplen un principio esencial: para optimizar el conjunto hay que suboptimizar las partes.

ajedrez, ganar

Como CIO, mucho de lo que usted hace es diseñar cosas, y eso es cuando no está supervisando a otras personas que diseñan cosas. O cuando no se asegura de que las cosas que todo el mundo diseña encajan como deberían. Hay algunas reglas universales que rigen el buen diseño, independientemente de lo que se diseñe. La más famosa es, probablemente, la del gran arquitecto Louis Sullivan, según la cual la forma sigue a la función. Menos conocida, pero igual de importante (al menos en nuestro contexto) es una introducida por W. Edwards Deming: para optimizar el conjunto hay que suboptimizar las partes.

Esto es importante independientemente de lo que se diseñe, ya sea un aparato, un programa informático, una organización o un proceso. Y es la clave para entender por qué tantos CIO se equivocan en la optimización.

 

De cola en cola: el cuello de botella oculto de los procesos

Si los CIO pudieran vivir de un solo truco, la optimización de procesos sería probablemente ese. Es vital para que el departamento de TI desempeñe bien su propia función, y gran parte de lo que el departamento de TI hace para ganarse la vida es ayudar a los gestores empresariales a optimizar sus procesos.

Los optimizadores de procesos, dentro y fuera de TI, disponen de una gran cantidad de marcos y metodologías. Lean es una de las más populares, así que vamos a utilizarla para ilustrar este punto. Tal vez la contribución más importante, pero menos reconocida, del pensamiento Lean al mundo de la optimización de procesos es que los procesos no son colecciones de tareas que fluyen de una caja a otra caja.

En cambio, son tareas que fluyen de una cola a otra cola. La diferencia puede parecer sutil, pero es una de las razones por las que la optimización de un conjunto ofrece resultados diferentes a la optimización de las partes de un conjunto. Esto puede parecer una tontería académica o un koan de la informática, pero entender esta diferencia es clave para dominar la optimización de procesos.

Escúcheme. Imagínese que está gestionando un proyecto que necesita un nuevo servidor para seguir adelante, suponiendo por el momento que el departamento de TI no se ha convertido en una nube completa y todavía posee servidores y un centro de datos. Sigue el procedimiento y envía una solicitud a la cola de solicitudes de TI. Simplificando un poco, la vista de todocampista de lo que sigue se parecería a lo siguiente: los equipos responsables de cada paso optimizaron hace tiempo los procedimientos para abordar sus responsabilidades. El esfuerzo total y la duración del ciclo del proceso son los mismos; para este ejemplo hipotético, calcule unas ocho horas, o un día en el calendario del proyecto.

Pero la visión del proceso de todocampista es errónea. El proceso real se parece más a que cada paso del proceso se gestiona como una cola de primeras entradas, primeras salidas (FIFO). Los equipos trabajan en las solicitudes solo cuando la solicitud ha pasado por la cola y ha salido para ser procesada. El esfuerzo total es el mismo que el estimado en la vista de todocampista. Pero el tiempo del ciclo incluye tanto el tiempo de trabajo como el tiempo en la cola: para este proceso modelado, cinco días más o menos.

El análisis real es más complicado que esto. Normalmente, un paso acaba siendo un cuello de botella; el trabajo se acumula en su cola mientras las otras colas se agotan, lo que se contrarresta con 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, cuyas colas eran bastante más largas que las antes descritas, experimentó retrasos de varios meses en sus proyectos mientras sus equipos esperaban la instalación de servidores aprobados de los que dependían, a pesar de que un servidor típico no requería más esfuerzo para adquirir, configurar e instalar que lo representado arriba.

¿La causa principal? Los gestores responsables de la adquisición, la administración de la red, la instalación del software, el control de calidad y la implantación habían organizado el trabajo de sus departamentos para maximizar la utilización del personal y el rendimiento. Ellos se habían optimizado a sí mismos a expensas del conjunto de cada proyecto.

 

Eliminar los elementos externos

La solución, que los devotos de DevOps reconocerán y adoptarán de inmediato, fue incluir a los analistas de infraestructura de TI en el equipo central del proyecto y, lo que es más importante, incluir tareas de infraestructura como la configuración de servidores en el plan de trabajo de cada proyecto, asignando fechas de inicio y de vencimiento en función de cuándo se necesitarían sus productos de trabajo.

Con este cambio, las construcciones de servidores pasaron a formar parte del calendario del proyecto en lugar de ser externalidades sobre las que el director del proyecto no tenía ningún 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 su gestión del trabajo. Los objetivos de utilización del personal no se acercarían ni deberían acercarse al 100%. [Consejo profesional: invierta algo de tiempo en investigar la metodología de gestión de proyectos de la Cadena Crítica de Eliyahu Goldratt para comprender más a fondo este punto].

 

El colapso del MBO

La cuestión de la optimización/suboptimización se aplica a mucho más que al diseño de procesos. Tomemos, por ejemplo, la remuneración de los directivos. En su día, la dirección por objetivos era una teoría popular sobre cómo sacar el máximo partido a la organización sacando el máximo partido a cada directivo de la misma. Su defecto fatal era no reconocer las consecuencias inevitables pero no deseadas de optimizar las partes a expensas del todo.

La forma en que funcionó (fracasar es una forma mejor de decirlo) fue que, como su nombre indica, los ejecutivos de la empresa asignaron a cada directivo uno o más objetivos. Los directivos, al tener más claro lo que debían conseguir, se dedicaban a cumplirlo con un fervor monomaníaco, sin que las distracciones de cualquier otro directivo de la organización les impidieran alcanzar 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 de la OBM.

 

Ayudar con impotencia al servicio de asistencia

Como alguien dijo una vez (o, en realidad, como han dicho casi todos los directivos cada vez que sale el tema), no hay organigramas perfectos. El principio de optimización/suboptimización de Deming es un factor clave que contribuye a las imperfecciones de los organigramas.

Tomemos el clásico help desk y su posición dentro del diseño organizativo de TI. Tiene objetivos de nivel de servicio para la demora entre el primer contacto con el usuario final y la respuesta inicial del servicio de asistencia; también un objetivo para el tiempo necesario para resolver el problema del usuario final. En algún lugar hay también un objetivo de minimizar el coste por incidente.

Hay que tener en cuenta que la gestión de cada incidente notificado incluye el tiempo dedicado a registrarlo, y el tiempo dedicado a intentar resolverlo o el tiempo dedicado a deshacerse de él pasándolo a otro equipo de TI. La forma más fácil de que el servicio de asistencia cumpla con su nivel de servicio de respuesta inicial es hacer lo menos posible durante la respuesta inicial, entregando cada incidente tan rápido como sea posible. De este modo, los analistas del servicio de asistencia técnica quedan libres para responder a la siguiente llamada y no se atascan 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ápidamente que si los analistas del servicio de asistencia intentan resolverlos por su cuenta.

Lamentablemente, este enfoque también garantiza que los analistas del servicio de asistencia nunca aprendan a manejar problemas similares en el futuro. Y aunque también mantiene bajos los costes del help desk, lo hace a costa de distraer al talento más caro de su actual conjunto de prioridades, que, desde la perspectiva del valor global, son probablemente más importantes.

La optimización del help desk acaba siendo un ejercicio de desplazamiento de costes y responsabilidades sin límites. El coste total de la gestión de incidencias aumenta en proporción a la disminución de los costes propios del help desk.

Para optimizar el conjunto, hay que suboptimizar las partes. Puede que esta orientación no suene concreta y pragmática, pero no deje que sus tintes esotéricos le desanimen. Si quiere obtener los mejores resultados, asegúrese de que todos los que participan en la obtención de esos resultados saben lo que deben hacer. También que nadie será penalizado por colaborar para que se produzcan.

 


TE PUEDE INTERESAR...

Nuevo número de nuestra revista de canal 
 
DealerWorld Digital

 

Cobertura de nuestros encuentros

 

Documentos ComputerWorld



Forma parte de nuestra comunidad

 

¿Te interesan nuestras conferencias?