StratOS, un sistema operativo para gestionar la empresa

StratOS conecta la operación de la empresa, prepara la información que necesita cada decisión y registra lo que pasó después. Así lo planteamos en EREA.

StratOS es la herramienta con la que EREA usa la inteligencia artificial para construir el sistema operativo digital de una empresa. Se monta sobre el ERP y los sistemas que la empresa ya tiene, y reúne en un mismo modelo lo que hoy está repartido entre sistemas, documentos y la experiencia de su gente. Sobre esa base trabajan juntas las personas y los agentes de IA, con tareas que tienen dueño, acciones con permisos y un registro de cada decisión con lo que pasó después.

Con StratOS, la empresa puede leer su operación completa, decidir con esa información y aprender de cada decisión. Lo opera la oficina StratEx de EREA junto con los dueños de cada proceso en el cliente, y se construye por partes, empezando donde más dinero se mueve.

Para ver qué cambia en la práctica, pensemos en una semana en una cadena de supermercados que opera sobre StratOS.

El lunes a primera hora, Lucía, compradora de abarrotes, abre un correo del proveedor de aceite: la entrega de esta semana va a llegar con la mitad de lo que se pidió. Antes de llamar a nadie, le pregunta a StratOS qué tan grave es.

StratOS cruza el inventario del centro de distribución con el de cada tienda y con la venta que se espera. Le muestra en qué tiendas se acabaría primero el aceite, para cuántos días alcanza lo que hay en bodega, cuánta venta se perdería y qué otras marcas tienen inventario para cubrir. También le recuerda que la próxima semana hay una promoción de ese aceite en todas las tiendas, financiada en parte por el proveedor. Hay algo que no puede confirmar: en tres tiendas el inventario no cuadra con la venta reciente. StratOS le abre una tarea al jefe de operaciones de tienda para que lo revise antes del martes al mediodía.

Después revisa el acuerdo comercial vigente. El proveedor se comprometió a un nivel de servicio mínimo y a compensar a la cadena cuando no lo cumple, y el faltante de esta semana entra en ese caso. StratOS calcula el monto con la venta que se va a perder y el margen que la cadena deja de ganar, y le prepara a Lucía un borrador de correo al proveedor que reclama la compensación. Lucía lo revisa, ajusta el tono y lo envía.

Con la información de mercado de Nielsen y CCR, StratOS revisa también cómo se mueve la marca fuera de la cadena. En el último trimestre la marca ganó participación en el mercado y la perdió en las tiendas de la cadena, y la competencia vende ese aceite a un precio más bajo. StratOS recalcula además el plan de crecimiento pactado con el proveedor para este año: con la venta que se pierde esta semana, el volumen queda por debajo de lo acordado, y eso cambia los descuentos por cumplimiento que corresponden al cierre.

El martes, el jefe de operaciones responde. En dos de esas tiendas hay producto en la bodega trasera que nadie había registrado, y la tercera sí está por quedarse sin aceite. StratOS corrige el inventario, vuelve a calcular y anota que en esas tiendas el conteo de la bodega trasera suele atrasarse, para tomarlo en cuenta la próxima vez.

El miércoles, Lucía llega a la reunión de compras con la información preparada. Tiene el margen completo de este proveedor comparado con el de su categoría, lo que invierte en promociones y la competitividad de su precio. Tiene también las opciones para la semana: repartir lo que llega dando prioridad a las tiendas que más venden, pedirle una parte del faltante a un segundo proveedor, con el inventario y el capital de trabajo que eso implica, o pasar la promoción a otra marca. Cada opción trae su efecto estimado en venta perdida, margen e inventario, con los supuestos a la vista. El equipo decide repartir con prioridad, comprar una parte al segundo proveedor y pasar la promoción a otra marca. También deja una regla escrita: una compra urgente a otro proveedor que suba el costo más de lo acordado necesita la aprobación del gerente de compras.

El jueves, la orden al segundo proveedor sale al ERP con su aprobación. El centro de distribución recibe el nuevo plan de despacho por tienda y las tiendas reciben el cambio de promoción. Un agente queda pendiente de la entrega del proveedor y de la venta de aceite tienda por tienda, le avisa a Lucía si alguna se acerca al quiebre y sigue el reclamo hasta que la compensación aparezca en la cuenta del proveedor.

Cuando llegue la próxima ronda de negociación con este proveedor, el dossier de Lucía ya va a tener lo que pasó esta semana: el faltante, la compensación cobrada, el efecto en el plan de crecimiento y la evolución de la marca en el mercado y en la cadena. Para llegar ahí, StratOS necesita conocer las tiendas, los productos, el inventario, los acuerdos comerciales y las reglas de esta cadena.

