Plantilla de briefing de automatización

Empiece por la decisión que el proyecto debe mejorar

Un proyecto de automatización se vuelve difícil de estimar cuando su propósito se describe solo como «ahorrar tiempo», «usar IA» o «mejorar las operaciones». Pueden ser ambiciones válidas, pero no definen qué debe hacer el sistema propuesto, quién depende de él ni cómo se juzgará su valor. Empiece por un objetivo empresarial explícito: una decisión que acelerar, una transferencia que reducir, una cola que gestionar o una tarea recurrente que estandarizar.

Exponga el objetivo en términos operativos. Por ejemplo, «preparar un primer borrador completo de registros de incorporación de proveedores para revisión humana» es más estimable que «automatizar la incorporación». La primera afirmación indica una salida, una persona responsable y un punto de revisión. También proporciona al equipo una base para identificar sistemas, datos, excepciones y medición.

Victor Laybats presta servicios de ingeniería de IA y automatización desde París y publica orientación práctica para definir, proteger y medir proyectos de IA y automatización. En ese contexto, un objetivo no es un eslogan del proyecto; es el límite que permite separar el trabajo de solicitudes adyacentes que, de otro modo, podrían ampliar el alcance.

• Nombre el proceso empresarial y a la persona responsable del proceso.
• Describa la salida, recomendación, acción o transferencia específica esperada.
• Defina qué usuarios o equipos utilizarán el resultado.
• Nombre la decisión o medida operativa que el proyecto debería respaldar.

Describa el flujo actual, incluidas las excepciones

Quien estima necesita entender el trabajo que existe hoy antes de proponer automatización. Por tanto, un briefing debe mostrar la secuencia actual desde el desencadenante hasta la finalización: qué inicia el trabajo, qué personas o sistemas intervienen, qué información se mueve entre pasos y qué marca el proceso como terminado. Un flujo numerado sencillo suele ser más útil que un diagrama de proceso amplio con etiquetas sin explicar.

El detalle importante es la variación. Muchos procesos parecen sencillos hasta que el equipo considera información ausente, registros duplicados, solicitudes inusuales, aprobaciones, escalados o trabajo realizado fuera del sistema principal. Estos casos afectan a las decisiones de diseño y al esfuerzo porque determinan si la solución puede seguir una ruta estable o debe devolver el trabajo a una persona.

No intente predecir todos los escenarios poco frecuentes durante la fase de briefing. En su lugar, diferencie los casos normales de las excepciones conocidas e indique qué debe ocurrir cuando la automatización no pueda continuar de forma segura. Así se hace visible la incertidumbre sin convertir el briefing en una especificación técnica.

• ¿Qué evento desencadena el proceso?
• ¿Qué sistemas, archivos, bandejas de entrada o formularios intervienen?
• ¿Cuál es la ruta normal desde el inicio hasta la finalización?
• ¿Qué excepciones ocurren con la frecuencia suficiente para importar?
• ¿Qué debe suceder cuando falta información requerida o es inconsistente?

Concretar el acceso y control de datos

Un proyecto útil de IA o automatización depende de datos controlados. Para estimar, esto implica más que enumerar fuentes de datos. Explique dónde reside la información, quién puede autorizar el acceso, cómo está estructurada actualmente, con qué frecuencia cambia y si puede utilizarse para el propósito propuesto. Una referencia vaga a los «datos de la empresa» deja sin resolver cuestiones importantes.

Describa las entradas y salidas a un nivel práctico. Las entradas pueden incluir un formulario de solicitud, un registro de cliente, una colección de documentos o el estado de una transacción. Las salidas pueden ser una respuesta redactada, un registro categorizado, una actualización del flujo o un informe para revisión. Para cada una, identifique el sistema de origen o responsable y el formato esperado cuando se conozca.

La calidad de los datos debe tratarse con honestidad. Los resultados dependen del contexto, los sistemas existentes y la calidad de las entradas. Si los archivos tienen nombres inconsistentes, los registros contienen vacíos o los campos no se mantienen de forma coherente, indíquelo en el briefing. Esto no hace imposible el proyecto; permite una estimación realista que incluya validación, preparación o un primer alcance más estrecho.

• Enumere cada entrada y salida con su responsable y ubicación.
• Indique si el acceso está disponible, pendiente o es desconocido.
• Anote los volúmenes de datos previstos y la frecuencia de actualización, si se conocen.
• Identifique información sensible, confidencial o restringida.
• Señale carencias de calidad conocidas, duplicados y registros incompletos.

Especifique las salvaguardas y la revisión humana

Las salvaguardas adecuadas forman parte del alcance, no son una consideración posterior. Un briefing de proyecto debe identificar qué acciones puede realizar de forma independiente la automatización propuesta, qué salidas debe revisar una persona y qué acciones están fuera de los límites. Esto es especialmente importante cuando una automatización modifica registros, envía comunicaciones, desencadena trabajo posterior o trata información sensible.

