Plantilla de brief para automatización

Empieza 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 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.

Formule 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 formulación indica una salida, un responsable y un punto de revisión. También da al equipo una base para identificar sistemas, datos, excepciones y medición.

Victor Laybats ofrece 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 el responsable del proceso.
• Describa la salida, recomendación, acción o transferencia concreta esperada.
• Defina qué usuarios o equipos utilizarán el resultado.
• Nombre la decisión o medida operativa que el proyecto debe respaldar.

Describe el flujo de trabajo actual, incluidas las excepciones

Quien estima necesita comprender el trabajo que existe hoy antes de proponer automatización. Por ello, un brief 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 de trabajo sencillo numerado suele ser más útil que un diagrama amplio de procesos con etiquetas sin explicar.

El detalle importante es la variación. Muchos procesos parecen sencillos hasta que el equipo considera información faltante, 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 en la fase del brief. En su lugar, distinga los casos normales de las excepciones conocidas e indique qué debe suceder cuando la automatización no pueda continuar de forma segura. Esto hace visible la incertidumbre sin convertir el brief en una especificación técnica.

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

Haz concretos el acceso y el control de los datos

Un proyecto útil de IA o automatización depende de datos controlados. Para estimar, eso significa más que enumerar las 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 imprecisa a «datos de la empresa» deja sin resolver preguntas importantes.

Describa las entradas y las 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 de flujo de trabajo 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 lagunas o los campos no se mantienen de manera uniforme, regístrelo en el brief. Esto no hace imposible el proyecto; permite una estimación realista que incluya validación, preparación o un primer alcance más reducido.

• Enumere cada entrada y salida con su responsable y ubicación.
• Indique si el acceso está disponible, pendiente o se desconoce.
• 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.

Especifica salvaguardas y revisión humana

Las salvaguardas adecuadas forman parte del alcance, no son una idea posterior. Un brief de proyecto debe identificar qué acciones puede realizar de forma independiente la automatización propuesta, qué salidas deben ser revisadas por una persona y qué acciones quedan fuera de los límites. Esto es especialmente importante cuando una automatización modifica registros, envía comunicaciones, activa 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 vía de retroalimentación.

Identifique también las expectativas de acceso y auditoría que ya se conocen. El brief no tiene que resolver cada detalle de 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 acciones permitidas, acciones que requieren revisión y acciones prohibidas.
• Nombre la función revisora y el punto de revisión previsto.
• Describa el escalado de casos inciertos, incompletos o inusuales.
• Identifique requisitos ya conocidos de aprobación, control de acceso, registro o retención.

Ejemplo: un brief que puede estimarse

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

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

La sección de datos identifica el formulario de entrada, la ubicación de almacenamiento de documentos, el sistema de compras, los responsables y la incertidumbre sobre los formatos de 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 en la revisión y el tiempo entre la recepció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 debe evaluar, las preguntas de preparación de datos que debe resolver, el flujo de revisión que debe diseñar y los límites que impiden que una autoridad de compra no planificada entre en el alcance.

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

Convierte el brief en un límite de entrega medible

Una estimación es más sólida cuando el brief separa lo que se conoce, lo que debe descubrirse y lo que se excluye deliberadamente. Incluya la primera versión prevista, los sistemas que se espera que intervengan, los usuarios previstos y las decisiones que aún esperan confirmación. Esto permite estimar una fase de definición del alcance cuando sea necesaria, en lugar de fingir que las preguntas sin respuesta no tienen efecto.

La medición en producción debe incluirse antes de hablar de despliegue. Defina qué se observará cuando la automatización esté operativa: 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 promete 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 técnicamente bien descrito y, aun así, seguir siendo ambiguo si nadie es responsable del proceso, el acceso a los datos, la revisión humana o la aceptación del flujo desplegado. Nombrar estas funciones hace que el brief sea accionable y ayuda a distinguir el trabajo del proyecto de las decisiones organizativas que deben tomarse por separado.

• Indique el límite de la primera versión 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 las decisiones de proceso, acceso a datos, revisión y aceptación.
• Registre dependencias de sistemas existentes, aprobaciones y disponibilidad de entradas.