Entrevista · The CIO Times
Trece preguntas sobre ERP, inteligencia artificial, seguridad y transformación empresarial en Centroamérica. Versión en español de la entrevista publicada por The CIO Times.
Esta es la versión en español de la entrevista publicada originalmente en inglés por The CIO Times, el 7 de octubre de 2026, dentro de su sección de entrevistas. Las respuestas son las de Leonel Guillén Hernández, fundador de ERPLEXIA. La versión original, en inglés, está disponible en el sitio de la revista.
ERPLEXIA nace de años de trabajar dentro de las empresas: en banca, en multinacionales con operación en varios países y en educación. En todos esos entornos vimos lo mismo: se compraba un sistema, se implementaba, y aun así la operación seguía viviendo en hojas de cálculo. El sistema quedaba como un lugar para registrar, no para trabajar.
Por eso la misión original fue cambiar el concepto de lo que es un sistema para una empresa. La mayoría ve el software como un lugar donde se anota lo que ya pasó; nosotros lo vemos como una solución que ejecuta los procesos digitalizados y que, por eso mismo, produce los datos con los que se toman decisiones informadas. Quisimos llevarle esa idea a la mediana empresa de la región con la misma disciplina de ingeniería que aplica una gran organización a sus sistemas centrales, a un precio que una distribuidora familiar pueda pagar.
Lo que evolucionó fue el alcance. Al principio los clientes nos pedían implementar un sistema. Hoy nos piden una solución que responda a las necesidades constantes y cambiantes del negocio: la factura electrónica, las obligaciones que cambian por decreto, importadores cuyo inventario pasa dos meses en un barco, cadenas que venden en varios puntos de venta a la vez y equipos comerciales que viven en WhatsApp. El cumplimiento, la operación y la integración dejaron de ser una fase del proyecto y se convirtieron en el proyecto.
Por eso hoy operamos como ERPLEXIA, con una frase que resume la visión: transformamos procesos en sistemas inteligentes. Trabajamos sobre cuatro pilares —ERP, inteligencia artificial, automatización e integración— y en un orden que no negociamos: procesos, datos, automatización, IA, resultados. La visión no cambió; cambió todo lo que hace falta para cumplirla.
Para nosotros transformar no es instalar tecnología; es que la empresa opere distinto al día siguiente. Por eso no empezamos por la herramienta, empezamos por el problema. Todo proyecto arranca con un cambio de concepto, y es lo más importante que ofrecemos: pasar de un sistema que registra lo que se hizo a una solución que ejecuta el proceso de punta a punta, de manera que el dato que genera sirva para decidir.
«Registrar es llevar los libros. Decidir es gerenciar.»
Nuestra metodología tiene dos caras. Por un lado, alineamos los procesos al sistema, algo que los clientes resisten al principio porque siempre es más fácil doblar el software que la costumbre. Por otro, diseñamos en paralelo para que quien toma las decisiones entienda su entorno de un vistazo. Un proceso correcto pero invisible para la gerencia está implementado a medias.
Una importadora de repuestos que atiende a aseguradoras y talleres lo ilustra bien. Antes de nuestro trabajo, la operación corría sobre sistemas satélite: factura electrónica descentralizada, control de entregas por un lado, compras por otro y ninguna vista que conectara nada. Unificamos toda la cadena en Odoo, desde que la aseguradora adjudica el trabajo hasta que se registra el cobro, con visibilidad de compras, proyecciones, tiempos de entrega, repuestos pendientes y niveles de servicio. Hoy la gerencia ve la operación en lugar de reconstruirla después, y esos tableros cambiaron su estrategia comercial y logística.
El mismo principio funciona a una escala mucho más simple. Una distribuidora con la que trabajamos recibía sus pedidos en una hoja de cálculo que viajaba por WhatsApp; alguien los volvía a digitar, se perdían mensajes y nadie sabía en qué estado estaba un pedido. Llevamos ese flujo a Odoo para que las órdenes se creen en tiempo real. Desaparecieron la doble digitación y los errores de transcripción, y los tiempos de proceso bajaron desde la primera semana. Eso es transformación: el mismo equipo, el mismo cliente, otra velocidad.
El equilibrio viene de cómo construimos, no del discurso comercial. Tratamos el cumplimiento de cada país como una capa delgada y reemplazable sobre un núcleo estándar.
La profundidad regional es real y nos ha costado años ganarla. Cada factura electrónica tiene su propia gramática: medios de pago, condiciones de venta, la precisión decimal que exige la norma, exoneraciones y mucho más. Nada de eso se puede aproximar: o valida ante la administración tributaria o no valida.
Pero nada de eso vive en nuestros módulos núcleo. Vive en módulos puente que se acoplan a una instalación estándar de Odoo Enterprise, con código fuente en inglés, el español entregado por archivos de traducción y empaquetado comercial, para poder desplegarse en una empresa que nunca hemos visitado. Trabajamos de forma remota, en la misma zona horaria y en español, para Costa Rica, Panamá, el resto de Centroamérica y el mercado hispano de Estados Unidos.
Los propios clientes también nos llevan hacia afuera. Un cliente que importa de forma constante nos llevó a desarrollar un centro de mando de compras que maneja tránsito marítimo y aéreo, costo de importación en varias monedas y seguimiento por etapa aduanera: capacidades que tienen todo que ver con el comercio global. Un módulo nacido para un importador se despliega en otro país cambiando la capa de localización, no reescribiendo el producto.
Entender antes de construir: la diferencia está en cómo abordamos cada requerimiento. Más allá de implementar, en ERPLEXIA nos interesa entender el problema del cliente y sus procesos, y a partir de ahí recomendar una solución que llegue a producción con buenas prácticas y sin tocar el núcleo de Odoo. Hemos visto muchos casos en los que un integrador sobrescribe el núcleo para cumplir un requerimiento y el cliente queda congelado en esa versión.
«La personalización que ganó el negocio se vuelve, tres años después, la razón por la que el cliente no puede actualizarse.»
Nunca un motor paralelo: es una regla que no rompemos. Si Odoo tiene un motor de precios, las listas nativas son el único motor de precios. Si ya construimos un motor de autorización, todo requerimiento nuevo pasa por ese motor. Hemos retirado módulos propios antes de llegar a producción al descubrir que duplicaban algo que ya existía: un costo que asumimos nosotros en lugar de dejárselo al cliente como deuda técnica.
Construir por piezas: de ahí viene la adaptabilidad. Entregamos ecosistemas de módulos pequeños, no monolitos. La suite de sucursales de Acabados Automotrices Matrix se entregó así: un núcleo que mantiene coherentes bodega, diario y condición de pago al elegir sucursal, un puente de auditoría de punto de venta y una capa de reportería gerencial. El cliente que no necesita la analítica simplemente no instala esa pieza.
Disciplina operativa: de ahí viene la escalabilidad. Todo despliegue sale por Git hacia Odoo.sh, probado primero en una rama de pruebas, con control de versiones en cada entrega. Los scripts de migración arrancan en modo simulación y exigen una confirmación explícita para aplicar cambios. No hay modificaciones manuales en producción. Suena lógico, pero la realidad es que no todos los implementadores trabajan así, y es justamente lo que nos permite sostener con seguridad un portafolio grande de módulos.
En ERPLEXIA la IA es el cuarto paso, no el primero: procesos, datos, automatización y luego IA. Un modelo razonando sobre un proceso desordenado solo produce desorden más rápido. Cuando el proceso ya vive en el ERP, la IA se incorpora con una convicción clara: un agente es un usuario más, no un atajo.
Eso lo aplicamos en nuestro agente conversacional para Odoo. Empezó respondiendo en lenguaje natural sobre clientes, cotizaciones e inventario, y hoy también puede crear oportunidades, generar cotizaciones y actualizar contactos. Lo importante no fue el modelo de lenguaje sino los controles: cada acción que escribe en el sistema está limitada por compañía y por permisos, igual que la de cualquier usuario, y queda registrada.
El segundo lugar donde la IA se gana el sueldo es la entrada de información, donde el papel se encuentra con el ERP. En REPAUT, taller de carrocería y pintura que cotiza y vende a aseguradoras, cada expediente nace como un documento de la aseguradora con la lista de repuestos dañados, que llega desde una plataforma de subastas. Lo digitalizamos con inteligencia artificial, de modo que la lista entra al sistema como dato en lugar de ser retecleada por una recepcionista, y la empresa tiene visibilidad de los casos ganados y perdidos directamente en Odoo.
El tercero es el CRM, en el canal donde ya está el cliente. Operamos nuestra propia infraestructura de WhatsApp conectada a Odoo, que crea la oportunidad en el CRM en el momento en que alguien escribe, y automatizaciones que mueven información entre Odoo, Microsoft 365 y Google Workspace sin intervención manual. El patrón es siempre el mismo: IA y automatización donde las personas transcriben, y control estricto en todo lo que toca la contabilidad.
Garantizar un entorno cien por ciento libre de incidentes es materialmente imposible, pero construir una arquitectura resiliente basada en mejores prácticas sí es una obligación.
Nuestra forma de ver la seguridad viene de la experiencia en ciberseguridad bancaria y en gestión de riesgo de terceros bajo el marco NIST. Desde ahí entendemos dos cosas. La primera: el ERP es la joya de la corona, porque contiene la lista de precios, la cartera de clientes, la planilla y las declaraciones tributarias. La segunda: la seguridad es una responsabilidad compartida entre la plataforma, quien implementa y la empresa que opera el sistema todos los días. Por eso separamos con claridad lo que hace cada parte.
Lo que aporta la plataforma: en la nube de Odoo y en Odoo.sh, la información viaja cifrada por HTTPS y se almacena cifrada, las contraseñas se guardan con algoritmos de hash robustos y cada base de datos está aislada de las demás. Odoo mantiene respaldos diarios, semanales y mensuales replicados en varios centros de datos. Odoo.sh agrega ambientes de prueba con copias de producción en los que los correos y las tareas programadas quedan neutralizados, para probar sin afectar la operación real.
Lo que cuidamos en la implementación: diseñamos sobre la arquitectura segura por diseño de Odoo, sin tocar su núcleo. Nuestras reglas de desarrollo prohíben construir consultas concatenando texto, para no abrir por el código propio lo que la plataforma ya cierra. Configuramos permisos por rol y reglas de registro, y cuando varias empresas conviven en una misma instancia dejamos implementadas desde el día cero las barreras entre compañías. Todo cambio pasa primero por un ambiente de pruebas.
Lo que recomendamos al cliente después de salir a producción: activar la autenticación de doble factor obligatoria, que Odoo trae de forma nativa; usar contraseñas largas y cambiarlas de inmediato ante cualquier indicio de compromiso, como recomienda hoy el NIST; aplicar el principio de mínimo privilegio y revisar los accesos cada trimestre, sobre todo cuando alguien sale de la empresa; no compartir usuarios ni claves de API; activar el bloqueo con hash de los asientos contables publicados y, cuando el negocio lo exige, una bitácora de auditoría más detallada; descargar periódicamente un respaldo propio y probar que se puede restaurar; y hacer cualquier cambio futuro siempre por un ambiente de pruebas, nunca directo en producción.
Nuestro compromiso es entregar una plataforma bien diseñada y dejarle al cliente claridad sobre cómo operarla con seguridad. La operación diaria es de la empresa; nuestro trabajo es que tenga las herramientas y el criterio para hacerla bien, sin asfixiar la operación.
Odoo ha sido la ventaja que nos permitió cumplir la promesa de alinear procesos y sistemas. Como partner oficial apostamos a una plataforma que mejora por debajo de nosotros en lugar de una que tengamos que cargar solos, y eso cambia la economía de cada proyecto.
En la práctica nos da tres cosas. Primero, un núcleo completo: contabilidad, inventario, compras, ventas, manufactura, punto de venta, CRM y recursos humanos ya construidos, integrados entre sí y mantenidos, de modo que nuestro esfuerzo de ingeniería se va al último veinte por ciento que es propio del cliente. Segundo, una sola base de datos: cuando la compra, la venta y el cobro viven en el mismo lugar, el tablero gerencial deja de ser un ejercicio de consolidación y pasa a ser un reflejo en tiempo real de la operación. Tercero, infraestructura y hoja de ruta: despliegue por Git en Odoo.sh, ambientes de prueba y una evolución anual contra la cual planificar nuestro portafolio de módulos.
También explica la velocidad con la que crecemos. Odoo es lo bastante modular para adaptarse a casi cualquier nicho: un taller de carrocería, un importador de repuestos, una distribuidora o una cadena de puntos de venta parten del mismo núcleo funcional, y nosotros agregamos valor con una implementación alineada a la empresa y la capa de decisión que esa industria necesita. Además, Odoo nos refiere oportunidades a través de su portal de partners, lo que nos pone frente a empresas que ya decidieron transformarse. Como nuestro interés es que el producto nativo funcione y no vender alrededor de él, cada hora que no gastamos reconstruyendo lo que Odoo ya hace es una hora que el cliente recupera.
Para nosotros innovar no es sumar tecnología de moda; es quitarle fricción a la operación real. Eso se traduce en una atención muy especial a la última milla, justamente la parte que muchos integradores dejan fuera del alcance.
Algunos ejemplos. Para REPAUT construimos Suite Taller 360, un sistema de cuatro módulos que sigue cada vehículo desde el avalúo hasta la entrega a lo largo de doce etapas, con propuestas a la aseguradora con varios escenarios de cobertura, monitoreo de niveles de servicio por severidad y tableros de productividad de técnicos. Para DIMAPART, un centro de mando de importación y compras que sigue sus importaciones en tránsito, controla faltantes y reporta repuestos pendientes contra los niveles de servicio comprometidos. Para una distribuidora, el paso de pedidos por WhatsApp y hojas de cálculo a órdenes creadas en tiempo real en Odoo. Para Agro El Secreto, grupo agrícola de cuatro compañías, control de crédito y morosidad que retiene la factura hasta que un supervisor la aprueba.
Ninguno de estos desarrollos es glamoroso. Cada uno nació de un cliente concreto frente a una fricción concreta, y como cada uno se construye como producto pensado para sus necesidades, el siguiente cliente con un problema parecido ya parte de una solución probada.
Destacamos tres, porque cada uno muestra una forma distinta de la misma idea: hacer que un número exista y que un proceso deje de depender de la memoria de alguien.
DIMAPART: el dinero. Importadora y distribuidora de repuestos para aseguradoras y talleres. Su problema de fondo era la ceguera de margen, el mal más común entre importadores: el costo entra en dólares en una orden de compra, pasa dos meses en tránsito acumulando flete y aduana, y el ingreso sale en colones semanas después. Nadie podía decir cuánto dejaba una venta. Sobre el centro de mando de compras construimos un módulo que enlaza cada venta con las compras que la abastecen y produce un análisis de utilidad con la moneda convertida y el costo de importación distribuido, agrupable por cliente, línea o período. El precio dejó de ser una discusión y pasó a ser un análisis; hoy la estrategia comercial se enfoca en las líneas que mejoran la rentabilidad.
REPAUT: el tiempo. Un taller de carrocería vive o muere por el tiempo de ciclo y la calidad de sus trabajos. Antes del proyecto nadie podía decir dónde esperaba realmente un vehículo. Suite Taller 360 sigue cada vehículo por doce etapas definidas, mide niveles de servicio y productividad por técnico, y la digitalización de documentos con IA eliminó la transcripción manual de repuestos. El cuello de botella resultó no estar donde la gerencia creía, que es lo habitual. Además migramos el histórico al sistema para que también se pudiera analizar.
La distribuidora: la velocidad. Los pedidos se armaban en una hoja de cálculo, se enviaban por WhatsApp y alguien los volvía a digitar en el sistema. Cada pedido pasaba por varias manos antes de existir. Hoy las órdenes se crean en Odoo en tiempo real, con precios, inventario y crédito validados al momento; bodega y facturación ven el pedido en cuanto entra. Se eliminó la doble digitación, bajaron los errores y se acortó el tiempo entre que el cliente pide y la empresa despacha.
En los tres casos la secuencia fue la misma: alinear el proceso al sistema, hacer posible la métrica y después dejar que el negocio la gestione.
Cada una falla de forma distinta, y ahí está lo útil.
En educación, un sector que conocemos desde adentro, la restricción es el calendario y la gobernanza. Las decisiones pasan por órganos colegiados y hay ventanas del año académico en las que no se puede tocar un sistema en producción. El trabajo es tanto de planificación y manejo de actores como de configuración.
El comercio minorista es el menos indulgente. En Matrix, seis sucursales venden al mismo tiempo por punto de venta, y saber qué producto hay y en qué bodega está es crítico para comprar con eficiencia. La oportunidad está un nivel más arriba: esas transacciones, convertidas en tableros de vendedores y reportería consolidada, permiten comparar sucursales cada semana en lugar de adivinar.
La distribución es donde la complejidad se acumula: varias compañías y bodegas, cortes de ruta, producto perecedero, inventario importado que se financia meses antes de venderse y clientes que son a la vez oportunidad de venta y riesgo de crédito. Es también donde la informalidad digital es más común —pedidos por WhatsApp, hojas de cálculo que circulan entre vendedores— y por eso donde un proceso bien alineado da resultados más rápido. Llevar esos pedidos a órdenes en tiempo real, o ganar visibilidad real del margen de todo el catálogo, se vuelve más productivo que la mayoría de los recortes de gastos.
La oportunidad es que la disciplina se transfiere de una industria a otra. Los controles que construimos para que una empresa apruebe o no un descuento, o autorice ventas a clientes con alta morosidad, son los mismos que le permiten a otra crecer con control y eficiencia.
El panorama ha cambiado drásticamente. Hoy, los avances en inteligencia artificial y nuestra cultura de investigación constante nos permiten diseñar, iterar y entregar soluciones a una velocidad que era impensable hace apenas cinco años. Dejamos atrás los ciclos de desarrollo interminables y logramos ese equilibrio de tres maneras.
1. Estructura especializada y potenciada por tecnología: somos un equipo de especialistas, no una pirámide tradicional. El cliente no paga personal ocioso disfrazado de administración de proyectos. Integramos herramientas de IA en nuestro flujo de trabajo para investigar, desarrollar y auditar con una productividad muy alta, y todo lo que se produce pasa por la revisión de especialistas antes de llegar al cliente. Esa eficiencia se traslada directamente al costo del proyecto.
2. Co-creación y soluciones que maduran: cuando un cliente necesita algo que Odoo no resuelve de forma nativa, lo construimos junto con él bajo buenas prácticas y, desde el inicio, le explicamos que la parte general de esa solución se convertirá en un módulo de nuestra suite. Las reglas propias de su negocio y su información son suyas y no se comparten. A cambio, el cliente gana dos cosas: su solución no queda como un código aislado que nadie actualiza, sino que se mantiene y evoluciona con cada versión de Odoo dentro de nuestro plan de soporte; y cada mejora que otros proyectos aportan a ese módulo le llega también a él. Es un modelo en el que todos aportan y todos se benefician. Hoy contamos con soluciones para planilla, control de crédito, descuentos, sucursales, impresión, bodega, análisis de margen, gestión documental y auditoría, de modo que un proyecto nuevo arranca aprovechando la experiencia acumulada en lugar de pagar por empezar de cero.
3. La disciplina de no construir lo que ya existe: la forma más rápida de destruir un presupuesto de ERP es desarrollar a la medida lo que la plataforma ya hace bien. En el levantamiento llevamos los requerimientos hacia la funcionalidad nativa de Odoo y cotizamos alcance cerrado donde se puede, para que el cliente decida sin sorpresas. Cada cambio pasa por validaciones rigurosas —hoy mucho más rápidas gracias a la automatización— antes de llegar a su ambiente, porque atrapar un defecto ahí cuesta minutos y atraparlo en producción cuesta un día y la confianza del cliente.
En resumen, estandarizamos lo básico y automatizamos la calidad. Eso libera presupuesto y tiempo para que la verdadera innovación se concentre donde corresponde: en la parte de la operación que es única de cada negocio, entregando valor a la velocidad que el mercado exige.
Tres capas, y la primera es la más difícil de copiar porque solo se puede acumular con los años.
Mantenemos una base de conocimiento estructurada con lecciones de ingeniería documentadas a partir de incidentes reales de producción: el servicio que cambió de nombre entre versiones, el identificador que no es estable entre actualizaciones, el recálculo que en silencio agota los tiempos de la base de datos en cargas masivas. Cada lección se pagó una vez y no hay que volver a pagarla. Ese conocimiento está en un formato que nuestras propias herramientas consultan antes de escribir código, lo que hace que trabajemos más rápido y con más seguridad cada trimestre.
La segunda es la biblioteca de módulos propios con licencia comercial, ya en producción en varios clientes y países. Y hay una tercera que no se ve en una propuesta: la manera de pensar. No vendemos licencias ni horas; vendemos que el sistema ejecute el proceso y le muestre a la gerencia lo que está pasando.
«Un competidor puede convertirse en partner de Odoo mañana. Lo que no puede comprar son los años entendiendo mercados distintos.»
Tampoco puede comprar los errores de producción que ya superamos ni la confianza de clientes que hoy deciden con datos.
Vemos un ERP que deja de ser un lugar al que uno va y se convierte en un servicio que responde.
Durante décadas el trato fue que el negocio se adapta a la interfaz del software: aprenda los menús, dónde está el reporte, qué campo filtrar. Ese trato se está acabando. Un agente lee el modelo de datos, entiende el contexto y devuelve la respuesta —o ejecuta la acción— sin que nadie navegue a una pantalla. El vendedor que hoy manda el pedido por WhatsApp mañana lo dicta y el pedido ya está en Odoo. Eso cambia quién puede usar un ERP mucho más de lo que cambia lo que hace un ERP.
Para que eso sea seguro deben cumplirse tres condiciones, y es ahí donde estamos invirtiendo. El agente debe regirse por los mismos permisos que las personas. La trazabilidad se vuelve más importante, no menos, cuando quien actúa no es humano. Y la calidad del dato pasa a ser lo que define el resultado: un agente razonando sobre un catálogo contable mal armado o un margen mal calculado se equivocará con total seguridad y a velocidad de máquina.
Por eso insistimos en el orden de ERPLEXIA: procesos, datos, automatización, IA, resultados. Las empresas que más van a aprovechar la IA en los próximos cinco años son las que primero hicieron el trabajo poco glamoroso de alinear sus procesos y volver confiables sus números. El diferenciador no será qué modelo se conecta, sino si el ERP se diseñó lo bastante bien como para ponerle uno encima.
«Procesos, datos, automatización, IA, resultados. En ese orden, y sin saltarse ninguno.»
Una conversación de 30 minutos basta para saber si Odoo, la automatización o una integración resuelven tu problema — y qué costaría hacerlo bien.