Los pilotos de IA y el contexto de la empresa

Casi todas las cadenas y distribuidores de la región ya pagan alguna herramienta de IA. Los equipos tienen licencias de asistentes que redactan y resumen, hay un chatbot que responde preguntas sobre algunos datos o documentos, y en una o dos áreas corre un piloto: un modelo de demanda en abastecimiento, otro de precios en comercial. Cada uno ayuda a quien lo usa. Pocos pueden señalar en qué línea del estado de resultados se nota.

Cada caso de uso se monta con el pedazo de contexto que alguien le pasó, mientras que lo que explica cómo opera la empresa está repartido entre el ERP, archivos de Excel, contratos, correos y la experiencia de quienes llevan años ahí. Sin eso, el asistente responde como un empleado recién contratado. El piloto de demanda no sabe que viene una promoción, el de precios no sabe que el proveedor está entregando incompleto, y ninguno registra qué se decidió con lo que propuso. Cada piloto nuevo vuelve a armar su conexión a los datos y empieza de cero.

Para que la IA cambie los resultados de una empresa hacen falta tres cosas. La primera es que conozca la empresa, con sus categorías, tiendas, proveedores, clientes, procedimientos y criterios conectados y al día. La segunda es que trabaje dentro de la operación, con tareas que tienen dueño, acciones con permisos y personas que deciden. La tercera es que la empresa aprenda, de modo que cada decisión quede registrada con su resultado y cada procedimiento pase de las personas a la IA a medida que demuestra que funciona.

En EREA planteamos la IA como parte de la gestión de la empresa, y por eso construimos StratOS como el sistema operativo sobre el que la empresa opera y decide. Conecta lo que hoy está repartido y permite que la gente y la IA trabajen sobre la misma base.

Ya lo estamos aplicando en varios procesos de nuestra propia firma y, en paralelo, con algunos clientes de retail y consumo masivo.

El contexto alrededor del modelo

Hoy cualquier empresa, incluida su competencia, puede contratar el mejor modelo de IA del mercado, y esos modelos mejoran y bajan de precio cada pocos meses. Un modelo así sabe mucho del mundo. Puede redactar un contrato, resumir un informe o explicar qué es la elasticidad de precio. De cómo se compra, se surte o se fija precio en una cadena concreta sabe casi nada.

Si se le pregunta cuánto aceite pedir para la próxima semana, va a dar una respuesta razonable para un supermercado cualquiera. Le falta saber que en esta cadena hay una promoción el jueves, que el proveedor entrega incompleto desde hace un mes y que dos tiendas acaban de cambiar de formato. Con esa información, la misma pregunta tiene otra respuesta.

La diferencia la hace el contexto que se construye alrededor del modelo: cómo opera la empresa, con qué criterio decide y qué decidió antes. Ese contexto crece con la operación diaria y con lo que pasa en el mercado. Cada tarea cerrada y cada corrección de un gerente le agregan algo, y lo mismo pasa con cada movimiento de un competidor. Ese contexto hay que levantarlo, ordenarlo y mantenerlo al día en cada empresa.

En StratOS le sumamos lo que EREA ha visto funcionar en retail y consumo masivo en la región: procedimientos que ya se probaron en otras cadenas, los indicadores con que se mide cada decisión y los errores más comunes al ponerlos en marcha. Una cadena que empieza no tiene que explicarle al sistema qué es una categoría destino o por qué un quiebre en un producto ancla pesa más que en el resto. Cada cliente parte de esa base, la ajusta a su operación y mantiene su propio conocimiento separado del de los demás. Cuando aparezca un modelo mejor, se cambia, y el contexto construido sigue sirviendo con el modelo nuevo.

La ontología de la empresa

En el centro de StratOS hay una ontología, que es un modelo de la empresa armado con los objetos con los que piensa un gerente. Categorías, tiendas, proveedores, promociones, indicadores y objetivos, cada uno con sus atributos y conectado con los demás. Una tienda tiene un formato, compite con ciertas tiendas de la competencia y la surte cierto centro de distribución. Un producto pertenece a una categoría y cumple un papel dentro de ella.

En el ERP esos objetos son tablas sueltas. En el escenario del lunes, saber en qué tiendas se acaba primero el aceite, qué dice el acuerdo con el proveedor y cómo se mueve la marca en el mercado obliga a cruzar ventas, inventario, contratos y datos de mercado, y hoy ese cruce lo hace alguien a mano. Con la ontología, el cruce ya está armado y la pregunta se responde en minutos.

