Un equipo pone en marcha un piloto. Unos cinco empleados, un proceso delimitado, una herramienta que se puede activar rápidamente. Al cabo de unas semanas, los resultados dentro de ese grupo pequeño son buenos. Se ahorra tiempo, el trabajo avanza más rápido, las primeras reacciones son positivas. El piloto se comparte internamente como prueba de que la IA funciona para la organización.
Después ocurre algo llamativo: nada. El piloto se queda con ese único equipo, en ese único proceso, con esas cinco personas. Otros departamentos observan, dicen que es interesante, y siguen con su propio trabajo como siempre lo han hecho. Un año después, el piloto todavía existe, pero la organización no ha cambiado.
El razonamiento detrás de un piloto encerrado en un rincón no es descabellado. Se quiere limitar el riesgo, se quiere aprender antes de implementar a gran escala, no se quiere poner de cabeza a toda la organización de inmediato por algo no probado. Empezar en pequeño es un punto de partida razonable.
El problema no está en empezar en pequeño. Está en lo que no ocurre después. Un piloto que funciona bien en un entorno protegido dice sobre todo algo sobre ese entorno: personas motivadas, un proceso manejable, pocas dependencias con otros departamentos. No dice nada sobre si el resto de la organización puede hacer lo mismo. Los datos están ordenados de otra manera en otros lugares, los procesos funcionan de forma distinta, las personas tienen otras prioridades. El piloto demuestra que puede funcionar en condiciones ideales, no que la organización esté lista para hacerlo funcionar en todas partes.
También es reconocible la situación en la que dos entusiastas y nadie más sostienen el piloto. Mientras esas dos personas dediquen energía al proyecto, este continúa. En el momento en que una de ellas asume otro rol o tiene mucho trabajo, el piloto se detiene. Nadie lo nota de inmediato, porque la organización nunca dependió realmente de él.
Hay algunas señales reconocibles. El piloto se menciona en presentaciones internas como historia de éxito, pero nadie sabe decir cuál es el siguiente paso para ampliarlo. No hay un acuerdo concreto sobre cuándo el experimento se convierte en algo estructural, y por tanto no hay acuerdo sobre qué debe quedar demostrado con la prueba. ¿Tiene éxito si el ahorro de tiempo es demostrable? ¿Si la calidad se mantiene igual? ¿Si otros equipos piden acceso por sí mismos? Sin ese criterio, un piloto sigue funcionando sin llegar nunca a ninguna parte.
Otra señal es que la tecnología funciona, pero la manera de trabajar a su alrededor no se ha adaptado. Las personas usan la herramienta junto a su proceso existente en lugar de en sustitución de él. Eso es una señal de que la tecnología va por delante de la estructura en la que debe funcionar: la organización no ha cambiado nada para hacer espacio al nuevo trabajo, así que el nuevo trabajo se adapta al antiguo, y no al revés.
Una tercera señal es que nadie fuera del piloto se siente propietario de él. Hay un equipo que lo prueba, pero ningún gerente, directivo o responsable de proceso que asuma la responsabilidad de ampliarlo. Si un piloto sigue siendo una demostración en lugar de una propiedad, entonces es exactamente el patrón en el que una demostración sin propietario pierde su efecto en cuanto desaparece la novedad inicial.
Y por último: si usted se imagina qué pasaría si el piloto tuviera que extenderse mañana a otros tres departamentos, y la respuesta es incierta o incómoda, probablemente ya se encuentre en esta trampa. No porque el piloto haya fracasado, sino porque nunca estuvo pensado para ir a ningún lugar.
La razón por la que los pilotos se quedan atascados en su rincón raramente está en la tecnología misma. Está en lo que hay debajo del piloto: cuán madura es la organización, la infraestructura de TI y la gestión de datos en relación con lo que requiere la implementación a gran escala. Un piloto puede funcionar excelentemente con un conjunto de datos aislado y un equipo selecto, y aun así resultar imposible en cuanto afecta al resto de la organización, sencillamente porque las capas fundamentales no están preparadas para ello. Precisamente por eso implementar a gran escala sin que la base esté lista tan a menudo se estanca: el piloto nunca fue el problema, el terreno debajo de él sí lo era.
La medición de madurez de hybridresourcing muestra ese terreno: cinco niveles, desde baseline hasta intelligence, en siete dimensiones que juntas determinan si una organización puede sostener un piloto fuera de su rincón. En una ronda plot, varias personas puntúan por separado, y la dispersión entre sus respuestas a menudo ya muestra dónde la organización está en desacuerdo consigo misma antes de que se haya dicho una palabra sobre tecnología. Quien quiera saber en qué debería fijarse un CEO respecto a la madurez de IA antes de iniciar el próximo piloto, encontrará ahí un punto de partida.
Esta medición trata de la pregunta de si la organización puede sostener un piloto: ¿está la estructura preparada, están los datos en orden, es suficiente la infraestructura? Esa es una pregunta distinta a qué parte del trabajo en sí es adecuada para transferir a la IA. Esa pregunta la responde el escáner de trabajo de FTE TO AI: calcula por tarea qué parte del trabajo se puede asumir, independientemente de si la organización en su conjunto ya está lista para ello. Quien esté considerando ampliar un piloto haría bien en plantear ambas preguntas por separado antes de confundirlas entre sí.
La medición de madurez está en construcción. Quien quiera realizar la ronda plot 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.