Preguntas frecuentes

Es hacer que un proceso que hoy depende de que alguien lo ejecute a mano ocurra solo: que los datos se muevan entre sistemas, que los cálculos corran en horario y que solo las excepciones lleguen a una persona.

No se trata de reemplazar al equipo, sino de sacarle de encima la parte repetitiva. En la práctica, casi siempre son procesos administrativos: reportes, conciliaciones, presupuestos, controles de gasto.

La clasificación clásica (fija, programable, flexible e integrada) viene de la automatización industrial y describe líneas de producción. En procesos administrativos conviene otra división, según qué tan definida está la regla:

• Tareas con regla fija: el cálculo siempre es el mismo. Un tope de compra, una comisión, una conciliación.
• Flujos con decisión humana: el sistema prepara y encadena, pero alguien aprueba. Órdenes de compra, contrataciones, descuentos.
• Integración entre sistemas: ningún cálculo nuevo, solo mover datos entre aplicaciones que hoy no se hablan.
• Estimación: no hay regla escrita y hay que inferirla de la historia. Un presupuesto de venta, una proyección de demanda.

Los tres primeros se resuelven con lógica determinista y auditable. Solo el cuarto justifica un modelo.

Cinco que hemos implementado:

• Un presupuesto de venta que se recalcula solo cada mes, por cliente y categoría.
• Un control que libera el presupuesto de compra en proporción a la venta efectiva.
• Un flujo de caja que se actualiza sin que nadie arme la planilla.
• El cálculo de comisiones variables de la fuerza de venta.
• La detección de clientes que dejaron de comprar.

Todos parten de datos que la empresa ya tenía guardados.

Cualquiera con procesos repetitivos y datos en algún sistema. En Chile es frecuente en distribución, retail, manufactura y servicios.

No depende del tamaño sino de dos condiciones: que el proceso se repita seguido y que la información esté en alguna parte digital, aunque sea una planilla. Una empresa de cuarenta personas con un ERP y Google Sheets tiene más que automatizar de lo que cree.

Primero identificar dónde se va el tiempo: qué tareas se repiten, quién las hace y cada cuánto. Después revisar qué datos existen y dónde están. Recién ahí se elige herramienta.

El orden inverso, comprar una plataforma y después buscarle uso, es el que falla. Conviene partir por un proceso acotado, con dueño claro y resultado medible, y escalar después.

El mejor candidato es un proceso que se repite seguido, ocupa tiempo de gente cara y genera errores o reclamos. De esas tres señales, la de los errores es la que más pesa, porque su costo casi nunca está contabilizado en ninguna parte. Cada corrección se lleva por delante el tiempo de varias personas, y algunas aparecen cuando ya es tarde.

Lo que conviene evitar es partir por el proceso que más molesta. Ese suele ser doloroso pero ocasional, y termina rindiendo menos que otro más aburrido que ocurre cien veces al mes.

Y hay algo que se hace antes de empezar, no después: anotar cuánto demora hoy el proceso, cuánta gente participa y con qué frecuencia falla. Sin ese registro, cuando el proyecto termine no va a haber forma de demostrar que sirvió.

No hay una mejor en abstracto: depende de dónde están tus datos. Si la empresa trabaja en Google Workspace, buena parte se resuelve con Apps Script, AppSheet y conexiones a la base de datos del ERP, sin sumar licencias. Si trabaja en Microsoft, Power Automate cumple un rol equivalente.

La plataforma correcta suele ser la que ya está pagada. Y en varios casos no hace falta ninguna, como se explica en la pregunta siguiente.

Mismo criterio que la pregunta anterior, con un agregado: muchas veces no se necesita software. Un script en Python, corriendo en horario sobre los datos que ya existen, resuelve procesos completos sin licencias, sin límite de usuarios y sin depender de que un proveedor mantenga su producto. Es también lo más barato de operar.

Las plataformas tienen sentido cuando el proceso lo van a mantener personas no técnicas, o cuando el flujo depende de aprobaciones de varios. Cuando el proceso es un cálculo que corre solo, el código gana casi siempre.

Antes de elegir modelo conviene preguntarse si el problema necesita uno. La mayoría de los procesos administrativos se resuelven con reglas deterministas: son más baratas, más rápidas y, sobre todo, auditables. Si el resultado sale mal, se puede rastrear exactamente por qué.

La IA aporta donde no hay regla posible: estimar un valor que no está registrado (modelos de regresión), ordenar casos en categorías (modelos de clasificación) o agrupar lo que se parece entre sí (clusterización). Ahí sí conviene, y de preferencia con modelos cuyo criterio se pueda explicar a quien firma la decisión.

