Un caso de automatización laboral de un no desarrollador tras rechazarse la ampliación de plantilla
Es el caso de un responsable de gestión empresarial que, tras asumir también tareas de mantenimiento con escasez de personal y estándares, eliminó cuellos de botella e inició pequeñas automatizaciones con Claude Code. La clave no está en una tecnología para trabajar más rápido, sino en cambiar primero la estructura del trabajo que genera intermediaciones y repeticiones innecesarias.
El problema más grave que el aumento del volumen de trabajo era que el personal existente tenía que crear al mismo tiempo nuevos procedimientos y estándares para los entregables.
Incluso las solicitudes breves de importación y exportación de archivos generan una carga de trabajo superior al tiempo real de procesamiento si interrumpen repetidamente la concentración.
La primera mejora efectiva no fue un programa de automatización, sino cambiar el flujo para que las solicitudes no tuvieran que pasar por la persona responsable.
Incluso un no desarrollador puede utilizar la IA generativa y herramientas de programación para crear pequeñas automatizaciones mediante un ciclo de explicación del problema, ejecución, comprobación de errores y corrección.
Los objetivos de automatización deben evaluarse no solo por la frecuencia de repetición, sino también por el riesgo de errores, la frecuencia de interrupciones, la posibilidad de estandarización y los controles de seguridad.
Quienes se sienten abrumados por tareas repetitivas suelen empezar buscando maneras de realizarlas más rápido. Sin embargo, el punto de partida que muestra este caso es distinto. Ante la dificultad de ampliar la plantilla, una persona encargada de la gestión de proyectos, en lugar de limitarse a acelerar el trabajo que se concentraba en ella, comenzó por revisar por qué todas las solicitudes y revisiones tenían que pasar por sus manos.
Este artículo no presenta las funciones de una tecnología de automatización, sino que analiza el entorno laboral que hizo inevitable recurrir a ella, la primera mejora estructural, el proceso de aprendizaje de una persona no desarrolladora y los principios que pueden generalizarse a partir de esa experiencia.
Punto de partida del caso: aumentó más la complejidad que el volumen de trabajo
En un principio, el equipo se encargaba de un proyecto de operación de infraestructura. Ya existía un flujo conocido para mantener los sistemas de forma estable, responder a incidentes y recopilar los resultados mensuales. El problema comenzó cuando, manteniendo la misma plantilla, se añadió un nuevo proyecto de mantenimiento.
Esto era distinto de realizar el mismo trabajo por duplicado. Además de encargarse de tareas en las que no tenía experiencia, la persona responsable debía diseñar desde cero los siguientes elementos:
· Qué entregables se recibirían
· Qué apartados se incluirían en los documentos
· Cómo se determinaría el orden de revisión entre el proveedor y el cliente
· Cómo se gestionarían la numeración y el calendario de cada trabajo
· De qué manera se recuperarían y reportarían los resultados firmados
Categoría | Operación de infraestructura existente | Tareas de mantenimiento añadidas
Sistema de trabajo | Existencia de procedimientos operativos conocidos | Necesidad de diseñar nuevos procedimientos y criterios
Entregables principales | Resultados operativos y registros de respuesta a incidentes | Cronogramas, registros de trabajo, copias firmadas, materiales de inspección, etc.
Objetos de gestión | Centrados en las operaciones internas | Participación conjunta de proveedores, trabajadores, áreas responsables y clientes
Carga principal | Operación estable | Incluye establecimiento de estándares, coordinación de calendarios, revisión, devolución y recuperación
La clave de la sobrecarga no fue solo que aumentara el trabajo, sino que también hubo que crear el sistema para gestionarlo.
Sin estándares, las revisiones y devoluciones se repiten
Como los estándares existentes para los entregables de mantenimiento no eran suficientes, la persona responsable creó directamente los formularios y los distribuyó a los proveedores. Sin embargo, sobre el terreno se repetían problemas como utilizar formularios del año anterior, omitir la firma del trabajador o redactar de forma ambigua las observaciones especiales.
Por ejemplo, si en el apartado de resultados solo se escribe «se tomarán medidas más adelante», la persona responsable de la gestión no puede hacer un seguimiento de la fecha de finalización. Debe devolver el documento solicitando que se indique una fecha concreta y volver a revisar la versión corregida. Se genera así una estructura en la que el trabajo de gestión necesario para revisar y corregir los entregables supera a la propia inspección.
Este caso demuestra que la estandarización debe preceder a la automatización de documentos. Si no se han definido el formato de entrada y los campos obligatorios, las herramientas de automatización se limitan a trasladar con rapidez datos ambiguos e incompletos. Si se está considerando automatizar, primero deben definirse los siguientes elementos:
· Campos que deben cumplimentarse obligatoriamente
· Formatos admitidos para fechas y nombres
· Condiciones que requieren firma o documentos adjuntos
· Motivos de devolución y responsable de la corrección
· Criterios para considerar completada una tarea
Por qué solicitudes de pocos minutos alteraban el flujo de todo el día
Por motivos de seguridad, la entrada y salida de archivos externos se gestionaba mediante un único canal que pasaba por una sola persona responsable. El tiempo necesario para tramitar cada solicitud no era largo, pero existía el problema de que no se sabía de antemano cuándo llegaría.
Si entraba una solicitud mientras la persona estaba concentrada en su trabajo principal, debía detenerse para procesar el archivo. Después tenía que recuperar el contexto de la tarea interrumpida. En este caso, lo que incrementaba la carga percibida no era tanto el tiempo dedicado a cada solicitud como los constantes cambios de tarea.
Al buscar candidatos para la automatización, no basta con calcular el tiempo que requiere tramitar cada caso. También deben considerarse los siguientes costes:
· Tiempo necesario para revisar la solicitud y determinar su prioridad
· Coste de transición de detener una tarea y volver a iniciarla
· Tiempo necesario para volver a preguntar al solicitante por información omitida
· Tiempo dedicado a registrar e informar por separado si la solicitud se ha tramitado
· Tiempo de espera generado cuando una persona responsable concreta está ausente
Las solicitudes breves pero impredecibles y recurrentes pueden convertirse en un cuello de botella que altera considerablemente el calendario general y la capacidad de concentración.
La primera solución no fue automatizar, sino eliminar el paso intermedio
La primera mejora del problema de entrada y salida de archivos no consistió en desarrollar un programa. Se modificó el flujo para que el solicitante y el cliente intercambiaran directamente las solicitudes mediante el tablón del sistema interno de gestión de proyectos.
Antes del cambio | Después del cambio
Todas las solicitudes pasaban por la persona encargada de la gestión del proyecto | El solicitante y el cliente las procesaban directamente en el sistema
La persona responsable se ocupaba tanto de transmitir como de registrar | El historial de procesamiento quedaba registrado en el sistema
El trabajo principal se interrumpía cada vez que llegaba una solicitud | La persona responsable consultaba los registros cuando era necesario
Las solicitudes podían retrasarse si la persona responsable estaba ausente | Los participantes designados podían revisarlas dentro del mismo flujo
El principio que puede extraerse de aquí es claro. En lugar de realizar más rápido el trabajo asignado, puede ser mejor evitar que ese trabajo tenga que pasar por uno mismo.
Antes de diseñar una automatización, resulta útil revisar los pasos en el siguiente orden:
· ¿Es un paso que puede eliminarse?
· ¿Puede el solicitante introducir o comprobar directamente la información?
· ¿Puede simplificarse el recorrido con las funciones del sistema existente?
· ¿Pueden estandarizarse los criterios de entrada y decisión?
· ¿Pueden automatizarse las tareas repetitivas que aún queden después?
La acumulación simultánea de varias tareas sencillas consolidó la sobrecarga
El flujo completo del mantenimiento incluía elaborar calendarios, organizar la información de proveedores y trabajadores, asignar números, recuperar registros de trabajo, obtener la revisión y firma del cliente, escanear, informar de la inspección y entregar los resultados a cada proveedor. Ninguna etapa era difícil por separado, pero cuando todas coincidían, resultaba complicado controlarlas únicamente mediante la memoria y el trabajo manual de una persona.
Esta situación continuó durante unos tres meses. Durante el día se atendían solicitudes de entrada y salida de archivos, consultas de proveedores, comprobaciones de miembros del equipo y peticiones de clientes, y solo después de la hora de salida, cuando disminuían los contactos, se realizaba el trabajo esencial acumulado. Más que resolver el problema, la situación se parecía a intentar ponerse al día tardíamente con lo ocurrido durante la jornada.
La persona responsable solicitó personal auxiliar, pero la petición no fue aceptada. Cuando quedó descartada la posibilidad de aumentar la plantilla, cobró importancia la opción de cambiar el método existente. La automatización no surgió como una afición motivada por el interés, sino como respuesta a la conclusión de que, con la estructura de trabajo actual, el mismo problema volvería a repetirse al mes siguiente.
Una demostración de Claude Code impulsó un pequeño experimento
El punto de inflexión fue una demostración de automatización con Claude vista en un evento de la sede central. Más que una tecnología de desarrollo compleja, lo importante fue comprobar la posibilidad de que «esta herramienta también podría aplicarse a nuestro trabajo». La conversación con un compañero que había asistido al evento sobre realizar un pequeño intento se convirtió en el punto de partida del posterior trabajo de automatización.
Como no era desarrolladora, la persona responsable comenzó preguntando a otra AI generativa cómo instalar Claude Code. Consultó y ejecutó las instrucciones y los comandos correspondientes a su sistema operativo, y siguió mediante vídeos y otros materiales el proceso de configuración inicial de otros usuarios. No comenzó después de aprender por completo la teoría de programación.
Sin embargo, este método no significa que se deban ejecutar sin más comandos cuya procedencia se desconoce. En los dispositivos de trabajo se deben comprobar las políticas de seguridad de la organización y los permisos de instalación de software y, siempre que sea posible, utilizar el procedimiento de instalación de la documentación oficial. Antes de ejecutar un comando, también debe verificarse si elimina archivos, modifica permisos o realiza transmisiones externas.
El proceso interactivo de resolución de problemas fue más importante que el resultado
El primer resultado proporcionó la confianza de que «incluso una persona no desarrolladora puede crear una automatización». Sin embargo, en este caso, el aprendizaje más importante estuvo en el proceso de creación, no en el programa terminado.
El desarrollo interactivo suele seguir un ciclo como el siguiente:
· Se explican el problema que se desea resolver y el procedimiento actual.
· Se comunican restricciones como los archivos de entrada, el formato de salida y las limitaciones de seguridad.
· Se revisan el método y el código propuestos por la AI.
· Se ejecutan utilizando copias o datos de prueba.
· Se vuelven a explicar los mensajes de error y los resultados distintos de los esperados.
· Se aplican las correcciones y se vuelve a validar.
La AI generativa puede proponer tecnologías o enfoques que el usuario desconocía, y también es posible pedirle que vuelva a explicar términos poco familiares. Por otro lado, sus propuestas no siempre son correctas ni adecuadas para el entorno de la organización. Por tanto, la AI no debe tratarse como una autoridad que sustituya el criterio humano, sino como un recurso auxiliar que amplía las opciones y reduce el ensayo y error.
Criterios extraídos del caso para decidir qué automatizar
No es necesario automatizar todas las tareas solo porque sean repetitivas. Evaluar conjuntamente los siguientes criterios facilita establecer prioridades.
Criterio de decisión | Pregunta que comprobar | Significado
Frecuencia de repetición | ¿Con qué frecuencia se realiza la misma tarea? | Cuanto más se repita, mayor será el ahorro acumulado potencial
Reglas de procesamiento | ¿Pueden explicarse la entrada y el resultado mediante reglas claras? | Cuanto más claras sean las reglas, más sencillas serán la implementación y la validación
Frecuencia de interrupción | ¿Llega sin previo aviso e interrumpe el trabajo esencial? | Incluso una tarea breve puede adquirir una prioridad alta
Impacto de los errores | ¿Una omisión o decisión equivocada afecta a contratos, seguridad o costes? | Puede requerir aprobación humana en lugar de una automatización completa
Calidad de la entrada | ¿Están estandarizados el formulario y los campos obligatorios? | Las entradas irregulares aumentan el tratamiento de excepciones
Trazabilidad | ¿Puede registrarse quién procesó qué y cuándo? | Es necesaria para auditorías y para determinar responsabilidades
Posibilidad de cambio | ¿Cambian con frecuencia los procedimientos y formularios? | También deben considerarse los costes de mantenimiento
Las primeras tareas que deben automatizarse suelen ser pequeñas operaciones con reglas claras, alta frecuencia de repetición y resultados que una persona pueda contrastar fácilmente. Por el contrario, resulta más seguro mantener una fase de revisión humana en los trabajos que incluyan valoraciones legales, autorizaciones de seguridad, responsabilidades contractuales o decisiones sobre cantidades importantes.
Controles y mantenimiento que suelen pasarse por alto en la automatización
Si la automatización se apresura porque el trabajo es urgente, los riesgos del proceso manual existente pueden trasladarse al código. Especialmente en entornos como el de este caso, donde se manejan archivos externos, copias firmadas y materiales de clientes, los controles deben diseñarse junto con la velocidad de procesamiento.
Controles mínimos que deben verificarse
· Permisos: limitar al ámbito necesario las carpetas y cuentas a las que puede acceder la herramienta de automatización.
· Protección de datos: no introducir datos personales, documentación contractual ni credenciales en servicios externos de AI no autorizados.
· Entorno de prueba: ejecutar primero con copias y datos de prueba desidentificados, no con los originales.
· Aprobación humana: establecer procedimientos de confirmación en etapas difíciles de revertir, como el envío o la eliminación de archivos y los informes finales.
· Registros: conservar las entradas, la hora de ejecución, los resultados del procesamiento, los errores y el historial de correcciones.
· Recuperación: conservar los originales y las copias de seguridad para poder volver al estado anterior en caso de fallo.
· Dependencia de la persona responsable: documentar el método de ejecución y detención para que también lo conozcan otros miembros del equipo, no solo quien creó la automatización.
El criterio de éxito de una automatización tampoco debe ser que «funcionó una vez». También debe evaluarse si puede modificarse cuando cambian los formularios o se sustituye a la persona responsable, si permite detectar errores y si es posible volver al procedimiento manual. Este es el criterio que diferencia una herramienta de productividad personal a corto plazo de un sistema de trabajo sostenible.
Hechos confirmados por la experiencia y límites de su generalización
Este caso se basa en la experiencia real de una persona responsable, por lo que no garantiza los mismos resultados en todas las organizaciones. Es necesario distinguir entre lo comprobado directamente en el caso y lo que debe validarse al aplicarlo en otros entornos.
Aspectos observados en el caso | Aspectos que deben comprobarse por separado antes de aplicarlo
Se añadieron nuevas tareas de mantenimiento sin cambios de personal | Distribución de personal y posibilidades de reorganizar el trabajo en cada organización
El canal único causaba interrupciones repetitivas en el trabajo de la persona responsable | Si las normas de seguridad permiten el procesamiento directo entre solicitantes
Se redujeron los pasos intermedios mediante el tablón del sistema de gestión existente | Permisos, conservación de registros y funciones de aprobación del sistema utilizado
Una persona no desarrolladora instaló herramientas y aprendió a utilizarlas con ayuda de una AI generativa | Permisos de instalación en los dispositivos de la empresa y políticas de uso de AI externa
Un pequeño resultado generó confianza para intentar automatizaciones adicionales | Precisión de la automatización, tiempo ahorrado y costes de mantenimiento
Por tanto, el valor principal de este caso no reside en afirmar que una herramienta concreta produce los mismos resultados para todo el mundo. Reside en que las tareas repetitivas no se interpretaron como falta de esfuerzo individual, sino que se redefinieron como problemas de flujo, estándares, permisos y cuellos de botella.
Conclusión: la falta de tiempo puede ser el punto de partida
No es necesario considerar la automatización únicamente como un proyecto independiente que se aprende cuando se dispone de tiempo. Si el trabajo sigue acumulándose y el mismo problema volverá a repetirse al mes siguiente, puede ser una señal de que es necesario cambiar la estructura actual.
El punto de partida no tiene por qué ser un ambicioso plan de desarrollo. Se puede elegir la solicitud que interrumpe con más frecuencia la concentración y comprobar primero si esa etapa realmente debe pasar por uno mismo. Si no puede eliminarse ni transferirse al sistema existente, resulta más seguro estandarizar el formato de entrada y comenzar automatizando una pequeña parte cuyos resultados puedan validarse fácilmente.
La pregunta más importante que deja este caso no es «¿cómo puedo hacer este trabajo más rápido?». Es «¿por qué se repite este trabajo, por qué tiene que pasar necesariamente por mí y hasta qué etapa puede confiarse al sistema?».
Injoys
