Qué procesos merece la pena automatizar y cómo reconocerlos

Cuatro preguntas con las que usted mismo puede cribar su trabajo diario: si es una cadena con un resultado, si la máquina recibe datos o una imagen, si el paso decide algo sobre una persona, y si el proceso ya tiene un plazo externo.

La pregunta «qué deberíamos automatizar» suele hacerse demasiado tarde, porque da por hecho que la respuesta es una lista de herramientas. En la práctica, la mayor parte de los proyectos de automatización que fracasan han empezado con la herramienta correcta puesta encima de un trabajo mal elegido, y precisamente la elección, no la herramienta, decidió el resultado.

Este artículo no intenta definir qué es la automatización de procesos de negocio, porque la definición no decide nada; en su lugar da cuatro preguntas con las que usted mismo puede cribar su trabajo diario, y después de cada pregunta muestra cómo se ve un caso que la supera y un caso que no. Cribar no cuesta nada y ocupa una tarde, pero ahorra bastante más que cualquier comparación de herramientas, porque responde a la pregunta más temprana de la cadena.

Primera pregunta: ¿es una cadena con un resultado o una sucesión de clics?

Esta es la frontera que más decide, y conviene trazarla con precisión: un proceso es una cadena de acciones que tiene datos de entrada, un resultado y un responsable: emitir la factura a partir del pedido, dar de alta a un empleado nuevo, el camino de la solicitud del cliente desde el formulario hasta la respuesta. Un procedimiento, o sea una acción suelta, es cómo se da un paso concreto: dónde hay que hacer clic, qué hay que copiar, en qué campo hay que poner el número.

Se pueden automatizar las dos cosas, pero el retorno difiere varias veces, y precisamente por eso el orden importa: si usted automatiza la cadena, cambia el resultado — el documento llega a contabilidad por sí solo, y ya nadie lo vuelve a copiar. Si usted automatiza una sucesión de clics, acelera un paso de una cadena que, en lo demás, sigue igual, y el beneficio es exactamente tan grande como era la parte de ese único paso.

El modo práctico de reconocerlo es preguntar simplemente qué ocurre después con el resultado, y la respuesta suele decirlo todo: si es «entonces alguien coge este archivo y lo mete en otro sistema», la cadena continúa y automatizar un solo paso significa desplazar el cuello de botella, no quitarlo. Si la respuesta es «entonces el trabajo está terminado y el resultado está en el sistema», usted tiene un proceso con un punto final claro, y precisamente esos son los que merece la pena tomar primero.

Tomemos una cadena típica y sigámosla hasta el final, porque precisamente el seguimiento muestra dónde está de verdad el beneficio: el cliente rellena un formulario en el sitio web, la solicitud llega al correo, alguien la copia al sistema de clientes, otro prepara la oferta y, tras la confirmación, otro más emite la factura en el programa de contabilidad. Aquí hay un proceso con un resultado claro (de la solicitud a la factura), y en él hay al menos tres sitios donde los mismos datos se vuelven a copiar, cada vez con la posibilidad de equivocarse.

Si de esa cadena se automatiza solo el copiado de la solicitud al sistema de clientes, el beneficio es real, pero pequeño, porque los otros dos copiados se quedan. Si se automatiza la cadena entera, cambia el propio carácter del trabajo: la persona ya no copia, sino que comprueba y toma decisiones allí donde de verdad hacen falta. Precisamente por eso conviene dibujar los límites de la cadena antes de cualquier conversación sobre herramientas, porque ellos determinan cuán grande puede ser el beneficio.

La cadena tiene también un responsable, y esa es una pregunta que suele quedar sin hacer. Si ninguna persona concreta puede decir cómo ocurre el proceso de principio a fin, la automatización será una sucesión de supuestos sobre cómo ocurre probablemente, y el primer caso real los romperá. Encontrar al responsable suele ocupar una conversación, pero ahorra varias semanas, así que es la parte más barata del proyecto.

Segunda pregunta: ¿la máquina recibe datos o una imagen?

Esta es la diferencia técnica más importante de toda la automatización, y en España ahora tiene también un lado normativo. Si el sistema recibe datos estructurados (XML, JSON, un registro en una base de datos), puede tratarlos sin adivinar. Si recibe una imagen, es decir un archivo PDF o una hoja escaneada, entonces antes del tratamiento alguien tiene que adivinar qué pone ahí, y precisamente esa adivinación crea los errores que después alguien corrige a mano.