Hablando de modelos generativos, que es a lo que suele apuntar la pregunta: no, y las diferencias son grandes. Algunos rinden mejor en programación, otros en análisis complejo, otros son mucho más baratos para procesar volumen. Entre uno y otro el costo llega a variar diez veces para un resultado equivalente en la tarea que necesitas.

Por eso la pregunta útil no es cuál es la mejor IA, sino cuál conviene para cada parte del proceso. En un mismo proyecto es normal combinar modelos de distinta capacidad, e incluso de distintos proveedores: uno potente para el paso que exige razonamiento y otro más liviano y barato para el volumen. O ninguno, cuando una regla determinista resuelve mejor y se puede auditar.

RPA imita lo que haría una persona en pantalla: abrir una aplicación, copiar, pegar, hacer clic. Sirve cuando el sistema no tiene otra forma de entrada. Las herramientas del rubro son UiPath, Automation Anywhere, Blue Prism y, en la región, Rocketbot, que es de origen chileno.

Es frágil: cualquier cambio de pantalla lo rompe, y el mantenimiento se come el ahorro. Antes de llegar a RPA conviene revisar si el sistema tiene API, acceso a base de datos o exportación programable. Casi siempre hay una vía más estable.

Con flujos que se disparan por un evento, sea un correo, un archivo nuevo o un formulario, y encadenan acciones entre aplicaciones de Microsoft y de terceros. Funciona bien para tareas de oficina.

Se queda corto cuando la lógica de negocio es compleja o el volumen es alto. En ese punto conviene mover el cálculo a código y dejar el flujo únicamente como disparador.

Dentro de Workspace: Apps Script para lógica y tareas programadas, AppSheet para aplicaciones internas sobre Sheets o una base de datos, y Looker Studio para visualizar.

Para procesos con más volumen, con librerías que Apps Script no tiene, o que superan sus límites de tiempo de ejecución, Cloud Run ejecuta el código en horario y BigQuery o Cloud SQL guardan los datos. En la práctica casi siempre se combinan ambos mundos.

Más de lo que la mayoría usa. Además de correo, documentos y videollamadas, permite construir aplicaciones internas con AppSheet, automatizar tareas con Apps Script, publicar dashboards y conectarse a bases de datos externas.

Muchas empresas pagan las licencias y aprovechan solo la parte de ofimática, cuando la capacidad de automatización ya viene incluida en lo que están pagando.

Depende de dónde esté hoy la empresa y de qué tan pesado sea su uso de Excel. Office 365 tiene ventaja en planillas complejas y en organizaciones con mucha infraestructura Microsoft. Workspace tiene ventaja en colaboración simultánea, administración liviana y en lo fácil que resulta automatizar sin licencias adicionales.

Migrar cuesta bastante más que la diferencia de precio entre ambos, así que rara vez se justifica solo por costo.

Se cotiza en dólares, no en pesos. El plan de entrada, Business Starter, parte desde los US$7 por usuario al mes; Standard, Plus y Enterprise suben según almacenamiento, capacidades de Meet y funciones de seguridad.

Los precios y las promociones cambian, así que conviene confirmarlos en la página oficial de Google o con un partner antes de presupuestar.

Las tarifas por hora en consultoría tecnológica varían mucho según la complejidad del proyecto y el tipo de trabajo. En general los rangos van entre 0,6 UF y 2 UF más IVA.

En proyectos de automatización preferimos cobrar por proyecto o por etapa, con alcance y entregable definidos. El cliente sabe desde el principio cuánto va a pagar, y el incentivo queda puesto en terminar bien, no en extender horas.

Depende menos del desarrollo que de tres cosas: en qué estado están los datos, cuántos sistemas hay que conectar y cuántas excepciones tiene el proceso. Como referencia, estos son órdenes de magnitud de proyectos que hemos hecho:

• Un dashboard en Looker sobre datos que ya existen: desde 18 UF.
• Órdenes de trabajo digitales para equipos en terreno, con AppSheet y Apps Script: desde 24 UF.
• Un modelo de presupuesto de venta que corre solo cada mes y proyecta por cliente y categoría: desde 135 UF.
• Un hub de agentes de IA con bases de conocimiento propias: desde 160 UF.

La diferencia entre el primero y el último no está en las horas de programación, sino en cuánto hay que entender del negocio antes de escribir la primera línea. Ese costo es bastante fijo, y por eso pesa mucho más en un proyecto chico que en uno grande.