Cómo seleccionar el proceso adecuado para automatizar
Cinco comprobaciones para elegir entre varios procesos candidatos y probar el elegido con ejemplos reales antes de encargar nada.
- automatización
- pymes
- procesos
Para seleccionar el proceso adecuado entre varios candidatos no basta con mirar cuál se repite más. Hay que comprobar cinco cosas antes de encargar nada: que se pueden reunir ejemplos reales del proceso, incluidos los raros; que el programa donde acaban los datos los acepta; que hay una persona que revisa lo que no está claro; que se sabe dónde pueden estar esos datos; y quién controla los accesos. El candidato que pasa las cinco con menos trabajo es el primero. Después, se prueba con esos ejemplos antes de convertirlo en proyecto.
Qué procesos son candidatos ya lo contamos en cómo automatizar procesos en una pyme: los que se repiten, siguen pasos que se pueden escribir y hoy consisten en copiar datos a mano. Este artículo empieza donde termina aquel, con la lista de candidatos ya hecha.
Por qué no basta con elegir el que más molesta
El proceso que más tiempo quita suele ser también el más difícil de automatizar. Molesta precisamente porque los datos llegan desordenados, porque pasa por tres programas o porque depende de alguien que conoce las excepciones de memoria. Elegirlo primero es empezar por la parte más arriesgada.
Lo que decide si una automatización llega a funcionar casi nunca es el código. Es todo lo que lo rodea: si hay con qué probarla, a dónde van los datos, quién la vigila y quién abre la puerta para instalarla. Todo eso se puede averiguar antes de gastar nada, y conviene hacerlo con cada candidato.
Las cinco comprobaciones
Hay ejemplos reales, también los raros
Un proceso que no se puede enseñar con ejemplos no está listo para automatizarse. La prueba de que algo funciona son los documentos de verdad, no unos ejemplos limpios preparados para la demostración.
Un fabricante para el que construimos un sistema de lectura de pedidos recibía los pedidos en PDF, Excel, Word, fotos hechas con el móvil y hojas escritas a mano. El sistema se validó técnicamente con pedidos reales de sus clientes, incluidos los escritos a mano, porque eran justo los que más costaba teclear. Si solo se hubiera probado con los PDF ordenados, el resultado no habría dicho nada.
Con el importador de Barcelona al que le estamos construyendo un programa de gestión pasa lo mismo: cada importación de catálogos se prueba con las hojas reales de sus proveedores, que cada fábrica monta a su manera.
Lo útil es reunir una carpeta con ejemplos de las últimas semanas, sin escoger: los normales, los incompletos y los que nadie sabe leer a la primera. Si cuesta juntarla, ese ya es un dato sobre el candidato.
El programa de destino acepta los datos
Toda automatización acaba escribiendo en algún sitio: el programa de gestión, el contable, una hoja compartida. Antes de elegir un proceso hay que saber cómo entran los datos en ese programa.
En el caso del fabricante, el sistema deja cada línea del pedido en un fichero con las columnas que su programa de gestión ya sabe importar. No hubo que tocar ese programa. Con el importador, el programa contable que ya usan sigue llevando la contabilidad y no se toca: la conexión con él llegará en un módulo posterior.
La pregunta concreta para el proveedor del programa, o para quien lo lleve en la empresa, es: ¿importa algún fichero, con qué columnas y con qué formato? Si la respuesta es que no acepta nada de fuera, el proyecto crece, y conviene saberlo antes de compararlo con otros candidatos.
Alguien revisa lo que no está claro
Siempre habrá una parte que la automatización no resuelve sola: un pedido con una referencia que no existe, un correo que no encaja en ninguna categoría. Hay que decidir de antemano quién lo mira y en qué momento. Si nadie tiene tiempo para revisar, lo dudoso se acumula y el sistema deja de usarse. Un candidato que tiene ya a su persona natural, quien hoy hace la copia a mano, sale con ventaja.
Se sabe dónde pueden estar los datos
Hay empresas que no quieren que sus documentos salgan de sus equipos, y otras que prefieren la nube para no mantener un servidor propio. Las dos opciones son razonables y cambian la forma del sistema. El sistema del fabricante, por ejemplo, puede funcionar entero en los equipos de la empresa. Lo que sale caro es descubrir esa preferencia con el sistema ya hecho.
Además, si los ejemplos contienen datos personales, probar con ellos ya es tratarlos: el Tribunal de Justicia de la UE lo dijo expresamente para las pruebas de software (TJUE, asunto C-683/21, 2023). Antes de conectar nada al correo o a la base de datos real de una empresa, tiene que estar firmado el encargo de tratamiento del artículo 28 del RGPD (2016).
Pesa más con según qué datos. En una gestoría para la que construimos un tablero de correo, una de las categorías es la de bajas laborales: son datos de salud, que el artículo 9 del RGPD (2016) trata como categoría especial. Un proceso con datos así puede ser buen candidato, pero pide los papeles en orden antes de la primera prueba.
Está claro quién da los accesos
Una automatización necesita entrar en sitios: un buzón de correo, un servidor, una carpeta compartida, el programa de gestión. Muchas veces esos accesos no los controla quien encarga el proyecto, sino un informático externo o el proveedor del programa.
En la gestoría, conectar el tablero al buzón del departamento necesita las credenciales del correo, un dominio y acceso al equipo donde se instala, y esa parte la lleva su informático externo. Es tan parte del proyecto como el código. El sistema está construido y probado; está pendiente de arrancar en la gestoría.
Por eso, al comparar candidatos, conviene apuntar quién tiene que dar permiso para cada uno. El que depende solo de gente de la propia empresa suele arrancar antes.
Cómo comparar varios candidatos
Con la lista hecha, cada candidato se pasa por las cinco comprobaciones. No hace falta puntuar con decimales: basta con ver qué candidato tiene menos alarmas.
| Comprobación | Señal buena | Señal de alarma |
|---|---|---|
| Ejemplos reales | Hay una carpeta con casos de las últimas semanas, raros incluidos | Solo hay ejemplos "de muestra" o nadie los guarda |
| Programa de destino | Importa un fichero con columnas conocidas | No acepta nada de fuera y nadie sabe si se puede |
| Revisión | Quien hoy copia los datos puede revisar los dudosos | No hay nadie con tiempo para mirar las excepciones |
| Dónde están los datos | Se ha decidido entre equipos propios o nube, y los papeles están en orden | Datos personales o de salud sin encargo de tratamiento |
| Accesos | Los da alguien de la propia empresa | Dependen de un tercero al que nadie ha llamado todavía |
El orden práctico es este:
Los dos primeros filtros son los que más candidatos descartan, y los más baratos de comprobar: una carpeta y una pregunta al proveedor del programa.
Una prueba pequeña antes de encargarlo
Elegido el candidato, lo sensato es probarlo con la carpeta de ejemplos antes de convertirlo en un proyecto completo. La prueba no busca una cifra para enseñar, sino responder tres preguntas:
- ¿Lee los casos raros? Los escritos a mano, los incompletos, los que llegan en un formato que solo usa un proveedor.
- ¿Sale lo que el destino necesita? Un fichero que el programa de gestión importa sin retoques, no una tabla que luego hay que adaptar a mano.
- ¿Qué le queda a la persona que revisa? Si corrige poco y entiende por qué se ha equivocado el sistema, el proceso está bien elegido. Si corrige casi todo, había que empezar por otro.
Es lo que hicimos con el fabricante: el sistema se validó con sus pedidos reales antes de hablar de instalarlo. Y es la razón de que el programa del importador avance por módulos, empezando por el catálogo y probando cada importación con hojas reales.
Una prueba así se hace con ejemplos que la empresa puede compartir sin problema o con el encargo de tratamiento ya firmado. Nunca "solo para ver si funciona" con datos personales sin papeles.
Cuándo no elegir ese proceso todavía
Hay candidatos que conviene dejar para después aunque sean los que más molestan:
- Cambia cada mes. Si las reglas todavía se están decidiendo, automatizarlas solo fija el desorden.
- Nadie puede dar ejemplos. Sin carpeta de casos reales no hay forma de probarlo.
- Depende de un programa que vais a cambiar. Mejor esperar al programa nuevo que construir la entrada al viejo.
- Tiene datos sensibles y los papeles no están. Primero el encargo de tratamiento; luego la primera prueba.
- Nadie va a revisar. Una automatización sin persona que mire las excepciones se abandona.
En esos casos, el proceso adecuado para empezar es el segundo de la lista. Si quieres ver qué tipo de proyectos hacemos, están en servicios; si dudas si puedes empezar por un solo módulo o si tienes que dejar el programa que ya usas, lo respondemos en las preguntas frecuentes.
Luis Cros
Programador y fundador de Optimio, en Palma de Mallorca. Hace ERPs a medida, automatizaciones y lectura de documentos para pymes, y emite las facturas de Optimio con su propio sistema VERI*FACTU.
Sobre Optimio