Estamos construyendo Yulia: estas son nuestras primeras hipótesis

Construir un producto nuevo obliga a tomar decisiones mucho antes de disponer de todas las respuestas.

Hay que decidir cómo se organiza la información, qué debe automatizarse, cuándo debe intervenir una persona, qué elementos forman parte del núcleo del sistema y cuáles pueden dejarse fuera de las primeras versiones.

Estas decisiones no deberían basarse únicamente en intuiciones técnicas. Detrás de cada una existe una hipótesis sobre cómo funcionan las organizaciones, dónde se concentra la fricción operativa y qué tendría que cambiar para reducirla.

En Yulia estamos construyendo una infraestructura para operaciones complejas. Estas son algunas de las primeras hipótesis que están condicionando de manera más directa el diseño del producto.

1. La complejidad no está en cada tarea, sino en sus dependencias

Muchas de las tareas que forman parte de una operación compleja no son especialmente difíciles cuando se observan por separado.

Solicitar un documento, revisar un dato, asignar una actividad, aprobar una decisión o generar un informe son acciones relativamente sencillas.

El problema aparece cuando cada una depende de muchas otras.

Un documento puede ser necesario para iniciar una validación. El resultado de esa validación puede determinar qué tareas deben abrirse. Una decisión puede cambiar los responsables, los plazos o la documentación requerida. Un dato incorrecto puede propagarse a varios informes y obligar a revisar actuaciones ya completadas.

La complejidad, por tanto, no depende únicamente del número de tareas, sino de las relaciones existentes entre:

• documentos;
• datos;
• actividades;
• responsables;
• decisiones;
• requisitos;
• plazos;
• excepciones.

Nuestra hipótesis es que una operación no puede gestionarse correctamente como una sucesión de tareas independientes. El sistema debe comprender las dependencias que existen entre sus distintos elementos.

Esta idea condiciona profundamente el diseño de Yulia.

No queremos construir únicamente un gestor de tareas al que se adjuntan documentos, ni un repositorio documental al que se añaden estados. Queremos que cada elemento forme parte de un modelo operativo conectado.

Cuando cambia una pieza, el sistema debe ser capaz de determinar qué otras partes de la operación pueden verse afectadas.

2. Una parte excesiva del trabajo consiste en mantener el proceso funcionando

En muchas organizaciones, una parte relevante del tiempo no se dedica a ejecutar el trabajo principal, sino a evitar que el proceso se detenga.

Alguien tiene que comprobar si se ha recibido la información necesaria, recordar un vencimiento, perseguir una validación pendiente, preguntar quién debe intervenir a continuación o reconstruir el estado real de un proyecto antes de una reunión.

También hay que trasladar información entre sistemas, actualizar hojas de seguimiento, preparar reportes y comunicar manualmente cambios que ya se han producido en otra herramienta.

Este trabajo de coordinación suele estar tan integrado en la rutina que termina considerándose inevitable.

Nuestra hipótesis es que no lo es:

Una parte importante de estas tareas existe porque los sistemas actuales almacenan información, pero no asumen la responsabilidad de mantener la operación en movimiento.

Las personas terminan actuando como la capa de integración entre herramientas, reglas y participantes. Son quienes recuerdan las dependencias, detectan los bloqueos y activan el siguiente paso.

Yulia parte de una idea diferente: el sistema debe asumir una parte mucho mayor de esa coordinación.

Debe saber qué información falta, quién debe aportarla, qué condición permite avanzar, qué plazo está próximo a vencer y qué actuación debe activarse cuando se produce un determinado evento.

El objetivo no es eliminar la colaboración humana, sino reducir el trabajo necesario para sostener mecánicamente el proceso.

3. La información pierde valor cuando se separa de su contexto operativo

Guardar correctamente un documento no significa necesariamente gestionar correctamente la información que contiene.

Un archivo puede estar almacenado en la carpeta adecuada y, aun así, resultar difícil responder preguntas básicas:

• ¿Qué requisito acredita?
• ¿Qué versión es la vigente?
• ¿Quién lo revisó?
• ¿Qué datos fueron extraídos?
• ¿Qué decisión se tomó a partir de él?
• ¿Qué tareas dependen de su aprobación?
• ¿Cuándo debe actualizarse?
• ¿Qué ocurre si se sustituye por una nueva versión?

En muchos sistemas, el documento permanece separado de las decisiones y actividades que genera. Los datos se copian a otra aplicación, las observaciones se envían por correo y el seguimiento se realiza en una hoja de cálculo distinta.

Como resultado, la información existe, pero su contexto se fragmenta.

Nuestra hipótesis es que los documentos, los datos y las decisiones no deberían tratarse como elementos aislados.

Un documento debe ser una pieza activa dentro de la operación. Puede acreditar un requisito, activar una validación, aportar datos estructurados, justificar una decisión o bloquear el avance de una iniciativa.

Esta hipótesis nos lleva a diseñar una gestión documental estructurada, en la que cada archivo pueda relacionarse con:

1. el proceso al que pertenece;
2. la información que contiene;
3. los requisitos que satisface;
4. las revisiones realizadas;
5. las decisiones adoptadas;
6. las actividades que dependen de él.

El valor no se encuentra únicamente en conservar el archivo, sino en mantener la relación entre la información y el proceso en el que debe utilizarse.

4. El sistema debería impulsar el proceso

La mayoría de los sistemas actuales ayuda a las personas a gestionar actividades. Sin embargo, sigue siendo habitual que el avance del proceso dependa de que alguien recuerde qué debe ocurrir a continuación.

