Cómo un Forward Deployed Engineer identifica oportunidades reales de IA

Una empresa decide que quiere aplicar inteligencia artificial a su operación. Reúne al equipo, describe el problema y, casi de inmediato, la conversación se llena de soluciones: un agente, un copiloto, un modelo conectado a los datos internos o una plataforma que promete automatizar el proceso completo.

En ese momento se está intentando elegir una solución antes de conocer el trabajo que debe cambiar.

Cuando un Forward Deployed Engineer, o FDE, llega al lugar donde se realiza el trabajo, su primera tarea no es escoger la tecnología sino entender cómo se produce hoy el resultado que la organización quiere mejorar.

Antes de iniciar un diagnóstico completo, necesita comprobar que existe un responsable capaz de decidir, que podrá observar el trabajo y acceder a la información necesaria, y que el problema tiene suficiente relevancia como para justificar la intervención.

Eso significa entrar en la operación, observar casos reales y construir con sus responsables un diagnóstico suficientemente preciso para tomar una decisión. El diagnóstico busca responder tres preguntas:

• ¿Qué resultado necesita mejorar la organización?

• ¿Cómo se produce hoy ese resultado?

• ¿Qué factores limitan su desempeño?

Con esas respuestas, el FDE puede comparar posibles intervenciones y determinar cuál merece ser probada. Sin este trabajo previo, es posible construir una solución técnicamente correcta para una parte del proceso que no determina el resultado.

EMPEZAR POR SABER QUÉ MEJORAR

“Queremos usar IA en atención al cliente” expresa una intención, pero todavía no define un problema.

Puede significar que la empresa quiere responder más rápido, atender un mayor volumen de requerimientos sin aumentar el equipo en la misma proporción, reducir respuestas incorrectas o resolver más requerimientos en el primer contacto. Cada resultado conduce a una intervención distinta.

Por eso el FDE empieza por identificar qué debe mejorar y qué restricciones no pueden ignorarse.

Por ejemplo: “Queremos reducir el tiempo de respuesta de los requerimientos complejos sin aumentar el riesgo de entregar información incorrecta”. Ahora existe un resultado observable y una condición que la solución debe respetar.

Esta definición también evita confundir actividad con valor. Un proceso puede ser lento, manual o incómodo y, aun así, no ser una prioridad. Otro puede parecer eficiente, pero generar errores costosos, retrasar ingresos o concentrar una decisión crítica en una sola persona.

No se busca la tarea más fácil de automatizar, sino qué se debe cambiar para mejorar un resultado que le importa a la organización.

OBSERVAR EL TRABAJO EN DONDE OCURRE

Una vez definido el resultado, el FDE revisa casos reales de principio a fin.

Los procedimientos documentados muestran cómo debería funcionar una operación. El trabajo cotidiano revela cómo funciona en realidad: archivos que llegan por distintos canales, información que se copia entre sistemas, aprobaciones por mensajes, datos que alguien corrige a mano y excepciones que solo ciertas personas saben resolver.

Si el diseño parte únicamente del procedimiento documentado, deja fuera las excepciones, correcciones y atajos con los que la operación consigue funcionar. Esos casos reaparecen cuando la solución entra en producción.

Para reconstruir el proceso, el FDE entrevista a sus responsables y a quienes lo ejecutan, acompaña algunos casos mientras ocurren y revisa los sistemas que intervienen: ERP, CRM, documentos, correos, hojas de cálculo o aplicaciones internas. Contrasta lo que las personas explican con los registros disponibles y presta atención a los pasos que no aparecen en el procedimiento formal.

A partir de esa observación busca entender:

• qué evento inicia el trabajo;

• qué información necesita cada persona y dónde la encuentra;

• qué decisiones se toman y con qué criterio;

• qué reglas son explícitas y cuáles dependen de experiencia;

• qué excepciones aparecen y quién sabe resolverlas;

• dónde se acumulan esperas, errores o retrabajo;

• qué sistemas, permisos y controles intervienen;

• qué incentivos condicionan el proceso y qué cambios podrían encontrar resistencia;

• quién responde por el resultado final.

El objetivo, más que producir un diagrama bonito, es descubrir qué explica el desempeño actual y qué tendría que cambiar para mejorarlo.

En ocasiones, la causa está lejos de la tarea que primero llamó la atención. Una demora atribuida a la redacción de respuestas puede provenir de información dispersa, de una aprobación sin responsable claro o de una clasificación incorrecta al comienzo del proceso. Automatizar la redacción haría más rápida una actividad, pero no necesariamente aceleraría el resultado completo.

CONSTRUIR UNA LÍNEA BASE

Después de entender el recorrido del trabajo, hay que medir su situación actual.

Sin una línea base, una demostración puede parecer impresionante sin que sepamos si produjo una mejora importante. El FDE necesita estimar el volumen de casos, el tiempo de ejecución y de espera, la frecuencia de errores, el retrabajo, las horas de supervisión y las consecuencias económicas u operativas de las demoras.