Los datos alcanzan para una parte. Las reglas están en manuales, políticas y contratos, y muchas excepciones solo las conoce quien decide: que en ciertas tiendas el conteo de la bodega trasera se atrasa, por ejemplo, no aparece en ninguna tabla. Por eso la ontología se llena leyendo sistemas y documentos y entrevistando a las personas. Lo que los datos y los documentos no resuelven se le pregunta a quien sabe la respuesta, y nada entra sin que alguien de la empresa lo revise.

La ontología crece con cada problema que se resuelve, y lo que se modeló para abastecimiento sirve después para precios o para surtido.

Cómo opera StratOS

Con la ontología como base, StratOS hace tres cosas.

Entiende la empresa, porque la ve conectada y al día. Ventas, inventario, contratos, procedimientos y datos de mercado se actualizan en el mismo modelo, y cualquier persona con los permisos necesarios puede preguntar en su propio lenguaje. Cuando Lucía preguntó qué tan grave era el faltante de aceite, la respuesta cruzó en minutos información que hoy vive en varios sistemas distintos y en el correo de un proveedor.

Actúa dentro de la operación. Sobre esa vista corren tareas con dueño y fecha, y agentes que vigilan indicadores, detectan lo que se sale de lo esperado y preparan propuestas. Las acciones tienen permisos: el sistema sabe qué se puede hacer sobre cada objeto, quién puede hacerlo y con qué aprobación. En el escenario del aceite, el agente redactó el reclamo al proveedor y quien lo envió fue Lucía. La orden al segundo proveedor salió al ERP cuando tuvo la aprobación que la regla pedía. Quien decide sigue siendo una persona.

Y aprende, porque cada decisión se registra con la información que se usó y con lo que pasó después. Cuando un gerente corrige una propuesta, la corrección también queda, como quedó la nota sobre el conteo de la bodega trasera. Con el tiempo, ese registro describe cómo decide la empresa en la práctica, incluidas sus reglas no escritas. Sirve para medir qué decisiones funcionaron, para que la siguiente propuesta parta de ahí y para que lo que sabe una persona siga disponible cuando cambia de puesto o deja la empresa.

Cómo madura un procedimiento

Un procedimiento entra a StratOS escrito y probado, con dueño y registro. Antes de que el sistema lo opere, se escribe paso por paso con quien lo ejecuta hoy, con ejemplos reales de lo que entra y de lo que sale, y se prueba hasta que otra persona pueda ejecutarlo solo con lo escrito. Ese trabajo suele mostrar pasos duplicados, decisiones que dependen de una sola persona y excepciones que nadie había documentado.

Cada procedimiento mezcla tres tipos de actividad. Hay actividades determinísticas, como extraer datos, cargarlos y hacer cálculos. Hay actividades de criterio, donde alguien interpreta la situación y decide. Y hay actividades de producción de documentos, como armar el reporte, la presentación o el correo al proveedor.

A partir de ahí cada actividad avanza por separado. En un pedido de reposición, extraer ventas y calcular el sugerido pasan pronto al sistema. Revisar excepciones o ajustar por una promoción toma más: primero el sistema propone y el comprador decide, y solo cuando las propuestas se aprueban casi sin cambios empieza a ejecutar con revisión. Generar la orden y el correo al proveedor puede pasar a la IA temprano, con una persona que revisa antes de enviar. Aprobar un pedido grande puede quedarse siempre con una persona.

Cada cambio de nivel se justifica con lo que mostró el nivel anterior y lo autoriza la dirección. Una actividad sube cuando el procedimiento está escrito y probado, cuando las propuestas se aprueban casi sin cambios o cuando los errores quedan por debajo del umbral acordado. Que la IA ejecute y otra IA vigile queda reservado para decisiones de bajo riesgo.

Así el avance se ve en indicadores del propio procedimiento: cuánto tiempo le dedica la persona, cuánto tarda el ciclo, cuántos errores hay que corregir y cuánto volumen atiende el mismo equipo.

Qué lo separa de un dashboard o de un piloto

Muchas empresas ya tienen buenas herramientas de inteligencia de negocios (BI). Un dashboard muestra lo que pasó y deja a alguien la tarea de interpretarlo, decidir y avisar a quien ejecuta. En el escenario del lunes, el dashboard habría mostrado los quiebres de aceite cuando ya estaban en las tiendas. La revisión del contrato, el cálculo del reclamo, las opciones para el comité y el cambio de promoción habrían salido de correos, archivos de Excel y reuniones.

