Una fábrica de software de una persona es una forma de organizar una PyME para que una persona pueda vender, presupuestar, responder, producir y revisar la operación con ayuda de software, automatizaciones y, cuando corresponde, IA. No implica trabajar sin equipo ni dejar decisiones sensibles en manos de una máquina: implica convertir una tarea repetida en un flujo claro, con datos de entrada, reglas, un punto de control humano y una medida observable. Para empezar, elegí un solo proceso frecuente y de riesgo acotado; documentá cómo se hace hoy y automatizá únicamente lo que puedas revisar.
Qué significa en la práctica
La idea no es comprar una colección de herramientas. Es diseñar una pequeña unidad operativa: recibe información, la ordena, ejecuta pasos previsibles, avisa cuando aparece una excepción y deja registro para que alguien pueda corregirla. Esa unidad puede ser un flujo de ventas, un generador de presupuestos, un tablero de seguimiento o un asistente que clasifica consultas. El software tiene sentido cuando encaja en una operación real, no cuando agrega otra pantalla que nadie consulta.
Para una PyME argentina, el punto de partida suele estar en actividades conocidas: mensajes comerciales que quedan sin seguimiento, presupuestos que se rehacen desde cero, consultas repetidas, reportes armados a mano, recordatorios o datos que se copian entre sistemas. La lista no es una receta universal. Es un inventario para observar el trabajo propio y detectar dónde se repite la misma decisión.
La diferencia entre automatización útil y un chatbot aislado está en el recorrido completo. Una respuesta automática puede redactar un texto, pero un proceso bien diseñado también define qué información falta, dónde se guarda, qué casos requieren aprobación, qué sucede si hay un error y cómo se comprueba el resultado. La IA puede colaborar en redactar, clasificar o resumir; las reglas, los permisos y la responsabilidad siguen necesitando diseño.
El marco RUTA para elegir una primera automatización
Propongo usar RUTA como filtro antes de pedir una solución:
- Repetición: ¿la tarea aparece con una frecuencia que justifica documentarla? Anotá ocurrencias reales durante un período representativo, sin inventar un umbral.
- Uniformidad: ¿las entradas y el resultado se parecen entre sí? Cuanto más variable sea el caso, más difícil es automatizarlo sin revisión.
- Traspaso humano: ¿en qué punto debe aprobar, editar o rechazar una persona? Ese punto no es un fallo del sistema: es un control de diseño.
- Auditoría: ¿qué dato permite comparar el proceso antes y después? Puede ser tiempo de respuesta, cantidad de casos pendientes, errores detectados o porcentaje de expedientes completos, siempre que se defina cómo se contará.
El marco evita empezar por la tecnología. Primero describe el trabajo; después decide si conviene una plantilla, una integración, una base de datos, un panel, una automatización o un agente. También obliga a anotar el descarte: si el error sería costoso, si los datos son especialmente delicados o si la tarea exige criterio profesional, la primera versión puede limitarse a preparar información para una persona, no a ejecutar la decisión.
Matriz reutilizable de priorización
Completá una fila por proceso. La columna “métrica antes/después” es una definición de medición, no un resultado prometido.
| Proceso | Frecuencia observada | Entradas | Regla de decisión | Riesgo del error | Aprobación humana | Integración necesaria | Métrica antes/después | Criterio de descarte |
|---|---|---|---|---|---|---|---|---|
| Ej.: preparar presupuesto para un servicio repetible | Registrar durante el relevamiento | Datos del pedido, alcance y supuestos | Usar plantilla si faltan datos, pedirlos; no enviar sin revisar | Medio: alcance mal interpretado | Revisión y envío por responsable | Fuente actual de clientes y canal de entrega | Tiempo desde pedido hasta borrador; correcciones por propuesta | Descartar si cada caso exige una solución distinta |
| __________________ | __________________ | __________________ | __________________ | Bajo / medio / alto | __________________ | __________________ | __________________ | __________________ |
| __________________ | __________________ | __________________ | __________________ | Bajo / medio / alto | __________________ | __________________ | __________________ | __________________ |
La matriz funciona mejor si se completa con ejemplos concretos de la última semana o del último ciclo de trabajo. “Automatizar ventas” es demasiado amplio; “clasificar una consulta entrante y pedir los dos datos que faltan” permite decidir entradas, reglas y control. Si no podés describir el proceso en pasos y excepciones, todavía no está listo para desarrollo.
Ejemplo localizado: una empresa de servicios que prepara presupuestos
Este ejemplo es ilustrativo, no describe un cliente ni un resultado verificado. Supongamos una empresa argentina de servicios que recibe pedidos por distintos canales y arma propuestas con una estructura parecida. La persona responsable quiere dejar de reconstruir cada presupuesto, pero no quiere que una herramienta envíe valores o compromisos sin revisar.
1. Delimitar la tarea. El proceso elegido no es “automatizar ventas”. Es generar un borrador de propuesta a partir de una consulta que ya contiene, o debe completar, tipo de servicio, objetivo, plazo aproximado y datos de contacto.
2. Separar entradas y ausencias. El flujo registra la consulta y verifica campos. Si falta información esencial, prepara una pregunta breve para la persona interesada. Si el pedido menciona una excepción, un alcance incierto o una condición que no está en la plantilla, lo deriva al responsable.
3. Aplicar una regla simple. Sólo los casos que encajan en una estructura previamente aprobada pueden producir un borrador. El borrador incluye supuestos visibles y una lista de puntos a confirmar. No se presenta como propuesta final hasta que una persona lo revise.
4. Dejar trazabilidad. Cada caso conserva la entrada original, los campos utilizados, la versión de la plantilla y la decisión humana. Así, cuando una propuesta necesita corrección, el equipo puede distinguir si falló la información, la regla o el documento base.
5. Medir sin adornar. Antes de implementar, se define cómo medir el tiempo de armado, cuántos campos faltan y cuántas correcciones requiere cada borrador. Después se observa el mismo conjunto de indicadores durante un período comparable. Si el sistema acelera el borrador pero aumenta las correcciones, la conclusión no es “funcionó”: hay que ajustar o descartarlo.
El resultado buscado en este ejemplo no es reemplazar a quien vende. Es reservar su atención para interpretar el pedido, negociar el alcance y asumir la responsabilidad de lo que se envía. La automatización prepara; la decisión comercial permanece visible.
Qué automatizar primero: tabla de decisión
| Si la tarea... | Primera versión aconsejable | Mantener bajo control humano |
|---|---|---|
| Repite pasos y usa datos estructurados | Plantilla con validaciones y registro | Excepciones y cambios de alcance |
| Recibe consultas parecidas | Clasificación y pedido de datos faltantes | Respuesta final y casos ambiguos |
| Copia datos entre sistemas | Integración acotada o carga asistida | Permisos, duplicados y correcciones |
| Produce reportes periódicos | Recolección y tablero de estado | Interpretación y decisiones de gestión |
| Involucra pagos, contratos, salud o información sensible | Preparación de información, sin ejecución automática inicial | Toda aprobación, acceso y comunicación |
| Cambia todas las semanas | Documentación y prueba del proceso antes de automatizar | La decisión de congelar una versión |
Una regla útil es priorizar lo reversible. Si se puede detener el flujo, revisar el registro y corregir el dato sin afectar a terceros, es mejor candidato para una primera iteración. Si una equivocación envía una instrucción irreversible, expone información o compromete una obligación, la automatización debe reducirse a asistencia y control.
Implementación en seis pasos
- Elegí un dueño del proceso. No alcanza con que alguien conozca la herramienta; una persona debe poder explicar el objetivo, aprobar cambios y detener el flujo.
- Dibujá el proceso actual. Escribí inicio, entradas, pasos, decisiones, excepciones, salida y responsable. Incluí dónde se pierde información.
- Definí una versión mínima. Quitá tareas accesorias. La primera versión debería resolver una sola operación y tener un camino claro para los casos que no encajan.
- Prepará datos y permisos. Revisá quién puede ver, modificar, exportar o eliminar información. No uses documentos sensibles en un formulario inicial si no son necesarios; el sitio de contacto de Develop Argentina indica expresamente que no deben enviarse allí pasaportes, claves, datos bancarios ni documentación societaria. Ver el proceso de contacto y evaluación.
- Probá con casos conocidos y excepciones. Usá ejemplos internos representativos, incluyendo datos incompletos, duplicados y pedidos fuera de alcance. Registrá el comportamiento y la corrección humana; no des por válida una salida sólo porque suena bien.
- Revisá y decidí. Compará las métricas definidas, la carga de revisión y los incidentes. Continuá, rediseñá o descartá. Una automatización que no se puede explicar ni detener no está lista para sostener una operación.
En el alcance técnico conviene dejar por escrito qué se construye, qué queda afuera, quién accede a cada dato, cómo se recupera la información, cómo se despliega un cambio y qué soporte existe. Las señales públicas del sitio describen servicios de productos digitales, sistemas internos, integraciones, IA y automatización, además de lanzamiento y soporte; no alcanza esa información para atribuir herramientas concretas, integraciones específicas o capacidades no detalladas. Por eso el alcance debe confirmarse caso por caso.
Limitaciones y costos de decisión
Este enfoque no convierte una empresa pequeña en una operación autónoma ni elimina la necesidad de criterio. Requiere tiempo inicial para describir tareas, ordenar datos y acordar responsables. También puede revelar que el proceso está mal definido, que dos personas aplican reglas distintas o que la fuente original no es confiable.
La IA puede redactar o clasificar de manera inconsistente, sobre todo cuando la consulta es ambigua o el contexto está incompleto. Un flujo automático puede propagar un dato equivocado más rápido que un proceso manual. Por eso hacen falta límites, registros, permisos y una salida humana; en asuntos regulados, legales, contables, financieros o de alta sensibilidad, el alcance profesional debe mantenerse separado y ser revisado por quien corresponda.
Tampoco toda tarea frecuente merece software propio. Si cambia constantemente, ocurre muy pocas veces, tiene un costo de error alto o una herramienta existente resuelve el problema sin fricción, documentar y mejorar el procedimiento puede ser suficiente. La decisión responsable incluye no construir.
Preguntas frecuentes
¿Una fábrica de software de una persona significa trabajar sin empleados?
No. Describe una operación aumentada, no una estructura laboral. Puede haber equipo, especialistas y responsables; lo importante es que el proceso tenga reglas claras, registro y un punto de decisión humana.
¿Tengo que empezar con un agente de IA?
No. Una plantilla, una validación, un formulario o una integración acotada pueden ser mejores primeras versiones. Elegí la herramienta después de entender la tarea y sus excepciones.
¿Cómo sé si una automatización vale la pena?
Definí antes qué problema querés observar: demora, pendientes, correcciones, datos incompletos u otra medida operativa. Compará el mismo criterio después y considerá también el tiempo de supervisión y el riesgo del error.
¿Qué pasa con WhatsApp y los canales de atención?
Un canal no es un proceso completo. Antes de automatizar mensajes, definí qué información se solicita, dónde queda registrada, qué respuestas están permitidas y cuándo interviene una persona. Evitá enviar información sensible sin un canal adecuado.
¿Cuándo conviene pedir ayuda para construirlo?
Cuando hay varios sistemas, permisos, datos históricos, excepciones o una salida que debe quedar documentada. El pedido útil no es sólo “quiero un bot”: es la matriz con proceso, entradas, reglas, responsables, métricas y límites.
¿Cuál es el próximo paso más prudente?
Elegí una tarea repetida, completá una fila de la matriz y observá el proceso actual antes de encargar desarrollo. Si el alcance queda claro, podés evaluar una solución de software, integración o automatización con responsabilidades definidas.
