La IA como capataz de obra: el papel del COO
Cuando se diseña un sistema en el que varios roles avanzan el trabajo en paralelo, el primer problema que aparece no es técnico. Es una pregunta sencilla pero imposible de evitar: ¿quién aprueba qué, y en qué orden?
En el diseño inicial, concentramos todas las aprobaciones en un solo punto. Las propuestas y los avances de cada rol llegaban a un mismo lugar para ser revisados. Como sistema, era fácil de entender. Tenía además la ventaja de mantener el registro centralizado.
Sin embargo, al ponerlo en marcha, apareció otro problema. Cuantos más casos había, más se acumulaban las aprobaciones pendientes en ese único punto. Mientras algo esperaba aprobación, el trabajo de los demás roles relacionados también se detenía. Los casos urgentes y los que no lo eran quedaban en la misma fila. La forma de priorizar se volvía improvisada, caso por caso. Nadie cometía ningún error, pero el avance general se iba haciendo cada vez más lento. No es un fallo visible. Es un atasco que se acumula poco a poco. En esta serie llamamos a este estado «colapso silencioso».
Separar el papel del capataz de obra
Para no dejar que este estado se instalara, creamos el COO (sigla en inglés que designa el rol encargado de dirigir la operación diaria de la organización). Si lo comparamos con una obra de construcción, el COO no es quien dibuja los planos ni quien toma la decisión final. Es el capataz que decide en qué orden se hace el trabajo del día.
El trabajo del COO se divide, a grandes rasgos, en dos partes. Una es priorizar entre áreas: decidir en qué orden se atienden los casos que llegan desde distintos roles. La otra es dar seguimiento al avance: comprobar si las cosas se mueven en el orden decidido y si hay algún punto atascado en el camino.
El COO no toma por sí mismo las decisiones de peso. Las decisiones importantes pasan por el mecanismo de consulta que hemos visto en las partes anteriores de esta serie. Lo que hace el COO es el trabajo previo: ordenar el tráfico. Decide qué caso se envía primero a consulta y cuál puede resolverse con una revisión ligera. Ese es su papel: clasificar.
No volver a crear un único punto de aprobación
Aquí conviene detenerse en un punto importante. Si concentrar las aprobaciones en un solo punto fue la causa del «colapso silencioso», reemplazar ese punto por el COO solo repetiría el mismo problema en otro lugar. Esta vez, el propio COO podría convertirse en el nuevo cuello de botella (es decir, el punto donde el flujo de trabajo se concentra y se atasca), mediando en cada caso.
Para evitar esto, pusimos dos límites al COO. El primero: el COO no tiene la decisión final. Clasifica y da seguimiento, pero deja el contenido —si algo se aprueba o no— en manos de la consulta de cada rol. El segundo: las reglas de clasificación están fijadas de antemano. En lugar de que el COO decida caso por caso en el momento, se define con anticipación, según el peso y el alcance de cada caso, por qué camino debe pasar. Con criterios ya establecidos, el sistema se atasca menos incluso si el COO no está disponible.
Un papel que no se nota, hasta que se detiene
El papel del capataz de obra es de los que menos se notan cuando todo funciona bien. Pero al ponerlo en marcha, descubrimos algo: sin este trabajo discreto de ordenar el tráfico, no importa qué tan buenas sean las decisiones que tome cualquier otro rol. El tiempo que tardan en llegar hasta el terreno se va alargando poco a poco.
El COO no es un rol que mejore la calidad de las decisiones. Es un rol que mantiene lo más corta posible la distancia entre el momento en que nace una decisión y el momento en que empieza a moverse de verdad. No concentrar las aprobaciones en un solo punto, pero tampoco dejar que nada avance sin alguien que ordene el tráfico: este rol se separó como el punto medio entre esos dos extremos.