Ha habido un piloto exitoso. La dirección quiere ritmo. Se toma la decisión: desplegarlo al resto de la organización, a otros equipos, a otros departamentos. Lo que funcionó en un rincón ahora debe funcionar en todas partes.
Eso no siempre sale bien. No porque la tecnología reaccione de repente de otra manera, sino porque el entorno en el que debe funcionar está organizado de forma distinta en cada lugar. El equipo donde el piloto tuvo éxito tenía, por casualidad, una infraestructura de TI capaz de soportar lo que se pedía, una gestión de datos en orden y una estructura organizativa en la que alguien asumía responsabilidad. En otras partes de la organización, una o varias de esas cosas están en otra situación. El resultado: el mismo esfuerzo produce algo en un lugar y nada en otro, o peor aún, trabajo adicional para corregir errores.
Escalar se siente como el siguiente paso porque el piloto ha demostrado algo. Hay un resultado, hay entusiasmo, hay presión para aumentar el rendimiento. Quien ha logrado que algo funcione, no quiere limitarlo a un solo equipo. Además, escalar es visible: más usuarios, más equipos, más líneas de proceso que adoptan la nueva forma de trabajar. Eso se siente como avance, incluso cuando las dimensiones fundamentales —organización, infraestructura de TI, gestión de datos— aún no están en todas partes al nivel donde la dimensión que depende de ellas sí puede funcionar.
El orden en que esto funciona no es opcional. Si la capa fundamental no está lista, la capa dependiente no tiene nada sobre lo cual construir. No es una cuestión de preferencia o de tomarse más tiempo; es la manera en que las dimensiones se sostienen entre sí. Escalar ignora ese orden y espera que la repetición de una forma de trabajar sea suficiente, incluso sin la base que estuvo presente por casualidad la primera vez.
Hay varias señales que se repiten con frecuencia. Los equipos que adoptan la nueva forma de trabajar reportan resultados dispares, y nadie puede explicar bien por qué funciona en un equipo y no en otro. Se pide más formación o más comunicación, mientras que el problema está en otro lugar: en sistemas que no se conectan entre sí, en datos que no tienen la misma calidad, en una estructura en la que nadie es dueño del resultado más allá de los límites del equipo.
También es reconocible la situación en la que se despliega tecnología sobre una estructura que no ha cambiado ella misma: la nueva forma de trabajar se pone a disposición técnicamente, pero los roles, las responsabilidades y las líneas de decisión siguen siendo los mismos que antes del piloto. Comparable es el patrón en el que un piloto funciona bien en su propio rincón pero no se conecta con el resto de la organización: la ampliación copia la forma de trabajar, no las condiciones bajo las cuales esa forma de trabajar se logró.
Una tercera señal es menos visible pero igual de determinante: dos entusiastas llevan el proyecto adelante y nadie más se siente responsable. Mientras la iniciativa dependa de unas pocas personas que casualmente están motivadas, no hay una base organizativa sobre la cual escalar; solo hay entusiasmo que no se multiplica en cuanto el equipo crece.
Quien reconoce estas señales haría bien en preguntarse si la dispersión entre equipos es consecuencia de la ejecución, o de una diferencia en el grado de preparación que ya existía desde antes de escalar. Esa distinción es precisamente lo que examina la medición de madurez de hybridresourcing: no una sola puntuación para toda la organización, sino cinco niveles en siete dimensiones, medidos mediante varias personas que puntúan por separado, de modo que se hace visible la dispersión entre sus respuestas. Esa dispersión a menudo dice más que el promedio: si la estimación del CEO difiere fundamentalmente de la del CIO, ahí reside parte de la explicación de por qué escalar funciona en un lugar y no en otro. Lo que un CEO muestra en esta medición sobre su propia organización y lo que un COO reconoce en ella desde la ejecución diaria rara vez ofrecen la misma imagen, y esa diferencia es precisamente aquello sobre lo que está construida la medición.
Esta página trata sobre si la organización puede sostener la IA: si la estructura, la infraestructura y la gestión de datos están en un nivel en el que escalar tiene sentido. Esa es una pregunta distinta de qué parte del trabajo mismo es apta para transferirse a la IA. Esta última pregunta la responde el escáner de trabajo de FTE TO AI: calcula por tarea qué parte del trabajo puede asumir la IA, independientemente de si la organización ya está preparada para ello. Ambas preguntas van juntas, pero el orden no es opcional: saber qué es transferible tiene poco valor mientras no esté claro si la base puede sostener esa transferencia.
La medición de madurez de hybridresourcing todavía está en construcción. Quien desee utilizar la medición en cuanto esté disponible puede inscribirse en la lista de espera.
Vraag maar wat er moet staan voordat AI in uw organisatie kan landen.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.