Relevo · el artículo
Le vendieron un robot y le cobraron por robot
Su equipo captura la misma guía dos veces al día, trescientas cuarenta veces entre todos, y eso no es un problema de disciplina ni de actitud: es la consecuencia de tres decisiones que se tomaron antes de que nadie le preguntara. Este artículo es sobre esas tres decisiones y sobre quién las tomó.
La escena
La persona que captura dos veces no es el problema
Empecemos por la escena, porque todo lo demás se entiende desde ahí. Son las nueve y veinte de la mañana. Una persona del área de tráfico tiene abierta la pantalla del sistema de la empresa en un lado y el portal de una paquetería en el otro. Del primero copia el número de guía, el domicilio, el peso y el tipo de servicio; en el segundo lo teclea. Tardó cuarenta y cinco segundos. Va a hacer lo mismo otras veces hoy, y entre todo el equipo esa misma tarea va a ocurrir trescientas cuarenta veces antes de que termine el día.
Si alguien mira esa escena y concluye que hace falta capacitar mejor a esa persona, o que el equipo no está comprometido, o que hay que poner una meta de capturas por hora, está mirando el lugar equivocado. Esa persona está haciendo exactamente lo que el sistema que le dieron le obliga a hacer. Es la consecuencia, no la causa.
La causa está más arriba y más atrás. Alguien decidió, hace años, que los dos sistemas no se iban a integrar porque la integración costaba una orden de cambio que no estaba presupuestada. Alguien decidió que ese proceso se documentaría cuando hubiera tiempo. Y alguien vendió, en algún momento, una automatización que resolvió otra cosa, porque esa otra cosa justificaba mejor el tamaño del proyecto.
Este artículo es sobre esas decisiones. Ninguna la tomó la persona que captura dos veces.
La gente que captura dos veces no es el problema. Es la consecuencia del modelo con el que le vendieron la solución anterior.
El primer problema: la unidad de cobro
Se vende por robot, se cobra por robot, y ahí está el conflicto
La automatización de procesos que se vende hoy en México a empresas de logística tiene, casi siempre, la misma estructura comercial: una licencia que se paga por cada robot en operación o por cada proceso automatizado, más un proyecto de construcción que normalmente ejecuta un socio certificado. Dos facturas, dos proveedores y una sola responsabilidad, que queda repartida de una manera que nadie pone por escrito.
Mire lo que ese diseño hace con los incentivos. El ingreso recurrente del proveedor de la licencia crece con el número de robots dados de alta. No crece con las horas que su equipo recuperó, ni con la calidad del dato que ahora llega bien, ni con la cantidad de errores que dejaron de ocurrir. Crece con la cantidad de robots. Por lo tanto, el proyecto que más le conviene proponer es el que produce más robots, no el que produce más horas.
Y eso tiene una consecuencia concreta, visible en casi cualquier operación que ya pasó por ahí: se automatizan los procesos largos, visibles y presentables —el que se puede enseñar en una junta de dirección— antes que la tarea corta y aburrida que se repite trescientas cuarenta veces al día. La tarea corta produce muchísimas más horas recuperadas y una sola línea de licencia. Casi nunca encabeza el alcance.
Conviene decir esto con cuidado, porque no es una acusación a nadie en particular. Los equipos que venden e implementan esas automatizaciones suelen ser gente competente y de buena fe. El problema no está en las personas: está en que el modelo les paga por una cosa y a usted le interesa otra. Cuando el incentivo del proveedor y el resultado del cliente apuntan a lados distintos, el que pierde es siempre el mismo.
Hay una segunda arista, más silenciosa. Un robot dado de alta sigue costando aunque se ejecute poco. Así que nadie tiene un incentivo claro para dar de baja la automatización que dejó de servir: el proveedor porque cobra por ella, y el cliente porque darla de baja implica admitir, en una junta, que el proyecto del año pasado no funcionó. Ahí empieza la acumulación de automatizaciones que nadie mira.
Cuando el proveedor cobra por robot, su mejor negocio es que usted tenga más robots. El suyo es tener menos trabajo. No es la misma cosa.
La primera pregunta de la primera reunión no es qué hace el producto. Es qué hace subir la factura.
El segundo problema: el método
El que documenta el proceso no es el que lo hace
Así empieza casi todo proyecto de automatización: un analista llega, reserva una sala, entrevista a tres o cuatro personas de la operación y escribe el proceso. Con frecuencia lo dibuja, y el dibujo queda bien. Ese documento es la base sobre la que se construye el robot.
El problema no es la calidad del analista. Es que el proceso que se escribe en esa sala es el proceso que la gente cree que hace, o el que sabe que debería hacer, o el que se acuerda de hacer cuando alguien le pregunta con una libreta en la mano. Y casi nunca es el que ocurre a las nueve y veinte de la mañana con dos ventanas abiertas y el teléfono sonando.
Las diferencias no son pequeñas ni excéntricas. El proceso real tiene el atajo que alguien descubrió hace dos años y no le contó a nadie. Tiene el campo que se llena con un guion porque el sistema no acepta vacío. Tiene la hoja de cálculo intermedia que no aparece en ningún diagrama y sin la cual nada funciona. Tiene el paso que se hace dos veces porque la primera vez el portal se cae a media captura. Y tiene la excepción que en la entrevista se mencionó como «eso casi nunca pasa» y que en realidad pasa en una de cada seis operaciones.
Un robot construido sobre la versión de la entrevista funciona en la demostración y falla en producción, y falla justo en los casos que la entrevista no cubrió. Entonces empieza la segunda fase del proyecto, la que no estaba en el presupuesto: ajustar el robot a la realidad, una excepción a la vez, cada una con su orden de cambio.
Observar el trabajo ocurriendo resuelve esto, y conviene ser preciso sobre en qué sentido lo resuelve. No es que la tecnología sea mejor: es que el método es distinto. Cuando el sistema registra la secuencia exacta de pasos en el orden en que se hace, con su duración y su número de repeticiones, el atajo aparece, la hoja de cálculo intermedia aparece y la excepción de una en seis aparece con su frecuencia real. No hay que confiar en la memoria de nadie, y no hay que pedirle a un operador que describa en palabras algo que hace con las manos.
Hay una consecuencia secundaria de este cambio de método que casi nunca se menciona y que a veces vale más que la automatización: la operación descubre cuánto le cuesta algo que llevaba años dando por normal. Cuarenta y cinco segundos por captura no le parece grave a nadie. Trescientas cuarenta capturas al día son otra conversación, y es una conversación con números que se pueden auditar, no con impresiones.
El proceso documentado en una entrevista es el proceso que la gente cree que hace. El proceso observado es el que hace.
Pida ver la secuencia de pasos con su duración antes de aprobar cualquier automatización. Si nadie puede mostrarla, la automatización se va a construir sobre una suposición.
El tercer problema: el apagado
El robot que nadie apaga
Éste es el problema que menos se discute antes de firmar y el que más caro sale después. Una automatización no falla como falla una máquina: no se detiene, no hace ruido y no prende una luz roja. Cuando el proceso cambia —la paquetería rediseña su portal, el cliente pide otro formato, la autoridad fiscal actualiza un catálogo— la automatización sigue corriendo con las reglas de antes y produce cientos de registros perfectamente bien formados y equivocados.
El daño es silencioso por diseño. Nadie recibe un aviso, porque desde el punto de vista del robot todo salió bien: llenó los campos que le dijeron que llenara y obtuvo una respuesta del otro sistema. El error aparece semanas después, cuando un cliente reclama una entrega que el sistema dice que ocurrió, cuando la conciliación de las pruebas de entrega no cuadra, o cuando alguien de contabilidad encuentra una serie de comprobantes con el mismo dato repetido.
Y aquí viene la pregunta que casi nadie hace en la mesa de negociación: quién puede apagar esto, y en cuánto tiempo. Es una pregunta incómoda porque la respuesta honesta, en muchos contratos, es «hay que abrir un ticket con el proveedor». Eso significa que el control de una pieza que escribe en sus sistemas de producción no está en su empresa. Y significa que entre el momento en que alguien se da cuenta y el momento en que se detiene, hay un intervalo que nadie definió.
Las preguntas que hay que hacer son seis y ninguna es técnica: qué puesto de su empresa puede detenerla sin llamar a nadie; en cuánto tiempo se detiene desde que alguien decide detenerla; si queda registro de quién la detuvo; qué lista existe de lo que ya ejecutó mal, con su hora y sus datos; si se detiene sola ante un caso que no reconoce; y quién autoriza volver a encenderla. Si las seis no se pueden contestar por escrito antes de firmar, la automatización no es suya: es del proveedor, corriendo dentro de su casa.
Y hay una variante especialmente amarga de este problema. Una automatización que sigue corriendo cuando el proceso cambió es peor que no tener automatización, porque destruye la confianza del equipo en el dato. Cuando la gente de operaciones aprende que el sistema a veces dice cosas que no son, empieza a verificar a mano lo que el sistema hizo. Y entonces usted paga la licencia del robot y el trabajo manual de revisarlo, las dos cosas a la vez.
Una automatización que nadie puede apagar en el momento no es un activo. Es una obligación con su nombre.
El daño de un robot mal calibrado no se mide en errores visibles. Se mide en la desconfianza de su propio equipo en el dato, y ésa tarda años en volver.
Lo que la categoría calla
Doce de doce no publican el plazo, y eso no es casualidad
Hasta aquí el argumento ha sido sobre incentivos y método. Ahora un hecho que se puede contar, y que no requiere afirmar nada sobre la calidad de ningún producto ajeno. El 27 de septiembre de 2026 se revisaron los sitios públicos, la documentación oficial de producto, donde existían, los reportes a inversionistas de quince proveedores de software de gestión y automatización del transporte. Doce de ellos son globales.
Ninguno de los doce publica plazo de arranque. Ninguno. No es un dato que se le haya olvidado a alguien: es que la categoría entera no lo publica. Y de los doce, uno publica un tarifario verificable en su propio sitio; los once restantes remiten a contacto comercial.
Cuando una categoría completa calla los dos datos que un comprador necesita para comparar, la comparación es imposible por diseño. No es un descuido de mercadotecnia: es una decisión de modelo comercial. Un precio que no se publica es un precio que depende de cuánto parezca que el cliente puede pagar. Un plazo que no se publica es un plazo que se negocia después de firmar, cuando el cliente ya no tiene alternativa.
Los dos únicos plazos que la revisión encontró son indirectos y conviene decir de dónde vienen, porque el origen es la mitad del dato: uno sale de reseñas de usuarios en una plataforma de evaluación, que hablan de meses y en algún caso de casi dos años hasta la estabilización; el otro es una cláusula de acompañamiento posterior al arranque, que sugiere el orden de magnitud sin comprometerlo. Ninguno de los dos es un compromiso publicado por el proveedor.
Y hay un tercer dato de categoría que en México pesa tanto como los dos anteriores: ninguno de los doce proveedores globales documenta, en su propio material, el cumplimiento fiscal mexicano del traslado de mercancía dentro de su sistema de transporte. Donde ese cumplimiento existe en el portafolio de un proveedor grande, vive en otro producto distinto del de transporte, o se resuelve con desarrollo a medida más un tercero que timbra. Eso no es una crítica a su calidad: es una descripción de dónde queda la obligación. Y queda en usted, cotizada por separado.
Cuando toda una categoría calla el mismo dato, el dato no es el problema. El modelo de contratación lo es.
La otra mitad del mercado
El tablero que mide y no quita una sola captura
Frente a la automatización pesada hay otra oferta, más barata y más fácil de comprar: la herramienta que graba el trabajo y lo mide. Se licencia por usuario observado, se instala rápido y entrega reportes de productividad por puesto y por equipo. Muchas operaciones de logística ya tienen una.
Su problema no es que mida mal. Es dónde termina su alcance. Entrega el diagnóstico y ahí se detiene: dice que se pierden horas en captura, incluso dice en qué captura, y no quita ninguna. El trabajo repetitivo sigue exactamente donde estaba, sólo que ahora está documentado. Y la operación descubre, tres meses después, que compró un espejo.
Hay un efecto secundario que conviene nombrar porque daña más de lo que parece. Una herramienta cuya única salida es la medición de personas empuja, sin querer, hacia el uso disciplinario: si el único producto del sistema es un tablero comparativo de cuántos minutos productivos tuvo cada quien, tarde o temprano alguien lo va a usar para una conversación de desempeño. No porque el software lo pida, sino porque es lo único que el software entrega.
Y entonces ocurre lo previsible: el equipo deja de confiar. Aparecen las estrategias defensivas —mover el ratón, dejar la ventana abierta, reservarse los atajos que hacen el trabajo más rápido— y la medición se vuelve inútil precisamente para lo que servía. Una operación que desconfía de la medición no produce datos de proceso: produce actuación.
La diferencia de propósito hay que declararla, porque es la línea que separa dos productos que en la superficie se parecen. Medir para automatizar y medir para evaluar no son el mismo producto, aunque capturen datos parecidos. El primero necesita saber qué tarea se repite y en qué orden; el segundo necesita saber quién trabaja menos. El primero se puede hacer con el proceso y no con el contenido, con el dato sensible enmascarado en el propio equipo antes de salir, y con un botón de pausa para lo personal. El segundo no funciona si permite pausas.
Medir para automatizar y medir para evaluar no son el mismo producto, aunque se parezcan en la pantalla.
Si su tablero ya le dijo dónde se van las horas y nadie ha quitado una captura, el problema no es la falta de datos. Es que compró la mitad del ciclo.
El costo que nadie presupuesta
La orden de cambio como modelo de negocio
Queda una pieza del rompecabezas: por qué las automatizaciones se quedan corriendo mal en lugar de arreglarse. La respuesta es administrativa, no técnica, y es de una banalidad casi ofensiva: porque arreglarlas implica abrir una orden de cambio, y una orden de cambio implica una cotización, una autorización y una espera.
Piense en la escena completa. Una paquetería mueve un campo de lugar en su portal. El robot empieza a escribir el dato en la casilla equivocada. Alguien de tráfico se da cuenta y avisa. Para arreglarlo hay que pedirle al socio implementador una cotización; la cotización tarda; el monto no está en el presupuesto del trimestre; alguien decide que mientras tanto se revisa a mano. Y ese «mientras tanto» se queda.
En la revisión del 27 de septiembre de 2026, ninguno de los doce proveedores globales documenta lo que cuesta un cambio pedido después del arranque, y en las reseñas públicas de dos de ellos ese costo es el reclamo más repetido de sus propios usuarios. No hace falta nombrar a nadie ni calificar su producto para sostener la conclusión de categoría: el precio de un cambio se conoce cuando ya no se puede cambiar de proveedor.
Y hay una capa más, que las empresas mexicanas conocen bien: en México la entrada de los grandes proveedores pasa por socios certificados. Eso reparte la relación en dos —uno cobra la licencia, otro cobra el proyecto— y con ella reparte la responsabilidad. Cuando algo no funciona, la conversación sobre de quién es el problema consume más tiempo que el problema.
El contraste que esta casa ofrece es de método y se puede verificar: el cambio se hace en la sesión de trabajo, con la gente de la operación en la sala, y no en una cotización posterior. Tiene su límite y también se dice: un cambio que implique volver a observar una tarea necesita que la tarea vuelva a ocurrir, y eso toma el tiempo que toma la operación. No hay magia en esa parte, y quien prometa que no tiene tiempo está prometiendo algo que no puede entregar.
Un modelo donde cada ajuste se cotiza aparte produce sistemas que envejecen mal, no porque el software sea malo, sino porque arreglarlo requiere una firma.
Dónde queda la culpa
No es su equipo, y tampoco es usted
Conviene cerrar el argumento donde empezó, porque la tentación de este tipo de texto es terminar culpando al lector por no haber preguntado antes. No. Usted no tenía por qué saber que la unidad de cobro de un contrato de automatización determina qué procesos le van a proponer. No tenía por qué saber que un proceso levantado en entrevistas produce robots que fallan en las excepciones. Y nadie le dijo, en ninguna de las reuniones, que la pregunta más importante era quién puede apagarlo.
Eso no se lo dijeron porque no conviene decirlo. Y no se lo dijeron tampoco porque, en la mayoría de los casos, el vendedor que estaba enfrente tampoco lo había pensado en esos términos: el modelo comercial se hereda, no se diseña de nuevo en cada operación.
Su equipo, mientras tanto, hizo lo único que podía hacer. Ante dos sistemas que no se hablan, una persona competente teclea dos veces. Ante un robot que se rompió, una persona competente revisa a mano. Ante una medición que no produce ninguna mejora, una persona competente deja de prestarle atención. Todas esas conductas son racionales, y todas son consecuencia del diseño que les dieron para trabajar.
La pregunta útil, entonces, no es quién se equivocó. Es cuál de las tres decisiones se puede cambiar primero. Y la respuesta práctica es la primera: cambiar qué se compra y cómo se paga. Porque de la unidad de cobro salen el método —observar u entrevistar— y el control —apagar o pedir un ticket—. Las tres están atadas.
Nadie de su equipo eligió capturar dos veces. Eligieron cumplir con lo que el sistema que les dieron les pide.
La culpa no es de quien captura. Es del modelo con el que se le vendió la solución anterior, y ese modelo se puede cambiar en el siguiente contrato.
Qué cambia si la observación es el método
Tres cosas distintas, y una que no cambia
Queda decir qué se propone en lugar de lo anterior, sin prometer plazos ni milagros. Son tres cambios de método y conviene medirlos con la misma vara con la que este artículo midió a los demás.
Primero: la prioridad sale de una multiplicación, no de una opinión. Cuántas veces al día ocurre la tarea, por cuántos segundos toma cada vez. Esa multiplicación es auditable, se publica con su aritmética en la página del número, y cualquiera de su equipo puede rebatirla con sus propios datos. Una prioridad que se puede rebatir es una prioridad que se puede defender ante la dirección.
Segundo: la versión del proceso que se automatiza es la última que ocurrió. No la del manual, no la de la entrevista, no la que el programador entendió. Y cuando el portal de un tercero cambia, la tarea se vuelve a observar y el sistema se detiene antes de ejecutar mal, en lugar de seguir escribiendo con la regla vieja.
Tercero: el control de apagado vive en su empresa. El dueño del proceso detiene la automatización desde la propia pantalla, sin ticket y sin llamada, y queda registro de quién lo hizo y cuándo. Esa es la diferencia entre un activo y una obligación.
Y una cosa que no cambia, porque prometer que cambia sería mentir: la obligación sigue siendo suya. Un sistema que observa el trabajo de personas trata datos personales de sus empleados, y el responsable del tratamiento es la empresa, no el proveedor del software. La ley aplicable es la Ley Federal de Protección de Datos Personales en Posesión de los Particulares publicada en el Diario Oficial de la Federación el 20 de marzo de 2025, en vigor el 21 de marzo de 2025, con reforma publicada el 14 de noviembre de 2025. El aviso, el consentimiento y la finalidad declarada son actos de su empresa; el sistema los guarda, los fecha y los hace demostrables, y no los sustituye.
Por eso el arranque de este producto empieza por el aviso y la firma, antes de observar nada. No es un gesto: es el orden correcto, y es el único orden que resiste una pregunta de su propio equipo el primer día.
Lo último que corresponde decir es lo que no se afirma en este artículo, para que no se lea como lo que no es. No se afirma que ningún producto ajeno funcione mal: no los hemos auditado. No se publica el tarifario de nadie, porque las cifras que circulan de esta categoría vienen de comparativas de terceros y no de las empresas. Y no se promete ningún plazo de arranque, entre otras cosas porque este artículo acaba de señalar que la categoría entera calla ese dato: empezar a publicarlo sin poder sostenerlo sería repetir el problema con otro nombre.
Lo que sí se ofrece es lo que se puede verificar hoy mismo: el sistema abierto, con los procesos de una operación de logística dentro, sin registro y con la marca de datos de ejemplo en pantalla; el conteo del proyecto real que lo sostiene, publicado en la página de evidencia con la hora del servidor al lado; y lo que es obligación suya y ningún sistema le quita.
Primero ve su sistema funcionando. Después decide. Ése es el único orden en el que el riesgo de construir no es suyo.
Preguntas frecuentes
¿Están diciendo que la automatización tradicional no sirve?
No. Sirve, y en procesos grandes y estables funciona bien. Lo que este artículo señala es el modelo con el que se contrata: cuando la unidad de cobro es el robot, el proveedor gana con más robots y no con más horas recuperadas, y eso determina qué procesos se proponen primero. Es una crítica al contrato, no a la tecnología.
¿Por qué no aparece el nombre de ningún competidor?
Porque no hemos auditado el software de nadie. Una revisión de sitios públicos permite afirmar qué publica y qué no publica una categoría, y permite describir modelos de licenciamiento y de órdenes de cambio. No permite afirmar que un producto ajeno funcione mal, así que no se afirma.
¿Esto significa que no debo medir a mi equipo?
Significa que medir y evaluar son dos cosas distintas y conviene decidir cuál está comprando. La medición de este sistema existe para ordenar tareas por repeticiones y segundos y ejecutar la primera; registra el proceso y no el contenido, enmascara el dato sensible en el propio equipo y tiene botón de pausa. Un producto pensado para evaluar personas no puede permitir pausas.
¿Cuánto tarda en arrancar?
Este artículo acaba de señalar que ninguno de los doce proveedores globales revisados publica plazo de arranque, así que publicar uno sin poder sostenerlo sería repetir el problema. Lo que sí se puede decir es el orden: primero aviso y firma, después observación, después priorización con la aritmética a la vista, y sólo al final ejecución.
¿Y si mi operación ya tiene robots construidos por otro proveedor?
Entonces la conversación útil empieza por las seis preguntas del apagado: qué puesto los detiene, en cuánto tiempo, con qué registro, con qué lista de lo que ejecutaron mal, si se detienen solos ante un caso desconocido y quién autoriza encenderlos otra vez. Esas respuestas valen más que cualquier comparación de funciones.
¿Dónde puedo comprobar lo que este artículo afirma del propio sistema?
En la página de evidencia, que publica los conteos del proyecto de logística generado por el motor con la hora del servidor, las citas de archivo y línea de la plataforma, y lo que es obligación suya. Y en el sistema en vivo, que se abre sin registro.
Referencias
- SPARTANE · mapa competitivo del dominio de software de gestión y automatización del transporte: quince proveedores revisados sobre sitios públicos, documentación oficial de producto y reportes a inversionistas, 27 de septiembre de 2026. Documento interno; no se publican nombres ni tarifarios de proveedores concretos, y lo que no se pudo verificar contra fuente primaria no se publica.
- Relevo · brochure de logística, 10 páginas: ejemplo de oportunidad detectada con su aritmética, ciclo de cuatro capacidades, seis controles de privacidad y arranque en cuatro pasos.
- Ley Federal de Protección de Datos Personales en Posesión de los Particulares, publicada en el Diario Oficial de la Federación el 20 de marzo de 2025, en vigor el 21 de marzo de 2025, con reforma publicada el 14 de noviembre de 2025. Sustituye a la ley del 5 de julio de 2010. Consultada el 27 de septiembre de 2026. ↗
- Complemento Carta Porte del comprobante fiscal digital, versión 3.1, publicado por el Servicio de Administración Tributaria el 17 de junio de 2024 y de uso obligatorio desde el 17 de julio de 2024. ↗
- Base de datos del motor de generación de sistemas de la casa, el proyecto de este sistema en el motor, consultada en modo de sólo lectura el 27 de septiembre de 2026 con fecha y hora tomadas del propio servidor. El nombre comercial del cliente está enmascarado y no se publica.
El modelo
Primero ve su sistema funcionando, sin costo y sin compromiso. Después decide si lo compra o lo renta.
No es un demo: es Relevo con sus procesos, sus áreas y su operación dentro. Entra, lo recorre y lo usa. Verlo no cuesta nada y no lo compromete a nada. Cuando decida, cobramos por resultados, no por entregables.
Siga por aquí