Para decidir qué puede automatizar una empresa pequeña con poco presupuesto, primero miro cómo trabaja hoy. Qué entra, quién lo revisa, dónde se copia la información y qué ocurre cuando falta un dato. Después comparo el trabajo que podríamos retirar con el que seguirá existiendo: supervisión, excepciones y mantenimiento.
No hace falta empezar por IA. Un recordatorio, una exportación programada o una regla de la herramienta actual puede resolver el problema. Construir algo propio tiene sentido cuando las opciones existentes dejan un bloqueo concreto y el negocio puede sostener su operación.
Qué tareas pondría en la primera lista
Buscaría tareas repetidas cuyo resultado una persona pueda verificar: preparar un informe interno, crear una tarea desde un formulario, avisar de solicitudes pendientes o mover campos aprobados entre herramientas. Son candidatos que hay que comprobar, no promesas de ahorro.
- Informes: reunir datos ya disponibles y señalar fuentes incompletas antes de distribuirlos.
- Solicitudes: comprobar campos obligatorios, asignar responsable y mostrar lo que sigue pendiente.
- Documentos: preparar una clasificación o extracción para revisión cuando el formato lo permita.
- Seguimiento: recordar una tarea interna sin enviar al cliente una respuesta o un compromiso no aprobado.
Antes de añadir generación de texto, revisaría los límites de la IA aplicada en producción. Si el problema requiere recoger información web, la arquitectura del pipeline de datos es una decisión posterior: primero hay que justificar esa fuente y su mantenimiento.
Ficha para priorizar automatizaciones
Completa esta ficha para cada candidato usando muestras del trabajo real. Incluye días normales y excepciones conocidas. Si no tienes un dato, márcalo como pendiente; no lo conviertas en cero ni en una estimación favorable.
| Criterio | Qué registrar | Cómo influye en la decisión |
|---|---|---|
| Carga actual | Casos por periodo, tiempo activo y correcciones. | La frecuencia sola no demuestra valor. Separa trabajo de tiempo de espera. |
| Reglas y excepciones | Pasos que se repiten y decisiones que cambian según la persona. | Si faltan criterios compartidos, aclara el proceso antes de programarlo. |
| Datos y acceso | Campos necesarios, fuente, permisos y forma de obtenerlos. | Una exportación estable puede bastar; una dependencia incierta exige investigación. |
| Consecuencia del error | Qué se modifica, quién lo detecta y cómo se corrige. | Prefiere una salida revisable para el primer piloto. |
| Trabajo restante | Revisión, excepciones, soporte y cambios de herramientas. | Cuenta el esfuerzo del equipo después de automatizar. |
| Responsable y medida | Quién acepta el resultado y qué mejora necesita comprobar. | Sin responsable o medida, el candidato aún no está listo. |
No sumaría puntos para esconder un bloqueo: tener mucho volumen no compensa carecer de acceso o de una forma de revisar errores. Entre los candidatos viables, elegiría el que permita comprobar una mejora útil con el menor alcance y unas dependencias que podamos mantener. Si el proyecto sigue sin ser viable, explico las alternativas en cuándo rediseñar o descartar una automatización.
Ejemplo hipotético: informe, solicitudes o respuestas
Imagina una pequeña empresa con tres candidatos: un informe semanal, solicitudes que llegan por formulario y respuestas comerciales redactadas desde correos libres. No es un caso de cliente ni una clasificación universal.
Si el informe usa exportaciones estables, criterios acordados y un revisor, empezaría por generar un borrador que muestre datos faltantes. Mantendría la publicación manual. Las solicitudes podrían ir después si el equipo todavía debe acordar quién recibe cada tipo. Pospondría las respuestas comerciales autónomas si dependen de disponibilidad y precios que nadie mantiene actualizados.
La elección cambiaría si el informe apenas consume trabajo y las solicitudes sí provocan retrasos medidos. La ficha sirve precisamente para contrastar esa diferencia antes de comprar herramientas.
Qué dejar fuera del primer piloto
Delimita una entrada, una salida, un grupo de usuarios y un responsable de excepciones. Anota también las exclusiones: migración histórica, nuevos canales, respuestas externas, decisiones de precio o un panel completo no tienen que formar parte del primer encargo.
Prueba primero si una función de tus herramientas actuales cubre el recorrido. Si hace falta desarrollo, pide el flujo mínimo con registro de ejecuciones, aviso de fallo y una forma de detenerlo. Un resultado incompleto debe quedar pendiente de revisión, no aparecer como terminado.
El caso Adslyfy muestra ejecuciones, fallos y capturas en monitorización de anuncios. Es evidencia de visibilidad operativa; no demuestra un retorno económico para este ejemplo ni obliga a copiar su arquitectura.
Cómo medir si el piloto compensa
Compara un conjunto acordado de casos equivalentes antes y después. Registra casos completados, pendientes, errores y minutos de trabajo activo del equipo. Incluye la preparación de datos, la revisión y la recuperación de fallos; no midas solo cuánto tarda la máquina.
Tiempo neto liberado en el periodo = trabajo manual comparable − preparación, revisión, excepciones y mantenimiento del piloto. Registra aparte la espera del cliente o del equipo: reducirla puede ser valioso aunque no retire horas de trabajo.
Separa coste inicial y gasto recurrente de herramientas, ejecución y soporte. Las horas liberadas son capacidad disponible, no ahorro de nómina automático. Con poco volumen o sin excepciones representativas, el resultado puede ser inconcluso: hace falta más evidencia, no una promesa de retorno.
- Continuar: se cumple el objetivo acordado, el responsable puede operar el flujo y el coste recurrente es aceptable.
- Corregir: hay utilidad, pero la revisión o los fallos consumen más trabajo del previsto.
- Parar: el proceso sigue cambiando, el equipo no usa la salida o no puede mantenerla.
- Medir más: faltan casos suficientes para decidir. Acuerda un límite de esfuerzo y una nueva revisión.
Qué llevar antes de pedir presupuesto
Prepara el flujo actual, muestras sin datos sensibles, las herramientas y accesos disponibles, la ficha de candidatos y las exclusiones. Pide que la propuesta identifique quién configura, prueba, revisa y mantiene cada paso. Mi guía de comparación de presupuestos de software desarrolla esa decisión de compra.
El servicio de automatización de procesos empresariales explica cómo acuerdo alcance, entregables y aceptación. Si el bloqueo afecta a prioridades y decisiones técnicas de todo el equipo, revisa el apoyo como CTO externo.
Elegir el primer proceso con un alcance concreto
Si quieres valorar una automatización para tu empresa, cuéntame cómo funciona el proceso actual, qué trabajo se repite y quién revisaría el resultado. Con esa base puedo ayudarte a definir qué conviene probar, qué debe seguir siendo manual y qué falta por medir.