El ejemplo de las facturas lo muestra mejor que ningún otro, porque ahí las dos posibilidades conviven y se llaman casi igual. Una factura electrónica estructurada, en el día a día también llamada factura electrónica, es un documento legible por máquina en un formato determinado: ante la Administración el formato es Facturae, y el modelo semántico europeo es la norma EN 16931 — la solución pública de facturación entre empresas toma como referencia la sintaxis UBL precisamente porque cumple esa norma. El sistema del destinatario puede contabilizarla sin participación de una persona, y por eso precisamente este formato es aquel al que se aplican los plazos normativos.

Una factura en PDF que el destinatario ha aceptado recibir por vía electrónica también es un documento válido: el Reglamento de facturación, artículo 9, condiciona la factura electrónica a que el destinatario haya dado su consentimiento, salvo en los supuestos en que ya es obligatoria. Pero es válida como factura, no como factura electrónica estructurada, y para la máquina sigue siendo una imagen.

De ahí se sigue una conclusión que ahorra mucho dinero: reconocer facturas en PDF con OCR no es implantar la factura electrónica estructurada. El OCR —el reconocimiento óptico de caracteres— es una operación aparte, que la gente automatiza con razón porque reduce el copiado a mano, pero no crea un documento estructurado ni cumple la obligación de expedirlo. La empresa que toma el OCR por respuesta al requisito normativo descubre al cabo de un par de años que ha automatizado el extremo equivocado, y entonces el proyecto hay que empezarlo de nuevo con el sistema que emite las facturas, no con el que las recibe.

El modo práctico de comprobarlo aquí es sencillo: pregunte en qué formato el sistema es capaz de emitir los datos y de recibirlos. Si la respuesta es «se puede exportar a CSV», eso ya son datos estructurados, solo que no del todo automatizados. Si la respuesta es «se puede imprimir» o «se puede guardar en PDF», entonces la imagen es la única salida, y el trabajo que sigue o bien pide una interfaz, o se quedará en adivinar.

Conviene saber también que la respuesta a menudo es mejor de lo que en la empresa se cree, porque muchos programas de contabilidad y de almacén tienen interfaz, solo que nadie la ha pedido nunca, porque el trabajo diario se apaña con la exportación. Una pregunta al proveedor sobre si el sistema tiene una interfaz de programación y qué se puede hacer con ella decide a menudo si el proyecto merece siquiera empezarse.

Tercera pregunta: ¿el paso decide algo sobre una persona?

La mayor parte de la automatización es mover cifras entre sistemas, y ahí no hay ninguna cuestión jurídica especial. Hay, con todo, un grupo de pasos que hay que reconocer aparte: aquellos que deciden algo sobre una persona concreta — si contratarla, si concederle crédito, si despedirla, si otorgarle una prestación.

El artículo 22 del Reglamento general de protección de datos —Decisiones individuales automatizadas, incluida la elaboración de perfiles— establece que todo interesado tendrá derecho a no ser objeto de una decisión basada únicamente en el tratamiento automatizado, incluida la elaboración de perfiles, que produzca efectos jurídicos en él o le afecte significativamente de modo similar. Existen excepciones (necesidad contractual, una ley con medidas de protección, consentimiento explícito), pero también entonces quedan el derecho a la intervención humana, a expresar el punto de vista y a impugnar la decisión. Las directrices de las autoridades de control añaden un matiz importante: la intervención humana ha de ser significativa, y un botón formal de confirmación que alguien pulsa sin mirar el contenido no saca el proceso del artículo 22.

Eso no es una prohibición de automatizar, sino una indicación de qué es exactamente automatizable en un proceso así: se puede automatizar el trabajo de preparación (recoger datos, comprobarlos, preparar la propuesta), pero la decisión misma se queda en la persona que de verdad la toma. En la práctica eso cambia el alcance del proyecto, así que conviene verlo antes del desarrollo, no después.

Junto a eso conviene conocer un plazo que aún no ha llegado, pero que afecta a los planes a largo plazo: las exigencias del Reglamento de inteligencia artificial para los sistemas de alto riesgo en el ámbito del empleo, es decir, la selección y las decisiones de personal, empiezan a aplicarse el 2 de diciembre de 2027. Eso significa que hoy la elección es más libre, pero a un sistema que se construye a largo plazo esta fecha hay que meterla en el plan.

Cuarta pregunta: ¿el proceso ya tiene un plazo externo?

En una parte de los procesos el plazo no lo fijan las prioridades de la empresa, sino una obligación externa, y esos pasan solos a la cabeza de la lista, porque sobre ellos ya no hay que decidir si hacerlo, sino solo cuándo y cómo. En España el ejemplo más claro vuelve a ser las facturas, y ahí hay tres fechas distintas que se suelen mezclar.