No toda la información estará disponible. En algunos casos habrá registros confiables; en otros será necesario observar una muestra, reconstruir datos o trabajar con rangos. Lo importante es hacer visibles los supuestos y el nivel de confianza de cada estimación.

Tampoco todos los beneficios se convierten directamente en dinero. Reducir riesgos, responder antes a un cliente o disponer de mejor información para decidir también puede justificar una intervención. Pero incluso esos beneficios necesitan una forma de comprobarse.

Esta etapa puede llevar a una conclusión incómoda: el problema no cuesta tanto como se suponía o resolverlo exige cambios que la organización todavía no está preparada para sostener. Descubrirlo antes de construir evita invertir en una solución cuyo retorno solo existía en la presentación.

COMPARAR INTERVENCIONES, NO PRODUCTOS

Solo después de entender el resultado, el proceso y la línea de base tiene sentido diseñar alternativas.

En esta etapa confluyen las dos partes del trabajo del FDE. El conocimiento del negocio le permite entender qué resultado importa, cuánto valor podría generar y qué cambios puede absorber la operación. El criterio técnico le permite evaluar los datos, las integraciones, los permisos, los mecanismos de automatización, los controles y la ruta hacia producción.

Durante el diagnóstico todavía no construye la solución, pero evalúa cada alternativa desde la perspectiva de quien tendrá que integrarla, medirla y hacerla funcionar.

Una de ellas puede usar IA, pero no debe ser la única por defecto. A veces la mejor intervención consiste en eliminar una aprobación, aclarar una responsabilidad, ordenar los datos o integrar dos sistemas. En otros casos conviene una automatización convencional porque las reglas son estables y la previsibilidad importa más que la flexibilidad.

Cuando el trabajo depende de interpretar información no estructurada o de asistir decisiones con contexto, un copiloto puede ser adecuado. Si el sistema necesita ejecutar varios pasos, usar herramientas y gestionar estados con cierto grado de autonomía, puede tener sentido evaluar un agente. Y si el costo, el riesgo o las dependencias superan el beneficio posible, la decisión correcta puede ser no intervenir todavía.

En la práctica, la intervención elegida puede combinar varias de estas capacidades. Un mismo flujo de trabajo puede utilizar reglas para los pasos predecibles, integraciones para mover información, IA para interpretar casos ambiguos y personas para asumir decisiones sensibles.

Estas alternativas no forman una escala en la que la opción más sofisticada sea necesariamente la mejor. La elección implica evaluar cuánto costará la solución, qué riesgos asumirá la organización, cuánto tendrá que cambiar la forma de trabajar y quién responderá por el resultado.

Para compararlas, el FDE considera cuatro dimensiones:

• Valor: el beneficio esperado, la inversión inicial, los costos recurrentes y el tiempo hasta obtener valor.

• Viabilidad: la disponibilidad y calidad de los datos, la complejidad de las integraciones, la capacidad de adopción y la existencia de una ruta creíble hacia producción.

• Riesgo: las posibles consecuencias técnicas y operativas, la supervisión humana necesaria, la responsabilidad sobre el resultado y la facilidad para corregir o revertir el cambio.

• Aprendizaje: las incertidumbres que la intervención permitiría resolver, la evidencia que podría producir y el conocimiento que dejaría para decisiones o despliegues posteriores.

El nivel de confianza atraviesa las cuatro dimensiones: cada estimación debe indicar qué evidencia la respalda y cuánta incertidumbre contiene.

El ROI forma parte de esta comparación, pero no decide por sí solo. Una alternativa puede prometer un retorno alto y depender de datos que no existen, una integración incierta o un cambio de responsabilidades que nadie ha acordado asumir.

EL PRIMER ENTREGABLE ES UNA HERRAMIENTA PARA DECIDIR

El resultado del diagnóstico no debería ser una lista de posibles usos de IA sino un mapa de decisión que conecte el trabajo actual con alternativas concretas y con las condiciones necesarias para avanzar.

El mapa muestra:

• el resultado que se quiere mejorar;

• la línea base;

• las causas de la pérdida de valor;

• las alternativas consideradas;

• los beneficios, costos y riesgos de cada una;

• la evidencia que falta;

• las condiciones necesarias para avanzar.

El FDE puede recomendar un camino, pero no sustituye la decisión empresarial. Quienes operan el proceso y responden por sus resultados deben elegir conociendo los beneficios, los costos, los riesgos y los supuestos involucrados.

La decisión puede ser construir, ejecutar una prueba acotada, resolver primero una dependencia o no intervenir por ahora. El diagnóstico cumple su función cuando permite explicar por qué una de esas alternativas tiene más sentido que las demás con la evidencia disponible.

Así termina esta primera intervención del FDE: una intención todavía difusa de usar IA se ha convertido en una decisión que la organización puede defender con evidencia.

Publicado originalmente en LinkedIn.