Un piloto de IA resuelve bien un problema acotado, con su propio contexto y su propia conexión a los datos. El segundo piloto vuelve a armar casi todo, y el tercero también. Al final la empresa tiene varias herramientas que no comparten datos ni reglas, cada una con su proveedor y su mantenimiento, y nadie que responda por el resultado conjunto.

El ERP sigue registrando las transacciones y el BI sigue mostrando los indicadores. StratOS se monta sobre ambos y agrega la capa donde se conectan los datos, las reglas y las personas, donde se decide y donde queda registro de lo que pasó. Cada problema nuevo se resuelve sobre lo que dejó el anterior: lo que se modeló para el aceite sirve para la siguiente categoría, y la regla que el comité fijó el miércoles se aplica de forma automática la próxima vez.

También cambia quién lo sostiene. Un equipo de EREA lo opera junto con los dueños de cada proceso en la empresa, que van tomando más peso a medida que el sistema crece. Lo que se construye queda funcionando en la operación, con indicadores que la alta dirección puede seguir.

Cómo cambia la forma de dirigir

Cuando una empresa opera sobre un sistema así, cambia el trabajo de la alta dirección.

En retail, buena parte del margen del año se decide en la mesa con los proveedores. Con StratOS, el comprador llega a cada ronda con la rentabilidad completa de cada proveedor, lo que se cobró y lo que quedó pendiente durante el año, y la evolución de cada marca en el mercado y en la cadena.

En la reunión de compras del miércoles, el equipo discutió opciones que ya traían su efecto estimado en venta, margen e inventario, sin pasar la primera parte de la reunión reconstruyendo qué había pasado. Después, cada decisión se compara con lo que se esperaba.

La alta dirección puede seguir la ejecución en un solo lugar, porque las tareas tienen dueño y fecha, se cierran y se miden, y todas las áreas trabajan sobre la misma capa. La pregunta de en qué quedó algo se responde sin escribirle a nadie.

El equipo dedica menos tiempo a extraer datos, armar reportes y perseguir información, y más a decidir, corregir lo que el sistema propone y atender las excepciones.

Una tienda, una categoría o un país nuevo entra sobre la misma capa, con lo que ya se aprendió en los anteriores. Los objetivos quedan conectados con los indicadores y estos con las tareas que los mueven, así que el plan se ajusta con evidencia durante el año, sin esperar la revisión anual.

El IAEX, lo que cuesta operar con IA

Una empresa registra lo que gasta en IA en cuentas conocidas: el CAPEX de la infraestructura, el OPEX de las licencias y el STRATEX del proyecto que la pone en marcha. Operar con IA genera además un gasto que esas cuentas no muestran completo. A esa cuenta la llamamos IAEX, un concepto que desarrollamos con Roberto Aguirre, director en EREA Management Consulting.

El IAEX tiene dos partes. La primera es el consumo: lo que se paga a los proveedores de modelos y de nube cada vez que un agente lee, calcula o redacta. A diferencia de una licencia, ese costo crece con el uso y depende de cómo está diseñado cada proceso, porque un procedimiento mal escrito hace que la IA lea, pregunte y rehaga más de lo necesario. La segunda es el tiempo de la gente para aprender a usar la IA, supervisar lo que produce y desarmar hábitos de años. Esa parte no aparece en ninguna factura, y por eso casi ninguna empresa la presupuesta.

Con el ERP, el tiempo de aprender se pagaba una vez y se cerraba con el proyecto. Con la IA se repite, porque revisar lo que la máquina propone exige el mismo criterio que hacerlo a mano, y las herramientas cambian cada pocos meses. Si nada de lo que la gente corrige queda guardado, la empresa paga esas horas cada semana y las vuelve a pagar cada vez que alguien deja su puesto.

El IAEX se convierte en inversión cuando el contexto que deja se captura y se reutiliza. La semana de Lucía es un ejemplo: el jefe de operaciones fue a la bodega, Lucía revisó el borrador del reclamo y el equipo de compras decidió, y el sistema guardó lo que cada uno sabía. La próxima vez esa revisión toma menos tiempo, porque el criterio ya está escrito.

Capturar contexto tiene un riesgo que hay que atender desde el diseño. Cuando una persona delega la redacción o el análisis en la IA y acepta un error sin notarlo, ese error entra al contexto y condiciona el trabajo siguiente. Con el tiempo, el equipo puede perder práctica en estructurar sus propias ideas, porque un documento bien diagramado parece terminado aunque le falte el concepto de fondo.