En primer lugar, la empresa que factura a una Administración Pública usa el formato estructurado ya desde el 15 de enero de 2015. En segundo lugar, desde el 1 de enero de 2027 los sistemas de facturación de quien tributa por el Impuesto sobre Sociedades deben adaptarse a Verifactu —y el 1 de julio de 2027 el resto—, de modo que los registros puedan remitirse a la Agencia Tributaria. En tercer lugar, la obligación de expedir factura electrónica estructurada a otro empresario o profesional se aplica a los doce o veinticuatro meses de la orden ministerial que desarrolle la solución pública, y, entre medias, los registros ya se pueden remitir a la Agencia Tributaria de forma voluntaria.

Precisamente esta tercera fecha es la que en la circulación pública más a menudo está mal, y la razón es sencilla: la redacción inicial apuntaba a un plazo más temprano, después se aplazó, y parte de los artículos de segundo orden nunca lo corrigieron. Para una empresa que planifica el presupuesto, la diferencia entre dos años es grande, así que la fecha conviene comprobarla en la fuente primera, no en el relato.

Los plazos externos están también en otras partes: el registro de la jornada tiene que ser objetivo y accesible, los documentos contables tienen plazos de conservación, y en los contratos suele haber fechas de informe. Lo común es que estos plazos no se negocian, y un proceso que tiene uno da un fundamento claro al trabajo — a diferencia de un proceso que se automatiza porque parece moderno.

Cómo se ve un proceso que merece la pena tomar primero

Si se reúnen las cuatro preguntas, sale un retrato bastante concreto, que se puede poner al lado de cualquier lista: el primer candidato más valioso es una cadena con un resultado claro, en la que los datos ya existen de forma estructurada o pueden llegar a serlo, en la que ningún paso decide nada sobre una persona, y que tiene un plazo externo o al menos un volumen medible.

En la práctica suele verse así: el pedido de la tienda llega al sistema de contabilidad sin copiarlo a mano; una cadena de aprobaciones en la que la solicitud va a la persona correcta y vuelve con una marca; la sincronización de datos entre el almacén y el sitio web, donde hoy alguien exporta un archivo dos veces al día. En los tres hay una señal común — entre dos sistemas hoy camina una persona con un archivo.

Precisamente esta señal es la más fácil de ver y la más difícil de olvidar, así que conviene empezar por ella el inventario. Escriba dónde, en su empresa, alguien exporta, copia o vuelve a escribir, con qué frecuencia y durante cuánto tiempo. Esta lista suele ser más corta de lo esperado, y en ella casi siempre hay una entrada que destaca.

La segunda señal que hace destacar a un candidato es el precio del error, y en los cálculos suele omitirse: si un error de copiado en esta cadena significa una factura incorrecta al cliente, un stock incorrecto en el almacén o un plazo incumplido, entonces el beneficio de automatizar no son solo las horas ahorradas, sino también los errores evitados, y eso suele ser el mayor de los dos números. Un proceso en el que el error pasa inadvertido y no hace daño es, en este sentido, un candidato menos valioso, aunque ocupe el mismo tiempo.

La tercera señal es cómo cambia el volumen con la empresa, y es la más importante de las tres: un trabajo que crece con la empresa, porque más pedidos significan más copiado a mano, se vuelve con el tiempo cada vez más caro, y precisamente ahí la automatización se amortiza por partida doble: libera tiempo hoy y quita un coste que, de otro modo, crecería. Un trabajo de volumen fijo, con independencia de la facturación, no da este segundo beneficio.

Al retrato conviene añadir una cosa sobre el orden, porque en ella las empresas se equivocan más a menudo que en la elección de herramientas: el primer proceso automatizado no hay que elegirlo por cuál es el más grande o el más doloroso, sino por cuál se entiende mejor y se termina antes, porque el primer proyecto enseña a la empresa cómo ocurren en general este tipo de proyectos — cómo describir las excepciones, cómo probar y qué hacer con los errores. Esta lección es mucho más barata sobre un trabajo sencillo que sobre uno del que depende el flujo de caja.

Cómo se ve un proceso que no merece la pena tomar primero

Tan útil como reconocer un buen candidato es reconocer lo que parece atractivo pero se amortiza mal, y de esos casos hay cuatro. El primero es un trabajo que ocurre poco (una vez al trimestre o una vez al año), porque el coste de desarrollo se queda igual, pero el ahorro se divide entre cuatro o entre uno.

