Glori Ibarra — Anagrama
Cuando un dueño de empresa evalúa digitalizar un proceso, rara vez la primera duda es tecnológica. La duda real, la que no siempre se dice en voz alta, es otra: ¿y si esto detiene lo que ya funciona? Llevo veinte años dirigiendo operación, procesos y agroindustria, y desde hace algunos me dedico a construir software con inteligencia artificial. La pregunta no cambió. Lo que cambió es qué tan rápido, y con cuánto menos riesgo, se puede contestar bien.
El rechazo a un sistema nuevo rara vez tiene que ver con si funciona o no. Tiene que ver con la gente que ya opera el proceso todos los días: teme que el cambio le sume trabajo antes de quitárselo, o que alguien interprete mal cómo hacen las cosas y termine imponiendo un procedimiento que no calza con su operación real. Es una resistencia razonable, nacida de haber visto antes un proyecto de sistemas que sí interrumpió la operación para "mejorarla".
Esa dinámica se repite en operaciones de campo: cuadrillas con su propia lógica de trabajo, construida durante años, a las que de pronto se les pide capturar información distinto porque el sistema nuevo "así lo pide". El sistema puede ser impecable en el papel. Si obliga a la operación a acomodarse a él, ya perdió antes de arrancar.
La forma en que trabajamos en Anagrama parte de una decisión poco común en cómo se venden los proyectos de tecnología. Antes de construir nada, documentamos el proceso como realmente ocurre — no como dice el manual, no como se explica en la primera reunión. Ahí entran las excepciones: quién cobra distinto, qué se hace cuando falla la conexión, qué pasa cuando el encargado no está. Son, casi siempre, lo primero que rompe un sistema nuevo, porque nunca llegaron al requerimiento original.
Con esa documentación se gobierna después el trabajo de los agentes de inteligencia artificial que ayudan a construir la solución, y se definen las pruebas que debe pasar antes de darse por terminada. No es una promesa de que nada va a cambiar — va a cambiar, porque el objetivo es poner orden donde hoy hay papel, WhatsApp o una hoja de Excel que solo una persona sabe interpretar. Es una promesa distinta: que el cambio se diseña a partir de cómo ya trabaja tu gente, y no al revés.
La segunda decisión que más reduce el riesgo de interrupción tiene que ver con el calendario, no con la tecnología: arrancar con una porción pequeña de la operación — una sola unidad, un solo equipo, una sola sucursal — antes de pensar en escalarlo a toda la empresa. Algunos dueños llegan proponiendo justo eso por su cuenta, sin que nadie se los sugiera: empezar por la parte de la operación donde la estructura ya es sólida, mostrar el beneficio ahí, y solo entonces decidir si vale la pena extenderlo. Es más lento en apariencia. Es la única forma de que, si algo no calzó, el costo de corregirlo sea pequeño y no una crisis operativa.
Esto también cambia cómo debe verse el primer contacto con el equipo que implementa. No debería ser alguien explicando pantallas, sino alguien que se sienta a entender la dinámica del área antes de pedirle a nadie que cambie cómo trabaja. Cuando eso pasa, la resistencia inicial suele bajar sola: la gente nota la diferencia entre quien llega a imponer y quien llega a entender primero.
Si estás evaluando dar este paso, hay tres preguntas que puedes hacerle a cualquier proveedor — nosotros incluidos — antes de aprobar el proyecto:
La pregunta que en realidad importa no es qué tan avanzada es la tecnología que te ofrecen. Es si esa tecnología se construyó a partir de cómo ya trabaja tu empresa, o si te está pidiendo a ti que te adaptes a ella.
Empieza con un diagnóstico, no con una cotización. Escríbeme y cuéntame qué proceso de tu empresa depende hoy de una sola persona.
glori.ibarra@anagrama.mx