Qué hace un ingeniero desplegado de forma avanzada y cuándo lo necesita

Un ingeniero desplegado directamente es un ingeniero de software que trabaja dentro del proceso del cliente en lugar de detrás de tareas pendientes. Se reúne con las personas que utilizarán la herramienta, aprende cómo se realiza realmente el trabajo, desarrolla la primera versión con datos reales y permanece hasta que funciona en las operaciones diarias. Este título proviene de las empresas que venden software complejo a grandes organizaciones, donde un producto solo funciona una vez que alguien lo integra en los sistemas y hábitos del cliente.

Este mismo método de trabajo es adecuado, quizás incluso mejor, para empresas pequeñas y de tamaño medio. Una pequeña empresa rara vez cuenta con un equipo interno de TI capaz de transformar una idea vaga (“¿Puede la IA leer nuestros certificados de proveedores?”) en una especificación técnica. Necesita a una persona que pueda realizar la investigación, escribir el código y asumir la responsabilidad del resultado.

Qué hace realmente este puesto

La mayor parte del trabajo se realiza antes y después de escribir el código. Un proyecto típico pasa por cuatro fases:

• Descubrimiento. Entrevistas con las personas que realizan el trabajo, revisión de los documentos, hojas de cálculo y sistemas reales, y una descripción escrita del proceso actual junto con sus excepciones. Las excepciones son las más importantes, ya que es allí donde la automatización falla.
• Prototipo. Una herramienta funcional con datos reales en cuestión de días, no un conjunto de diapositivas. Es rudimentaria, pero las personas pueden usarla y señalar qué está mal.
• Producción. Control de acceso, manejo de errores, registro de actividades, monitoreo, copias de seguridad, un paso de revisión en el que una persona aprueba los resultados inciertos, y un conjunto de pruebas que demuestra si la herramienta sigue funcionando después de cada cambio.
• Entrega y soporte. Documentación, una breve capacitación para el equipo, y un método acordado para reportar problemas y solicitar cambios.

En qué difiere de un proyecto clásico

En un proyecto de alcance fijo, el cliente escribe los requisitos, el proveedor los implementa y ambas partes discuten sobre su significado. Esto funciona cuando el problema está bien comprendido, como en el caso de un nuevo sitio web o una integración conocida.

Rara vez se comprende bien la automatización con IA desde el principio. Nadie sabe cuántas facturas tienen un formato extraño, con qué frecuencia un proveedor envía una imagen escaneada en lugar de un PDF, o qué regla aplica el contador sin anotarla. Un ingeniero que se involucra desde el inicio descubre esto al trabajar directamente con el material, de modo que el alcance del proyecto se define según las pruebas reales y no según conjeturas.

También difiere de la contratación temporal de personal. Un desarrollador adicional recibe los tickets del líder del equipo. Se espera que un ingeniero desplegado de antemano decida qué se debe desarrollar, se oponga cuando una idea no da resultados y evalúe si el resultado funciona.

Cuando una pequeña empresa lo necesita

Este modelo tiene sentido cuando se cumplen varias de estas condiciones:

• un proceso repetitivo consume horas cada semana: leer documentos, copiar datos entre sistemas, verificar plazos, responder las mismas preguntas;
• los datos se encuentran en muchos lugares: ERP o 1C, archivos de Excel, adjuntos de correo electrónico, carpetas compartidas, papel escaneado;
• alguien ya probó un chatbot o un prototipo de ChatGPT y funciona en demostraciones pero no en casos reales;
• no hay un desarrollador interno que conozca tanto el negocio como la tecnología.

Tiene menos sentido cuando el proceso cambia cada mes, cuando no hay nadie a tu lado que pueda dedicar unas horas a la semana a responder preguntas, o cuando ya existe una herramienta lista para usar que hace el trabajo. En ese caso, compra la herramienta.

Qué esperar en las primeras dos semanas

Comenzamos nuestros proyectos con un período fijo de dos semanas a precio fijo. Al final de este tiempo deberías contar con tres cosas: un mapa escrito del proceso con las excepciones encontradas en los datos reales, un prototipo que funcione con una muestra de tus documentos o registros, y una estimación honesta de cuánto tiempo tomaría la producción, incluyendo aquello que no debería automatizarse en absoluto.

Después de eso decides si deseas continuar. Un proyecto completo suele durar de dos a seis semanas, dependiendo de cuántos sistemas estén involucrados y cuánta revisión necesiten los resultados.

Preguntas que hacer antes de contratar a alguien

• ¿Trabjará el ingeniero con nuestros datos reales desde la primera semana, y cómo se controla el acceso?
• ¿Cómo sabremos que la herramienta es correcta? Solicitemos el conjunto de pruebas y las métricas, no promesas. Nuestras notas sobre evaluaciones y revisión humana describen cómo sería eso.
• ¿Dónde se ejecutan los modelos, y sale alguno de nuestros datos de nuestra infraestructura? Para archivos confidenciales, consulte IA local para documentos confidenciales.
• ¿Qué sucede después de la entrega: quién lo arregla cuando un proveedor cambia el formato de su factura?

Si las respuestas son vagas, el proyecto también lo será. Si desea conocer un proceso concreto, nuestra página de ingeniería con despliegue avanzado explica cómo llevamos a cabo estos proyectos, y puede respondernos a través del formulario de contacto.