Una ventana de chat en la que alguien formula una pregunta y recibe una respuesta parece sencilla. Lo que debe ocurrir por debajo de eso no lo es. El apoyo a la decisión con IA significa que un sistema combina datos de varias fuentes, los coloca en el contexto correcto y formula una respuesta sobre la que alguien se atreve a actuar. Cada paso de esa cadena impone una exigencia a la organización que precede a la cuestión de qué modelo o qué plataforma se elige.
Un modelo que apoya decisiones es tan bueno como los datos que llega a ver. Eso significa que las cifras de distintos sistemas deben manejar la misma definición, que los datos históricos deben ser accesibles sin que alguien deba exportarlos primero manualmente, y que debe estar claro qué fuente es la autoritativa cuando dos sistemas se contradicen. Las organizaciones que aún no tienen esto en orden lo notan justo en el momento en que la respuesta del sistema no coincide con lo que las personas en el terreno ya sabían.
El apoyo a la decisión se sitúa a menudo en el punto de encuentro de varios departamentos: el momento en que la información debe pasar de un lugar a otro para que resulte una buena decisión. Eso hace relevante cómo funciona la coordinación entre departamentos en su organización, pues un sistema que emite un consejo que luego se queda atascado entre dos departamentos no ha aportado nada. La misma lógica se aplica a las fuentes con las que se alimenta el consejo: si esas fuentes consisten en documentos que primero deben leerse y resumirse antes de poder usarse, la pregunta de qué exige la lectura y el resumen de documentos a la organización influye directamente en la velocidad y la fiabilidad del consejo que de ello resulta.
Parte del apoyo a la decisión no consiste en responder a una pregunta que alguien formula activamente, sino en señalar algo que merece atención antes de que alguien pregunte por ello. Eso plantea exigencias distintas a las de una ventana de chat: debe existir algo que observe de forma continua, reconozca umbrales y distinga entre ruido y una señal que realmente importa. Lo que eso exige de la monitorización y la señalización es una pregunta que debe responderse por separado, y quien quiera saber qué exige la monitorización y la señalización de la organización verá que no se trata solo de tecnología, sino también de quién recibe las señales y qué se hace con ellas.
Muchas decisiones se preparan en conversaciones: con clientes, con proveedores, entre compañeros. Si esas conversaciones no se registran de una manera reutilizable, al sistema que debe apoyar una decisión le falta precisamente el material que dio lugar a ella. Eso hace visible qué exige el registro y el seguimiento de conversaciones a la organización, un tema que afecta directamente a la cuestión de si el apoyo a la decisión puede construirse sobre algo, o sobre nada. Quien quiera saber más sobre qué exige el registro y el seguimiento de conversaciones verá la relación con la calidad de cada consejo que después se derive de esas conversaciones.
No es raro que un equipo, con un conjunto de datos y un caso de uso, muestre una versión funcional de apoyo a la decisión. Eso demuestra que es posible, no que sea posible a escala de toda la organización. En cuanto un segundo departamento, con otros sistemas, otros propietarios de datos y otras definiciones, quiere conectarse, a menudo resulta que la primera versión se hizo a medida exactamente para ese único equipo. Por qué un piloto que solo funciona en su propio rincón no aporta nada no es, entonces, una cuestión de tecnología decepcionante, sino de un fundamento que nunca se construyó de forma más amplia. Para quien quiera leer más sobre esto: por qué un piloto que solo funciona en su propio rincón no aporta nada explica qué falta entre una demostración y una aplicación a escala de toda la organización.
Un sistema puede dar el consejo mejor fundamentado y aun así no cambiar nada, si nadie asume la responsabilidad de trabajar con él. Ese es un punto organizativo, no un punto técnico: quién es el propietario del consejo, quién evalúa si se sigue, y quién explica por qué en una ocasión no se ha seguido. Sin ese propietario, el apoyo a la decisión desaparece en la categoría de los experimentos interesantes. Por qué una demostración sin propietario no aporta nada guarda relación con ese mismo punto, y quien quiera seguir el razonamiento preciso puede encontrarlo en por qué una demostración sin propietario no aporta nada.
Las exigencias que plantea el apoyo a la decisión tienen que ver, en gran medida, con lo que ya debe estar presente antes de que la ventana de chat pueda hacer algo significativo: datos limpios y accesibles, una transferencia funcional entre departamentos, un registro estructurado de conversaciones y documentos, y un propietario claro para lo que el sistema produce. Precisamente por eso, la medición de madurez de hybridresourcing observa las dimensiones fundamentales antes de abordar las dependientes: la organización, la infraestructura de TI y la gestión de datos determinan si hay algo sobre lo que construir el apoyo a la decisión.
La pregunta de si una organización puede sostener esto es independiente de la pregunta de qué parte del trabajo puede efectivamente asumir la IA. Esto último lo calcula el escáner de trabajo de FTE TO AI por tarea: qué parte del trabajo se deja asumir, y bajo qué condiciones. Mientras esta página describe qué debe estar presente antes de que el apoyo a la decisión pueda funcionar, el escáner de trabajo describe qué cambia concretamente en el trabajo mismo, una vez presente esa base.
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.