Nuestra hipótesis es que esta responsabilidad puede trasladarse parcialmente al sistema.

Cuando se completa una validación, el sistema debería poder activar la siguiente fase. Cuando falta un documento, debería solicitarlo. Cuando se alcanza un plazo, debería escalar el bloqueo. Cuando se cumple una condición, debería actualizar el estado de la operación y comunicarlo a las personas implicadas.

Esto supone pasar de un software que registra lo que hacen los usuarios a una infraestructura que participa activamente en la ejecución del proceso.

No significa que el sistema deba tomar todas las decisiones.

Las personas seguirán siendo necesarias cuando exista ambigüedad, riesgo, conflicto, una excepción no prevista o una decisión que requiera conocimiento profesional.

Pero no deberían tener que intervenir para impulsar cada paso previsible.

La visión que estamos explorando puede resumirse así:

El sistema debe encargarse de que el proceso avance; las personas deben intervenir cuando el proceso necesite criterio.

Esta hipótesis determina qué entendemos por autonomía operativa. No se trata de eliminar a las personas del proceso, sino de reservar su atención para aquellas situaciones en las que realmente aporta valor.

5. La autonomía no exige que una inteligencia artificial tome todas las decisiones

En el contexto actual, hablar de sistemas autónomos suele conducir inmediatamente a hablar de agentes de inteligencia artificial.

Sin embargo, una parte importante de las operaciones empresariales no necesita un modelo interpretando libremente cada situación.

Muchos procesos pueden avanzar mediante una combinación de:

• reglas;
• estados;
• condiciones;
• permisos;
• plazos;
• eventos;
• validaciones deterministas;
• integraciones entre sistemas.

La inteligencia artificial puede resultar especialmente útil cuando es necesario interpretar documentos, extraer información no estructurada, detectar incoherencias, generar borradores o apoyar decisiones que no pueden reducirse fácilmente a una regla.

Pero utilizar IA en cada paso no necesariamente mejora el proceso. Puede añadir costes, incertidumbre y falta de trazabilidad allí donde una regla sencilla habría sido suficiente.

Nuestra hipótesis es que una infraestructura operativa autónoma debe combinar diferentes mecanismos y utilizar cada uno allí donde sea más adecuado.

En algunos casos, la respuesta será una regla determinista. En otros, una automatización convencional. En otros, un modelo de inteligencia artificial. Y en determinadas situaciones, una decisión humana.

El diseño de Yulia parte de esa combinación.

No queremos construir un sistema en el que la IA sustituya indiscriminadamente la lógica del proceso, sino uno en el que pueda utilizarse de forma controlada, explicable y vinculada al contexto operativo.

Cómo estamos convirtiendo estas hipótesis en producto

Estas hipótesis están determinando el alcance de la primera versión de Yulia.

Estamos trabajando sobre un conjunto inicial de capacidades:

1. Portal de relación con clientes y colaboradores

Un espacio desde el que cada participante pueda aportar información, consultar el estado de sus actuaciones y atender las solicitudes que tenga pendientes.

2. Gestión documental estructurada

Los documentos no se almacenan únicamente como archivos. Se relacionan con requisitos, procesos, revisiones, decisiones y datos específicos.

3. Planificación y seguimiento de actividades

Las tareas se integran dentro del flujo operativo y se activan en función del estado del proceso, sus dependencias y las decisiones adoptadas.

4. Recopilación y validación de información

El sistema permite solicitar datos y documentos, comprobar condiciones, registrar revisiones y mantener la trazabilidad de cada validación.

5. Automatización del avance operativo

Determinados eventos pueden activar nuevas actividades, comunicaciones, cambios de estado o solicitudes de información sin depender de una intervención manual.

6. Generación de informes

Los informes se producen a partir de la información estructurada y actualizada que ya existe dentro del sistema, reduciendo la necesidad de reconstruir manualmente el estado de la operación.

Estas funcionalidades no representan todavía la visión completa de Yulia.

Constituyen la primera infraestructura necesaria para comprobar si podemos reducir tres fuentes principales de fricción:

• la coordinación manual;
• la fragmentación de la información;
• la dependencia constante de la atención humana.

Lo que todavía necesitamos validar

Construir sobre hipótesis implica aceptar que algunas serán incompletas y que otras tendrán que cambiar.

Todavía necesitamos responder preguntas importantes.

1. ¿Cuánto puede estandarizarse una operación sin eliminar las particularidades de cada organización?

1. ¿Qué elementos debería poder configurar directamente el usuario y cuáles requieren un diseño más especializado?

1. ¿Qué procesos deben resolverse mediante reglas y cuáles se benefician realmente de la inteligencia artificial?

1. ¿Hasta qué punto Yulia debe sustituir herramientas existentes y en qué casos debe actuar como una capa de infraestructura que las conecte?

1. ¿Qué nivel de autonomía resulta útil sin reducir la confianza de las personas que gestionan el proceso?

1. ¿En qué tipo de operación genera más valor esta combinación de documentación estructurada, coordinación, automatización y trazabilidad?

Estas preguntas no se resolverán únicamente construyendo tecnología.

Necesitamos contrastarlas con organizaciones y profesionales que trabajen cada día con procesos intensivos en documentación, validaciones, seguimiento, decisiones y coordinación entre múltiples participantes.

Estamos construyendo la primera versión de Yulia para convertir estas hipótesis en algo que pueda probarse.

No buscamos demostrar que todas son correctas. Buscamos descubrir cuáles lo son, cuáles necesitan matices y qué problemas importantes todavía no estamos viendo.

Esa validación también forma parte del producto.