Por qué construimos nuestro propio ERP en Eximus
Cuando banco, nómina, facturación, cobranzas e integraciones viven en sistemas separados, el problema ya no es falta de esfuerzo: es falta de una capa operativa con criterio compartido.
Andrés Marín · 28/4/2026
Por qué importa
La operación crítica se pone a prueba bajo presión, no cuando todo está en calma
Estos recursos ayudan a líderes técnicos a tomar mejores decisiones sobre continuidad, modernización y riesgo operativo.
Artículo
Qué cubre este artículo
Hay un punto en la operación de una empresa donde seguir trabajando entre bancos, hojas de cálculo, portales externos, correos, reportes manuales y herramientas aisladas deja de ser "normal" y empieza a salir caro.
No siempre caro en dinero inmediato. A veces el costo aparece como reproceso, cierres lentos, conciliaciones frágiles, decisiones tardías y equipos que gastan más energía reconstruyendo contexto que administrando el negocio.
Eso fue lo que empezamos a ver en Eximus.
Por eso empezamos a construir EximusERP — internamente, Eximus Finance Ops — como una capa operativa para conectar piezas críticas de la administración, dejar trazabilidad real y reducir la dependencia de puentes manuales.
El problema no era falta de software
De hecho, herramientas ya había.
El banco resolvía una parte. La contabilidad formal vivía en otra plataforma. El trabajo ejecutado estaba en Azure DevOps. Los soportes aparecían en documentos y correos. La facturación y la cartera seguían otra lógica. Y cuando tocaba responder preguntas simples — qué se pagó, qué se cobró, qué falta por facturar, qué colaborador ya quedó liquidado o qué movimiento ya está conciliado — había que abrir demasiadas pestañas y recomponer la historia a mano.
Ahí entendimos que el cuello de botella no estaba solo en capturar datos. Estaba en no tener un modelo operativo propio.
Lo que decidimos construir
No planteamos EximusERP como “otro sistema más”. Lo planteamos como una capa que centraliza la operación financiera interna y convierte procesos repetitivos en flujos gobernables.
Eso implica respetar reglas que, en nuestro caso, no eran negociables:
- operación multimoneda con lectura analítica en COP,
- importaciones bancarias históricas y operativas con idempotencia,
- liquidaciones conectadas con trabajo ejecutado en Azure DevOps,
- facturación con reglas distintas según el tipo de acuerdo,
- flujos de billing y cartera integrados con Siigo,
- conciliación entre movimientos bancarios y eventos operativos,
- y trazabilidad completa de corridas, incidencias y fuentes de datos.
Ese tipo de operación muchas veces termina resuelto con combinaciones de Excel, scripts sueltos y revisiones manuales. Nosotros preferimos convertirlo en producto interno.
Dónde empieza a cambiar la operación
Una de las primeras mejoras no fue “automatizar más”. Fue poder leer la caja con más confianza.
EximusERP ya soporta importaciones históricas y operativas desde cuentas como Davivienda y Global66 en COP, USD y EUR. Trabaja con un modelo multimoneda, pero conserva COP como moneda base de análisis. Además, diferencia transferencias internas y conversiones para no tratarlas erróneamente como ingresos o gastos.
Ese detalle se vuelve útil de verdad cuando el proceso puede correrse más de una vez sin miedo. Las importaciones fueron diseñadas para ser idempotentes: cada fila se normaliza, genera un fingerprint determinístico y se compara contra restricciones únicas antes de entrar al sistema.
Parece un detalle técnico menor, pero no lo es. Cuando un proceso no es idempotente, cada reintento da miedo. Cuando sí lo es, reintentar deja de ser una amenaza y se vuelve parte normal de una operación seria.
Automatización útil no es solo ejecución
Otro frente importante fue sacar procesos de scripts opacos y llevarlos a una capa de ejecuciones gobernables.
EximusERP maneja tipos de ejecución, perfiles reutilizables, solicitudes lanzadas desde interfaz o API y una traza consolidada en sync_runs, con detalle por hoja e incidencias por corrida. Eso significa que una importación no queda registrada solo como “algo que corrió”, sino como un evento operativo con contexto: qué perfil se usó, qué archivo entró, qué pasó en cada hoja, qué warnings aparecieron y qué errores requieren revisión.
Esa diferencia importa mucho más de lo que parece. En una empresa que crece, automatizar sin evidencia solo cambia de lugar la incertidumbre. Automatizar con trazabilidad sí reduce fricción real.
Nómina, billing y cobranzas dejan de vivir aislados
En una empresa de servicios intensivos en conocimiento, la operación administrativa no está separada de la ejecución. Por eso uno de los módulos más valiosos es el de nómina.
EximusERP toma tareas cerradas en Azure DevOps con trabajo completado, las cruza con colaboradores y construye liquidaciones con historial, estados y trazabilidad por ítem. La idea no es solo “integrar ADO”, sino convertir trabajo técnico en señal administrativa confiable.
Lo mismo pasa con billing. No todos los acuerdos comerciales funcionan igual, así que no tiene sentido forzarlos a una sola regla. El sistema maneja reglas por tipo de acuerdo, revisión por cliente, preview de correo y cierre con trazabilidad por factura.
Y después aparece el siguiente cuello de botella: cobrar y conciliar. Ahí también decidimos dejar de tratar la cartera como un proceso externo al resto de la operación. EximusERP ya documenta flujos para sincronizar facturas, normalizar estados operativos, registrar notificaciones y buscar conciliación automática contra movimientos bancarios.
Lo valioso no es reemplazar todo, sino conectar con criterio
EximusERP no pretende borrar de un golpe todos los sistemas externos. Sería una mala lectura del problema.
La empresa ya opera sobre bancos, Azure DevOps, Siigo y otros servicios. El valor de esta capa está en conectarlos con reglas propias, trazabilidad compartida y una lectura operativa mucho más clara.
Si hubiera que resumir el aporte en una sola idea, sería esta: menos interpretación manual, más criterio compartido.
Eso se traduce en varias cosas:
- una sola lectura operativa de movimientos, facturas y liquidaciones,
- menos dependencia de archivos intermedios y memoria humana,
- mejor capacidad para auditar qué pasó en cada proceso,
- integraciones reutilizables en lugar de parches por módulo,
- y una base mucho más sólida para automatizar sin perder control.
Lo que aprendimos construyéndolo
Hay varias lecciones que aplican mucho más allá de este sistema.
La primera es que el problema real casi nunca es la interfaz. Es el modelo. Si no existe un maestro confiable de terceros, clientes, acuerdos o movimientos, cualquier automatización amplifica errores.
La segunda es que en operaciones sensibles, idempotencia y trazabilidad valen más que una sensación superficial de velocidad. Lo importante no es correr una vez rápido. Lo importante es poder correr, revisar, corregir y volver a correr sin romper la confianza del proceso.
La tercera es que no todo debe ser automático, pero todo sí debería ser visible. Hay decisiones que siguen requiriendo criterio humano. Lo correcto no es esconderlas, sino diseñar el sistema para que queden asistidas y trazables.
Y la cuarta es que construir herramientas internas también fortalece el criterio externo. Te obliga a vivir problemas reales de integración, gobernanza, conciliación, deuda de procesos y adopción operativa, no solo a hablar de ellos.
El siguiente paso útil
Para nosotros, EximusERP es una forma de operar con menos fricción y mejor contexto. Pero también es una evidencia práctica de cómo entendemos el software: no como pantallas aisladas, sino como sistemas que conectan decisiones, reducen ambigüedad y vuelven la operación más gobernable.
Si tu empresa también vive entre procesos manuales, datos repartidos e integraciones frágiles, probablemente el problema no sea falta de disciplina. Probablemente falta una capa operativa diseñada de verdad para cómo funciona tu negocio.
Si quieres profundizar en cómo ordenamos datos y criterios operativos, puedes seguir con Gobierno y cumplimiento de datos. Y si estás evaluando construir o reordenar una plataforma interna, revisa cómo trabajamos el Desarrollo de Software de Negocio.
Tema relacionado
Explora más sobre este tema
Este artículo forma parte de un conjunto de recursos sobre el mismo tema. Vuelve al inicio del tema para ver el contexto completo.
Articulo
Gobierno y cumplimiento de datos
Cómo ordenar acceso, reporting y linaje cuando los datos ya son una responsabilidad operativa, no solo técnica.
Capacidades relacionadas
Servicios que aplican este enfoque
Más contenido
Sigue explorando
data governance compliance
Gobierno y cumplimiento de datos
Cómo ordenar acceso, reporting y linaje cuando los datos ya son una responsabilidad operativa, no solo técnica.
data governance compliance
Migración de software de escritorio y procesos SSIS
Cómo migrar apps de escritorio y paquetes SSIS sin romper cierres, ETL ni reportes críticos.