En StratOS lo planteamos con una revisión diaria. Lo que cada persona trabajó en el día queda registrado, se revisa contra los estándares acordados antes de que la IA lo vuelva a usar y, si hay un error de concepto o de procedimiento, se corrige y la persona recibe una nota con lo que debe hacer distinto. Alguien del equipo lee cada semana una muestra de esas correcciones, para que el revisor automático no propague sus propios errores. Con eso los errores no se acumulan en el contexto y la persona aprende con cada nota. Esa revisión es una forma de supervisión, y se acuerda desde el inicio con el equipo y con la alta dirección. Su propósito es mantener limpio el contexto y que cada persona mejore su trabajo: las notas llegan a la persona, y quién más puede verlas queda definido en ese acuerdo.

StratOS es también el lugar donde esta cuenta se puede medir, en sus dos partes. Cada agente registra lo que consume y cada tarea tiene dueño y fecha, así que el costo de cada procedimiento queda visible: lo que se paga a los proveedores de IA y las horas de revisión y aprobación que todavía exige. A medida que un procedimiento madura se ve cuántas horas libera y cuánto cuesta ejecutarlo. Para la alta dirección, eso convierte el IAEX, que hoy está repartido o no se ve, en una línea con dueño y con indicador.

Los proyectos de EREA, habilitados con IA

StratOS también cambió cómo trabaja EREA. Todos nuestros proyectos son ahora IA enabled, es decir, habilitados con IA desde el inicio. La negociación con proveedores, la optimización de negocios en red y el resto de nuestras prácticas se arman desde la primera fase sobre el StratOS de EREA.

En la práctica, el diagnóstico, los análisis y los acuerdos de cada proyecto quedan desde el primer día en un sistema que entiende la empresa del cliente, con la misma ontología, los mismos procedimientos y el mismo registro de decisiones que describe este artículo. El proyecto se conecta a los sistemas que el cliente ya tiene y convive con ellos. Al cerrar, lo construido sigue funcionando dentro de su operación y puede convertirse en la primera parte de su propio sistema operativo digital.

Un cliente que contrata una negociación con proveedores, por ejemplo, recibe los resultados de la ronda y también el dossier de cada proveedor, las reglas acordadas y el seguimiento de cobro operando sobre StratOS, listos para el siguiente ciclo.

Por dónde empezar

Antes de construir nada, el diagnóstico de StratOS mide dos cosas: dónde está la oportunidad y qué tan lista está la empresa para aprovecharla.

La oportunidad está en las decisiones que más dinero mueven, como la negociación con proveedores, los precios, el surtido, la reposición o las promociones, y en cuánto cambiaría el resultado si se tomaran con mejor información y más rápido. Para estimarla se usan los datos de la propia empresa de los últimos años y entrevistas con quienes toman esas decisiones hoy.

En retail, la negociación con proveedores suele ser el mejor lugar para empezar. EREA tiene una práctica propia para eso, Fact-Based Negotiations (FBN), con la que ha acompañado la negociación de más de 80 mil millones de dólares en compras en 35 proyectos. Los resultados van de uno a más de seis puntos sobre la compra negociada. El método mide la rentabilidad completa de cada proveedor en cada categoría, sumando lo que entrega fuera de factura y restando lo que la cadena absorbe en merma, logística y precio. Con esa medida ubica a cada proveedor contra su categoría, convierte cada desequilibrio en una petición en puntos sobre la venta y le entrega al comprador un dossier con más detalle que el que trae el proveedor.

Sobre StratOS, ese método deja de depender del ciclo anual. Los dossiers se mantienen al día para toda la base de proveedores con el mismo criterio, los incumplimientos se cobran cuando ocurren, como el faltante de aceite de Lucía, y un agente sigue cada acuerdo hasta que lo pactado aparece en el resultado. Cuando llega la siguiente ronda, el comprador parte de lo que se cobró, de lo que quedó pendiente y de cómo se movió cada marca en el mercado. En el diagnóstico, la oportunidad en negociación se estima en puntos sobre las compras, con dos años de datos cerrados de la propia empresa.

La capacidad depende del estado de los datos, de qué tan escritos están los procesos y de quién en la empresa puede hacerse dueño de cada uno. Una empresa con datos ordenados y procesos claros avanza más rápido. Una con información repartida necesita primero una base técnica, y el diagnóstico dice cuál y cuánto trabajo toma.

El diagnóstico termina con las decisiones de la empresa ordenadas por su valor, lo que falta para operarlas sobre StratOS y una propuesta de por dónde empezar. La primera aplicación va donde más dinero se mueve, con una línea base medida desde el inicio, y cada paso siguiente se decide con los resultados del anterior.

Cuando la operación se puede leer completa, aparece otra pregunta para la alta dirección: cuáles de las decisiones que llegan a su mesa llegan porque la necesitan, y cuáles solo porque la información no estaba más abajo.