AUTOMATIZACIÓN DE PROCESOS
Antes de automatizar con IA, revisa cómo funciona el proceso
Guía práctica para preparar una automatización antes de elegir herramientas.
Una empresa recibe solicitudes por correo electrónico. Quien las tramita abre el mensaje y descarga el archivo. Después comprueba si falta algún dato. Parte de la información termina en una hoja de cálculo y luego vuelve a copiarse en el ERP. Si el documento está incompleto, hay que escribir al remitente. Algunos importes requieren autorización. Al terminar, otra persona recibe un correo para continuar el trabajo.
La dirección ve cuánto tiempo consume esta forma de trabajar y plantea automatizarla. Una opción es conectar el correo con el ERP. También aparece la posibilidad de utilizar OCR. En algún momento alguien propone incorporar IA. La conversación empieza a centrarse en herramientas antes de aclarar cómo debería funcionar realmente el trabajo.
Todavía faltan varias decisiones que condicionan el proyecto.
Primero hay que saber qué documentos admite la empresa. También debe estar claro qué datos son obligatorios. Las excepciones necesitan un criterio de revisión. Si dos archivos contienen información distinta, alguien debe saber cuál consultar. La hoja de cálculo intermedia también merece una explicación. Las autorizaciones por importe también tienen que responder a una regla clara. Y tiene que existir una persona responsable del trabajo completo.
Sin esas decisiones, todavía es pronto para automatizar. La tecnología puede ejecutar con mucha rapidez instrucciones que la empresa todavía no ha terminado de definir.
Automatizar un trabajo mal definido puede multiplicar sus errores. El problema aparece cuando esos errores se repiten a mayor escala y nadie tiene claro dónde corregirlos.
Si el trabajo está mal definido, automatizarlo puede hacer que los mismos errores se repitan más rápido y a mayor escala.
En un proyecto de este tipo, antes de elegir una herramienta hay que entender el trabajo que se quiere automatizar. Eso exige revisar qué ocurre desde que llega una solicitud hasta que queda resuelta . Después se decide qué tecnología encaja.
Automatizar una tarea y automatizar un proceso son cosas distintas
La automatización de procesos empresariales utiliza software para ejecutar de forma sistemática parte del trabajo de una empresa. IBM define la BPA —Business Process Automation— como una estrategia para automatizar procesos complejos y repetitivos. Esa definición obliga a mirar el trabajo completo y no solo una tarea aislada.
Una tarea puede ser descargar un archivo. El proceso incluye lo que ocurre antes y después de esa descarga. Empieza con una necesidad concreta y termina cuando esa necesidad queda resuelta. En medio puede haber comprobaciones. Puede haber también una aprobación o una excepción que obligue a detener el trabajo.
Esa diferencia importa en cuanto se diseña una automatización.
Descargar un archivo adjunto es una tarea dentro de la gestión de una factura. Responder una llamada forma parte de la gestión de una cita. Enviar un mensaje a un proveedor puede ser solo una parte de la resolución de una incidencia.
Automatizar una tarea puede ahorrar tiempo sin resolver el problema principal. Un archivo puede descargarse solo y seguir llegando incompleto. Un contacto puede entrar en el CRM y quedarse sin asignar. Una incidencia puede clasificarse automáticamente y aun así requerir una autorización que nadie ha definido.
La parte automatizada debe terminar en algo comprobable. Para decidir hasta dónde llegar, hay que saber qué debe quedar resuelto al final. En una primera fase suele ser preferible acotar bien el alcance.
Una integración no automatiza por sí sola todo el trabajo
En estos proyectos se mezclan con frecuencia conceptos distintos. Conviene separarlos porque cada uno resuelve una necesidad diferente.
Digitalizar consiste en pasar información o una actividad a formato digital. Sustituir una ficha en papel por un formulario web es un ejemplo sencillo. El dato queda disponible en digital, pero el trabajo posterior puede seguir siendo manual.
Integrar dos aplicaciones permite que intercambien datos. Por ejemplo, un formulario puede crear un contacto en el CRM sin que nadie copie la información. Aun así, las tareas posteriores pueden seguir dependiendo del equipo.
Automatizar implica que ciertas acciones se ejecuten sin repetirlas manualmente cada vez. Una solicitud puede comprobarse antes de crear un expediente. Si falta un dato, se puede detener el alta y pedirlo. Cuando la información está completa, el registro puede continuar.
La IA encaja mejor cuando la entrada no sigue siempre el mismo formato. Puede ayudar a interpretar un correo o extraer información de un documento. También puede preparar un resumen para revisión. Su utilidad depende de lo que haya que entender en cada punto. La IA amplía las tareas que pueden tratarse automáticamente. Las reglas del trabajo siguen teniendo que estar definidas.
Cuando una condición es inequívoca, una regla suele ser suficiente. Si toda factura superior a 5.000 euros necesita aprobación, no hace falta un modelo de lenguaje para comprobar el importe. La IA puede ayudar cuando hay que interpretar texto o documentación variable. Ambos recursos pueden convivir sin utilizar IA en tareas que una regla resuelve mejor.
Elegir la herramienta antes de entender el trabajo
Es fácil comparar herramientas porque se pueden probar y enseñar en una demo. Entender cómo trabaja realmente una empresa exige más esfuerzo. Hay hábitos que nunca se documentaron. También hay excepciones que una persona resuelve de memoria. Si eso no se revisa primero, el software se elige con una imagen incompleta.
La empresa pregunta qué plataforma necesita. El proveedor enseña una demostración con entradas limpias y reglas claras. Al llevarla al trabajo diario aparecen situaciones que esa demo no contemplaba.
Un campo marcado como opcional puede ser imprescindible para contabilidad. Algunos clientes envían documentos con nombres distintos. En otra parte del trabajo se corrigen errores sin dejar registro. También puede ocurrir que el ERP permita importar datos, pero no exactamente como se había previsto. Esas diferencias condicionan la implantación.
Ese es el trabajo que la automatización tendrá que soportar.
Una demostración solo enseña lo que la tecnología puede hacer en unas condiciones concretas. Antes de trasladarla a una empresa hay que comprobar si esas condiciones existen. Si no existen, toca definirlas o cambiar el planteamiento.
Thomas H. Davenport y David Brain defendían en Harvard Business Review que conviene mejorar los procesos antes de automatizarlos. La recomendación sigue siendo aplicable con las herramientas actuales. La IA permite abordar tareas que hace unos años eran difíciles de automatizar, pero aumenta la necesidad de definir con precisión qué puede hacerse automáticamente y qué necesita revisión.
Antes de automatizar, separa los problemas de organización de los técnicos
El trabajo manual puede tener dos orígenes distintos. A veces la empresa ha organizado mal una tarea. Otras veces el trabajo está bien definido, pero las aplicaciones no se comunican. En muchos proyectos aparecen ambas situaciones a la vez. Automatizar un paso innecesario sigue siendo una mala inversión . Si dos áreas piden el mismo dato, primero conviene comprobar si una de esas peticiones puede desaparecer. Una aprobación que no reduce ningún riesgo también merece revisión. Un informe que nadie consulta merece la misma revisión. La tecnología debe entrar después de estas decisiones, porque automatizar algo innecesario solo hace permanente un problema que podía haberse eliminado.
Señales de que primero hay que revisar el trabajo
- La misma información se solicita varias veces.
- Hay aprobaciones cuya utilidad nadie puede explicar.
- Dos personas comprueban lo mismo.
- El resultado cambia según quién realiza la tarea.
- La información entra por varios canales y después hay que reunirla manualmente.
- Nadie responde por el trabajo completo.
- Las incidencias se resuelven sin registrar por qué ocurrieron.
- Algunos pasos se mantienen únicamente por costumbre.
Señales de que falta una integración o una función técnica
- Los datos se copian manualmente entre aplicaciones.
- Una tarea puede quedar bloqueada sin que nadie reciba un aviso.
- Los documentos llegan por varios canales y luego hay que localizarlos manualmente.
- Para revisar un expediente hay que abrir varias herramientas.
- Hay APIs o funciones de importación disponibles que todavía no se utilizan.
- Las mismas respuestas se redactan una y otra vez.
- No queda registrado quién modificó un dato o autorizó una acción.
Siete preguntas antes de automatizar
Para empezar un análisis no hace falta tener un procedimiento perfecto. Sí hace falta responder algunas preguntas básicas. De lo contrario, el alcance cambia durante la implantación y el presupuesto deja de reflejar el trabajo real.
En Yarvia utilizamos siete preguntas antes de diseñar la solución .
1. ¿Qué debe quedar resuelto al final?
“Ahorrar tiempo” dice poco sobre lo que debe hacer una automatización. Es mejor definir una salida comprobable. Una factura puede quedar registrada y pendiente de validación. Una cita puede quedar confirmada. Un documento puede quedar clasificado y listo para revisión.
Si la salida no está definida, cada persona puede interpretar de forma distinta cuándo ha terminado su parte.
2. ¿Dónde empieza y dónde termina?
“Gestionar correos” abarca demasiado. En cambio, tramitar las solicitudes de alta que llegan por correo hasta registrarlas permite fijar un principio y un cierre. Si falta información, la solicitud puede quedar pendiente hasta que se complete.
Acotar el inicio y el final evita intentar automatizar demasiadas tareas en una sola fase.
3. ¿Qué datos hacen falta para continuar?
Antes de diseñar reglas hay que saber qué información es imprescindible. Los datos opcionales pueden tratarse aparte. Si algún dato puede deducirse, también debe quedar claro cuándo esa deducción es aceptable y cuándo alguien tiene que confirmarla.
En una clínica puede bastar con identificar al paciente y disponer de un medio de contacto para ciertas tareas administrativas. Una gestoría puede necesitar el proveedor y el número de factura antes de registrar un documento. Cada automatización debe partir de los datos que necesita de verdad para continuar.
Si falta un dato obligatorio, la automatización debe detener esa parte del trabajo y solicitarlo o dejar una tarea para revisión.
4. ¿Las reglas pueden explicarse con claridad?
Una regla puede depender de varias condiciones y seguir siendo válida para automatizarse. El problema aparece cuando solo una persona sabe aplicarla y nunca se ha explicado por qué.
Ese conocimiento tiene que convertirse en criterios que otras personas puedan revisar. Algunas decisiones acabarán como reglas. Otras necesitarán interpretación. También habrá decisiones que seguirán requiriendo aprobación.
5. ¿Sabemos qué hacer cuando algo sale de lo habitual?
Además del funcionamiento normal, hay que definir cómo se tratan las excepciones.
Un archivo ilegible requiere una actuación distinta de una factura duplicada. Una solicitud urgente tampoco se gestiona igual que una solicitud incompleta.
Cada excepción necesita una respuesta definida. A veces se puede corregir automáticamente. En otras situaciones habrá que pedir un dato o dejar la tarea para una persona.
6. ¿Quién puede decidir cambios en esta forma de trabajar?
Tiene que existir una persona con autoridad para resolver dudas sobre las reglas y aprobar cambios durante la implantación. El equipo técnico puede plantear opciones, pero no debería inventar criterios de negocio cuando aparezca una excepción.
Si nadie asume esa responsabilidad, las decisiones terminan aplazándose o recayendo en quien está implantando la solución.
7. ¿Sabemos cómo funciona hoy?
Para saber si una automatización mejora el trabajo hay que conservar una referencia anterior. Puede ser suficiente medir el volumen y el tiempo que tarda una tarea. En otros proyectos interesará registrar errores o esperas. La guía sobre cómo medir si una automatización funciona explica cómo elegir una referencia inicial y qué métricas tienen sentido según el objetivo.
Las horas ahorradas son solo una medida posible. En algunos procesos importará más responder antes. En otros será más relevante reducir errores o evitar que una solicitud quede olvidada.
Las excepciones condicionan el coste del proyecto
Un presupuesto sencillo suele describir qué ocurre cuando todo llega correctamente. En la práctica, el coste aumenta cuando aparecen documentos incompletos o datos que no cuadran. También hay que prever qué sucede si una entrada llega duplicada o en un formato inesperado.
Por eso dos automatizaciones parecidas sobre el papel pueden exigir cantidades de trabajo muy distintas.
Pensemos en la entrada de facturas. Con un PDF legible se pueden extraer los datos y comprobar si el proveedor ya existe. Después se revisa si esa factura está duplicada. La dificultad aumenta cuando llega una fotografía borrosa o varias facturas dentro del mismo archivo. También puede aparecer un abono o una discrepancia con el pedido. Cada una de esas situaciones obliga a decidir qué hacer antes de registrar nada.
La extracción de datos es solo una parte. También hay que decidir qué ocurre cuando falta un campo o el importe no coincide con otra fuente. Si el documento no ofrece suficiente seguridad, el trabajo debe detenerse antes de crear un registro incorrecto.
Ante una excepción suelen existir varias respuestas posibles :
Si existe una regla inequívoca, la corrección puede hacerse automáticamente. Cuando falta información, se solicita antes de continuar. Si hace falta una decisión, la tarea queda pendiente para revisión. Y cuando no es seguro seguir, el tratamiento se detiene.
La revisión por una persona forma parte del diseño cuando la decisión lo exige. Tiene que decidirse desde el principio qué situaciones pueden resolverse automáticamente y cuáles deben quedar pendientes. Añadir esta revisión al final suele obligar a rehacer parte de la automatización.
Ejemplos en distintos tipos de empresa
En una gestoría, una factura puede registrarse automáticamente cuando cumple las comprobaciones definidas. Si falta el número de factura, se puede pedir ese dato. Una discrepancia fiscal debe quedar pendiente para quien corresponda.
En una administración de fincas, una incidencia sencilla puede asignarse según reglas acordadas. Una fuga de agua tendrá otra prioridad. Si el trabajo requiere una autorización, la automatización debe esperar a que quede registrada.
En una clínica, una consulta administrativa puede recibir una respuesta inicial. Una pregunta sobre el tratamiento requiere otra gestión y debe llegar al profesional adecuado. El mismo mecanismo de seguimiento comercial no debería responder cuestiones asistenciales.
En los tres ejemplos se automatiza parte del trabajo, pero el punto en el que una persona debe intervenir cambia.
La IA necesita reglas de negocio definidas
Los modelos actuales pueden interpretar texto y extraer información de entradas poco estructuradas. Esa capacidad puede ahorrar trabajo cuando llegan correos o documentos que no siguen siempre el mismo formato. También puede servir para preparar una respuesta o un resumen para revisión.
La IA no resuelve una política que la empresa todavía no ha decidido. Si dos responsables aplican prioridades distintas, un modelo solo ocultará esa discrepancia detrás de una respuesta automática.
Algo parecido ocurre con las autorizaciones. Si nadie ha definido cuándo hacen falta, un agente tampoco dispone de un criterio fiable. En captación ocurre lo mismo: antes de automatizar el seguimiento hay que acordar qué considera la empresa un contacto válido.
La IA puede manejar información ambigua. La empresa sigue teniendo que definir los criterios con los que se trabaja.
Conviene elegir la herramienta según la decisión que haya que resolver. Las reglas sirven para condiciones claras. La IA puede intervenir cuando hay que interpretar información. Las decisiones sensibles necesitan la revisión prevista por la empresa.
- Las integraciones intercambian datos entre aplicaciones.
- Las reglas resuelven condiciones inequívocas.
- La IA interpreta información no estructurada o prepara una propuesta para revisión.
- Las decisiones sensibles quedan pendientes de la persona responsable.
- Los registros permiten consultar después qué ocurrió.
Cómo preparamos una automatización en Yarvia
Antes de diseñar la parte técnica revisamos cómo se realiza hoy el trabajo. Esa revisión debe dejar claro qué entra en el proyecto y qué queda fuera.
1. Revisar cómo se trabaja de verdad
La explicación inicial suele simplificar lo que ocurre en el día a día. Para entenderlo hay que revisar ejemplos reales y hablar con las personas que realizan la tarea. Los correos o registros existentes ayudan a comprobar qué pasos se repiten de verdad.
También buscamos correcciones manuales que nunca se incorporaron al procedimiento. Si existe una hoja paralela o una forma informal de resolver incidencias, tiene que aparecer en el análisis. De lo contrario, la automatización se diseñará sobre una versión incompleta del trabajo.
2. Medir el volumen y el tiempo que consume
El volumen permite saber si el esfuerzo de automatizar tiene sentido. Procesar cincuenta documentos al mes plantea un proyecto distinto de procesar dos mil. El tiempo empleado también importa, especialmente cuando una tarea obliga a esperar respuestas o repetir comprobaciones.
También revisamos cuántas veces una tarea cambia de persona. Si para completarla hacen falta varios correos internos, esa coordinación debe tenerse en cuenta.
3. Quitar pasos que ya no hacen falta
Antes de desarrollar nada revisamos si hay duplicidades. También comprobamos si se puede utilizar una única entrada en lugar de varias. Si una aprobación dejó de tener sentido, debe resolverse antes de automatizarla.
Cada paso que desaparece reduce trabajo de desarrollo y mantenimiento. El número de acciones de una automatización no mide su calidad. A veces la mejor mejora consiste precisamente en eliminar tareas.
4. Definir las reglas y las excepciones
Primero se separan las decisiones que pueden expresarse con una regla. Las que dependen de interpretar un texto pueden apoyarse en IA. Las decisiones sensibles se dejan pendientes de aprobación. Si una regla todavía no está definida, la empresa tiene que resolverla antes de automatizarla.
De este modo, el equipo técnico trabaja con criterios ya acordados durante la implantación.
5. Diseñar qué ocurrirá en cada punto
Con las reglas claras se define qué ocurre desde la entrada hasta el cierre. En cada punto se especifica qué aplicación interviene y qué dato debe quedar registrado.
También se decide cuándo debe detenerse el trabajo. Si alguien tiene que validar algo, esa persona debe recibir la información necesaria para decidir. Los errores técnicos necesitan una salida prevista para que una tarea no quede bloqueada sin aviso.
6. Acotar una primera fase viable
La primera versión no tiene por qué resolver todas las excepciones. Es preferible cubrir bien el trabajo más frecuente y dejar una vía clara para aquello que todavía necesita revisión.
Esa primera fase permite comprobar si el planteamiento funciona con datos reales antes de ampliar el alcance.
7. Medir después de implantar
Después del lanzamiento hay que revisar los errores y comprobar los tiempos reales. También hay que actualizar la solución cuando cambian las aplicaciones o sus APIs. Si la empresa modifica una regla de negocio, la solución también necesita actualizarse.
Una automatización necesita mantenimiento. Si cambia la forma de trabajar, habrá que revisar la solución.
Ejemplo: automatizar la entrada de documentos por correo
Volvamos al correo del inicio.
Hoy una persona abre cada mensaje y descarga el documento. Comprueba si están los campos necesarios. Después copia parte de los datos antes de registrarlos en el sistema. Si falta información, escribe al remitente. Determinados importes necesitan una aprobación adicional.
Copiar todos esos pasos tal cual sería la opción más rápida de diseñar, pero conservaría tareas que quizá ya no hacen falta.
Al revisar el trabajo aparece el motivo de varias tareas. La hoja de cálculo existe porque algunas personas no consultan el ERP. El cambio de nombre facilita encontrar archivos en una carpeta compartida. También se descubre que la aprobación por importe se aplica de manera distinta según el proveedor. Los correos incompletos tampoco se responden siempre de la misma forma.
Con esas decisiones aclaradas, el trabajo puede plantearse de otra manera:
El correo entra en una bandeja controlada. Primero se identifica el tipo de mensaje. Después se extraen los datos del documento. Si falta un campo obligatorio, se pide antes de continuar. El ERP se consulta antes de crear el registro. Las reglas de aprobación se aplican con los criterios acordados. Las excepciones quedan pendientes para quien deba revisarlas. El documento se vincula al expediente. El remitente recibe la respuesta que corresponda. Al final queda registrado lo ocurrido.
La hoja intermedia puede desaparecer si ya no cumple ninguna función. También puede dejar de ser necesario renombrar archivos manualmente. La aprobación por importe pasa a seguir una regla escrita. La IA puede ayudar a interpretar el correo o extraer datos, mientras las discrepancias fiscales siguen la revisión definida por la empresa.
La mejora aparece al revisar por qué existía cada tarea. Después se automatizan únicamente las que siguen siendo necesarias.
Cuándo es mejor esperar
Hay procesos que todavía no justifican una automatización a medida. A veces es mejor resolver primero un problema de organización. En otros casos el volumen de trabajo todavía no compensa desarrollar una solución.
Un proceso con poco volumen puede tardar demasiado en amortizar el coste de desarrollo y mantenimiento. También conviene esperar si la forma de trabajar va a cambiar a corto plazo.
También conviene frenar el proyecto si nadie sabe qué hacer con las excepciones. Puede ocurrir además que la aplicación principal no permita un acceso fiable. Mientras esas cuestiones sigan abiertas, el software acabaría ejecutando reglas que la empresa todavía no ha definido.
En algunos casos basta con una mejora sencilla. Un formulario mejor configurado puede eliminar varias correcciones posteriores. También puede ser suficiente aprovechar una función que ya existe en el ERP o crear una bandeja compartida.
Hay decisiones que deben mantener la aprobación correspondiente aunque técnicamente pudieran automatizarse. Esa elección depende del impacto de un error y de las obligaciones que tenga la empresa en ese proceso.
Posponerla puede evitar un proyecto cargado de excepciones desde el primer día.
Qué revisar antes de preparar un presupuesto
Una reunión inicial permite saber si el proyecto parece viable, pero un presupuesto serio requiere conocer cómo se trabaja en la práctica. Dos proyectos que leen facturas y las registran en un ERP pueden tener un esfuerzo muy distinto. En uno, los proveedores son recurrentes y los formatos apenas cambian. En otro hay varios formatos y cada documento debe compararse con un pedido. Si además el software ofrece pocas opciones de integración, el desarrollo cambia por completo. Por eso el presupuesto debe apoyarse en el trabajo real que habrá que resolver.
- Resultado que debe quedar resuelto.
- Punto de inicio y condición de cierre.
- Volumen habitual y épocas con más carga.
- Entradas que recibe el proceso y calidad de esos datos.
- Aplicaciones que intervienen y opciones reales de integración.
- Reglas de negocio que ya están definidas.
- Excepciones habituales y situaciones de mayor riesgo.
- Datos personales y permisos de acceso.
- Tiempo actual y errores que se producen.
- Trabajo incluido en la primera fase.
- Necesidades de supervisión y mantenimiento.
- Criterios para aceptar la implantación.
Primero quita trabajo innecesario
La pregunta sobre la herramienta llega después.
Primero hay que decidir qué trabajo merece la pena conservar. Después se revisan las decisiones que pueden convertirse en reglas. Las excepciones que necesitan revisión deben quedar previstas antes de desarrollar.
Una empresa automatiza para reducir trabajo innecesario o responder mejor. También puede hacerlo para disminuir errores en tareas repetitivas. El beneficio tiene que estar ligado a un problema concreto.
A veces bastará con una integración sencilla. En otros proyectos hará falta extraer información de documentos o interpretar texto con IA. También habrá procesos para los que todavía sea mejor seguir trabajando de forma manual.
La tecnología debe elegirse después de entender el trabajo y acordar quién puede tomar cada decisión.
Preguntas frecuentes
Estas son algunas dudas habituales antes de iniciar un proyecto de automatización.
Fuentes
- Google Search Central — Crear contenido útil, fiable y centrado en las personas. La guía explica que Google prioriza contenido creado para ayudar a los usuarios, con análisis original, experiencia y fuentes claras. También aclara que no existe un recuento de palabras preferido. Consultar fuente
- Google Search Central — Google's Guide to Optimizing for Generative AI Features on Google Search. Recomienda crear contenido propio, útil y no comoditizado, con un punto de vista que no se limite a resumir lo que ya existe. Consultar fuente
- IBM — ¿Qué es la automatización de procesos empresariales? Define la automatización de procesos empresariales como el uso de software para automatizar procesos complejos y repetitivos. Consultar fuente
- Davenport, Thomas H. y David Brain — Antes de automatizar los procesos de su empresa, busque formas de mejorarlos. Harvard Business Review, 13 de junio de 2018. Consultar fuente