La revisión humana debe describirse operativamente. Indique quién revisa la salida, qué comprueba, cuándo interviene y qué ocurre si la rechaza o corrige. Una afirmación como «humano en el circuito» es demasiado amplia para estimar porque no muestra la carga de revisión, los permisos ni la ruta de retroalimentación.

Identifique también las expectativas de acceso y auditoría que ya se conocen. El briefing no tiene que resolver todos los detalles del diseño de seguridad, pero debe dejar claro que existen requisitos de protección y si hay partes interesadas internas que deben aprobar el acceso, el despliegue o los procedimientos operativos.

• Defina las acciones permitidas, las acciones que requieren revisión y las acciones prohibidas.
• Nombre la función revisora y el punto de revisión previsto.
• Describa el escalado para casos inciertos, incompletos o inusuales.
• Identifique requisitos ya conocidos de aprobación, control de acceso, registro o retención.

Ejemplo: un briefing que puede estimarse

Ejemplo: un equipo empresarial quiere reducir la preparación manual de solicitudes internas de compra. Su briefing dice: «Crear un borrador de registro de solicitud de compra a partir de un formulario de admisión estándar y documentos de respaldo, y dirigirlo después al coordinador de compras para su revisión. El objetivo es que las solicitudes estén listas para revisión de manera más coherente; la automatización no debe enviar ni aprobar compras». Esto es considerablemente más estimable que una solicitud de «automatizar compras».

El flujo actual se registra así: una persona solicitante completa un formulario, adjunta uno o varios documentos y envía el paquete por correo electrónico a compras. Un coordinador lee los materiales, copia campos seleccionados en el sistema de compras, solicita información faltante y dirige la solicitud para su aprobación. Las excepciones conocidas incluyen centros de coste ausentes, adjuntos ilegibles y solicitudes que implican categorías no estándar.

La sección de datos identifica el formulario de admisión, la ubicación de almacenamiento de documentos, el sistema de compras, las personas responsables y la incertidumbre sobre los formatos de los adjuntos. La sección de salvaguardas exige que el coordinador apruebe cada borrador antes de que entre en la ruta de aprobación. La medición en producción se define como la proporción de paquetes enviados que pueden generar un borrador listo para revisión, las categorías de corrección de revisión y el tiempo entre la admisión y la revisión del coordinador.

Este ejemplo no determina por sí solo una estimación única. Sin embargo, permite a quien estima identificar las interfaces que evaluar, las cuestiones de preparación de datos que resolver, el flujo de revisión que diseñar y los límites que evitan que una autoridad de compra no planificada entre en el alcance.

• Objetivo empresarial: preparar registros borrador listos para revisión, no aprobar compras.
• Entradas: formulario estándar y adjuntos; salida: registro borrador para revisión del coordinador.
• Excepciones: campos ausentes, archivos ilegibles y categorías no estándar.
• Salvaguarda: ningún envío ni aprobación autónomos.
• Medición: preparación del borrador, tipos de corrección y tiempos de revisión.

Convierta el briefing en un límite de entrega medible

Una estimación es más sólida cuando el briefing separa lo que se conoce, lo que debe descubrirse y lo que se excluye deliberadamente. Incluya la primera entrega prevista, los sistemas que se espera involucrar, los usuarios esperados y las decisiones que aún esperan confirmación. Esto permite estimar una fase de definición cuando sea necesario, en lugar de fingir que las preguntas sin responder no tienen efecto.

La medición en producción debe incluirse antes de hablar del despliegue. Defina qué se observará una vez que opere la automatización: resultados de finalización, correcciones de revisión, volumen de excepciones, tiempos de procesamiento u otra medida vinculada al objetivo empresarial. La medición no es la promesa de un resultado concreto. Es una forma de determinar si la implementación sigue siendo útil en su contexto operativo real.

Por último, asigne responsabilidades. Un proyecto puede estar bien descrito técnicamente y aun así seguir siendo ambiguo si nadie es responsable del proceso, del acceso a datos, de la revisión humana o de la aceptación del flujo desplegado. Nombrar estas funciones hace que el briefing sea accionable y ayuda a diferenciar el trabajo del proyecto de las decisiones organizativas que deben tomarse por separado.

• Indique el límite de la primera entrega y las exclusiones explícitas.
• Enumere las preguntas abiertas y la persona responsable de resolver cada una.
• Defina medidas de producción vinculadas al objetivo.
• Nombre responsables de decisiones de proceso, acceso a datos, revisión y aceptación.
• Registre dependencias de sistemas existentes, aprobaciones y disponibilidad de entradas.