El segundo es un proceso cuya forma de hacerse todavía cambia, y ese es el caso en el que la prisa sale más cara: si esa forma se ha modificado tres veces en el último medio año, la automatización fijará la versión que de todos modos cambiará pronto, y el mantenimiento se comerá el beneficio. Aquí el orden correcto es ponerse primero de acuerdo sobre cómo se hace y solo entonces automatizarlo, aunque en la práctica suele ocurrir al revés.

El tercero es un trabajo en el que cada caso es una excepción, y ahí la frontera está en la propia naturaleza de la tarea, porque la automatización se apaña bien con lo frecuente y lo previsible, pero mal con una situación en la que diez casos tienen diez caminos distintos; ahí el juicio de una persona es el propio trabajo, y sustituirlo por un árbol de reglas suele crear más excepciones de las que quita.

A estos tres casos los une una señal: en ellos la automatización fija algo que aún no está listo para quedar fijo. El trabajo raro no está lo bastante rodado como para que merezca la pena inmortalizarlo; el proceso cambiante todavía busca su forma; el trabajo de excepciones es, de suyo, un juicio. En los tres la acción correcta es esperar o poner orden primero, no automatizar antes.

El cuarto es el caso en el que se imita la pantalla porque el sistema no tiene interfaz. A veces es el único camino posible, pero es también el más frágil: basta un cambio en la pantalla y el trabajo se para. Si el sistema tiene interfaz o se puede pedir, esa es casi siempre una elección más ventajosa que imitar la pantalla.

Qué ocurre con las personas cuyo trabajo se automatiza

Esta pregunta las ofertas de automatización suelen esquivarla, aunque en la empresa se hace ya el primer día, y sin respuesta se convierte en una resistencia callada que puede parar el proyecto con más seguridad que cualquier problema técnico. La respuesta honesta en la mayoría de las pequeñas y medianas empresas es que la automatización libera tiempo, no a la persona: el copiado a mano es la parte del trabajo que nadie quiere, y su desaparición suele significar que esa misma persona por fin llega a hacer aquello para lo que antes no había tiempo.

De ahí se sigue una recomendación práctica que suena blanda, pero es una cuestión pura de dirección de proyecto: a la persona que hace el trabajo hoy hay que involucrarla en el proyecto como la fuente que más sabe, no informarla del resultado. Conoce las excepciones que nadie ha apuntado, y precisamente las excepciones son las que rompen la automatización. Un proyecto en el que esta conversación ocurre al principio cuesta menos que uno en el que ocurre después del primer error.

También es honesto decir la otra cara, porque lo contrario sería fingir: si en la empresa el trabajo de alguien consiste por completo en pasar datos entre dos sistemas, entonces la automatización sí sustituye ese trabajo, y esa es una conversación sobre el cambio de rol que dirige la dirección de la empresa, no el proveedor. Una oferta que no plantea esta pregunta en absoluto no es delicada — sencillamente no está pensada del todo.

Cómo calcular su propia cifra

El cálculo que hace falta para la decisión cabe en una página y no pide ni un consultor ni un estudio. Hacen falta cuatro cifras: cuántas veces a la semana ocurre este trabajo, cuántos minutos ocupa cada vez, cuánto cuesta la hora de la persona que lo hace, y con qué frecuencia surge en él un error que después alguien corrige.

Las tres primeras dan el coste directo de tiempo al año, y esta cifra suele ser menor de lo esperado — precisamente por eso justificar el proyecto solo con ella a menudo no sale. La cuarta cifra es la que de ordinario decide, porque el precio del error rara vez es solo el tiempo de corregirlo: una factura incorrecta significa correspondencia con el cliente, un stock incorrecto significa o bien un producto que se queda sin vender, o un pedido de un producto que ya no está en el almacén, y un plazo incumplido a veces significa una multa.

Frente a estas cifras se pone el coste de desarrollo y el mantenimiento, y precisamente el mantenimiento es el que se olvida. Una automatización que une dos sistemas vive tanto tiempo como viven las dos interfaces, así que en el plan tiene que haber sitio para los cambios que pedirá otro. Si el cálculo se amortiza solo cuando el coste de mantenimiento no se incluye, entonces en realidad no se amortiza en absoluto.

Otra cosa que conviene aclarar antes de la conversación es con qué frecuencia cambian los sistemas. Un servicio en la nube que se actualiza por sí solo puede cambiar la interfaz sin aviso, mientras que un programa instalado en local permanece años sin cambios, pero su actualización alguna vez exige volver a comprobarlo todo. Ninguna de las dos variantes es peor, pero piden un plan de mantenimiento distinto, y una oferta que no lo refleja saldrá barata precisamente en el sitio donde más adelante nacerá el coste.

Por qué no hay que creerse los porcentajes de los estudios

En las ofertas de automatización aparece casi siempre una cifra: que se puede automatizar la mitad del trabajo, que los proyectos fracasan en un tercio de los casos, que alguien ahorró decenas de miles de horas. Estas cifras existen y se pueden citar, pero casi nunca describen a la empresa a la que se las muestran, y precisamente eso las convierte en una mala base para la decisión.

El indicador ampliamente citado de que una gran parte de las acciones es automatizable es un cálculo sobre acciones en la masa salarial de un país concreto y un año concreto, con las tecnologías de aquel año, y lo publicó una consultora que vende este mismo servicio. El indicador sobre el fracaso de los proyectos viene de la experiencia de un consultor con clientes que lo llamaron después de los primeros fracasos, así que la muestra está distorsionada ya por definición. La cifra de las horas ahorradas describe un departamento de contabilidad concreto de cuarenta personas en otro país, hace varios años.

De ahí no se sigue que la automatización no se amortice, sino que la cifra correcta es la suya: cuántas veces a la semana ocurre este trabajo, cuánto dura y cuánto cuesta la hora. Este cálculo se puede hacer en una página, describe precisamente su empresa, y es el único sobre cuya base merece la pena tomar la decisión.

Qué hay que saber de los sistemas antes de pedir una oferta

Cuando el candidato está elegido, el siguiente paso no es pedir una oferta, sino cinco minutos de indagación sobre los propios sistemas, porque precisamente eso decide si la conversación con el ejecutor será sobre la solución o sobre la posibilidad. Averigüe si cada sistema implicado tiene una interfaz de programación, si está disponible en su nivel de licencia y si el proveedor cobra por ella aparte, porque las tres respuestas suelen diferir.

La segunda pregunta es quién guarda los datos y quién puede cambiarlos. Si dos sistemas contienen la misma información, por ejemplo los datos de facturación del cliente o el stock de un artículo, entonces antes de unirlos hay que decidir cuál de los dos es el principal, porque si no la automatización empezará a copiarlos el uno sobre el otro y el resultado será peor que antes. Esta decisión es gratis si se toma al principio, y cara si se descubre en las pruebas.

La tercera es qué ocurre cuando algo falla. En cada automatización hay casos que no pasan (falta un campo, el sistema no responde, los datos se contradicen), y necesitan un sitio al que llegar y una persona que los mire. Una automatización sin tratamiento de errores funciona tanto tiempo como todo va bien, y eso nunca es mucho.

Conviene también decidir de antemano con qué se valorará si salió bien, porque sin eso el proyecto nunca termina, sino que simplemente se interrumpe. La medida puede ser del todo sencilla: cuántas veces al mes alguien sigue copiando datos a mano, cuántos errores se corrigieron el mes pasado y cuánto tarda una solicitud del formulario a la respuesta. Esta cifra tiene sentido medirla una vez antes de empezar el trabajo, para tener después con qué comparar. Las empresas que no hacen esta medición, al cabo de medio año discuten si cambió algo siquiera.

Por último conviene recordar que la automatización no es un trabajo de una vez, sino algo que se queda en la empresa y pide un dueño igual que cualquier otro sistema. Cuando el proceso está unido, alguien tiene que saber dónde mirar si se para, y alguien tiene que tener derecho a detenerlo si el resultado parece incorrecto. En las empresas en las que este rol no está nombrado, la automatización deja de funcionar en silencio, y se nota solo al cabo de un mes, cuando alguien busca un documento perdido.

Por dónde empezar en la práctica

El comienzo no es ni la elección de la herramienta ni pedir una oferta, sino una semana en la que se apunta lo que ocurre: qué trabajo se repite, con qué frecuencia, durante cuánto tiempo y dónde, en él, una persona pasa datos entre sistemas. Después plantee a cada entrada las cuatro preguntas de este artículo, y la mayor parte de la lista caerá ya tras las dos primeras.

El resultado suele dejar uno o dos candidatos, y eso está bien, porque precisamente tantos merece la pena empezar a la vez: dos trabajos terminados dan más que seis empezados. Cuando el candidato está elegido, el siguiente paso es averiguar si los sistemas implicados tienen interfaz, porque eso decide tanto el precio como la solidez de la solución.

Si en este punto está claro cuál es su proceso, pero no cómo unirlo, se puede hablar con nosotros: la automatización de procesos de negocio en nuestra ejecución son integraciones y flujos de trabajo entre los sistemas que usted ya tiene. Si quiere entender primero en qué se diferencian los distintos enfoques y grupos de herramientas, escríbanos o envíenos su lista — a menudo la respuesta es que basta una conexión, no una plataforma.