Caso Ecolia: Cómo una PyME construyó un ERP de nivel mundial en Azure con Django y Siigo

Cuando Ecolia llegó a nosotros, su "sistema de gestión" era una carpeta compartida en Google Drive con 47 hojas de Excel. Cada área tenía la suya: ventas, contratos, inventario de equipos, nómina, reportes para clientes. La información nunca coincidía y nadie sabía cuál era la versión más reciente.

18 meses después, Ecolia opera sobre un ERP a medida construido en Azure App Service, con backend en Python/Django, base de datos SQL Server y sincronización contable automática con Siigo Nube. Este artículo documenta cada decisión técnica, los errores que cometimos y los resultados reales en producción.

1. El problema: gestionar una empresa en Excel

Ecolia es una empresa mediana de servicios ambientales con operaciones en tres ciudades colombianas. Con 80 empleados y más de 200 contratos activos, el modelo de "una hoja de Excel por proceso" había colapsado. Estos eran sus puntos de dolor concretos:

2. La arquitectura: decisiones técnicas y por qué las tomamos

Antes de escribir una línea de código, pasamos 3 semanas en discovery: entrevistas con cada jefe de área, mapeo de flujos de datos y análisis de integraciones críticas. El resultado fue una arquitectura modular en Azure con un backend Django como núcleo.

¿Por qué Django y no Laravel, Node o un ERP off-the-shelf?

Evaluamos cuatro opciones: Odoo Community, SAP Business One, Laravel + Vue y Python Django + Next.js. La decisión de ir con Django no fue automática — fue el resultado de ponderar tres variables críticas para Ecolia:

1. Velocidad de desarrollo: el ecosistema de Django (ORM, admin, DRF) permite construir módulos de negocio complejos en días, no semanas. Para una PyME con presupuesto ajustado, esto es determinante.
2. Integración con Siigo: Siigo expone una API REST bien documentada. Django REST Framework simplifica la creación de la capa de sincronización bidireccional sin fricciones.
3. Costo de mantenimiento: Python es el lenguaje más conocido por científicos de datos y automatizadores. El mismo equipo que mantiene el ERP puede crear scripts de RPA o modelos predictivos sin cambiar de stack.

3. Integración Siigo API: el núcleo contable automatizado

La integración con la API de Siigo Nube fue el componente más crítico del proyecto. El objetivo: eliminar la doble digitación contable. Cada factura generada en el ERP debía aparecer automáticamente en Siigo sin intervención humana, y cada pago registrado en Siigo debía actualizar el estado de la cuenta corriente en el ERP.

Flujo de autenticación y sincronización

import requests
from django.core.cache import cache
from django.conf import settings

class SiigoClient:
    """
    Cliente para la API REST de Siigo Nube.
    Gestiona tokens OAuth2 con renovación automática vía cache Django.
    """
    BASE_URL = "https://api.siigo.com/v1"
    TOKEN_KEY = "siigo_access_token"

    def _get_token(self) -> str:
        token = cache.get(self.TOKEN_KEY)
        if token:
            return token

        resp = requests.post(
            "https://api.siigo.com/auth/access-token",
            json={
                "partner_id": settings.SIIGO_PARTNER_ID,
                "username": settings.SIIGO_USERNAME,
                "access_key": settings.SIIGO_ACCESS_KEY,
            },
            timeout=10,
        )
        resp.raise_for_status()
        data = resp.json()
        # Siigo tokens duran 24 h; guardamos con TTL de 23 h para renovar antes
        cache.set(self.TOKEN_KEY, data["access_token"], timeout=82800)
        return data["access_token"]

    def _headers(self) -> dict:
        return {
            "Authorization": f"Bearer {self._get_token()}",
            "Content-Type": "application/json",
            "Partner-Id": settings.SIIGO_PARTNER_ID,
        }

    def create_invoice(self, invoice_data: dict) -> dict:
        """Crea una factura electrónica en Siigo desde los datos del ERP."""
        resp = requests.post(
            f"{self.BASE_URL}/invoices",
            json=invoice_data,
            headers=self._headers(),
            timeout=15,
        )
        resp.raise_for_status()
        return resp.json()

    def sync_payments(self, since: str) -> list:
        """Obtiene pagos registrados en Siigo desde una fecha dada."""
        resp = requests.get(
            f"{self.BASE_URL}/documents",
            params={"document_type": "FV", "date_start": since},
            headers=self._headers(),
            timeout=15,
        )
        resp.raise_for_status()
        return resp.json().get("results", [])

El modelo Django que representa una factura en el ERP tiene un camposiigo_id que almacena el ID retornado por la API de Siigo. Esto garantiza idempotencia: si la sincronización falla y se reintenta, no se crean duplicados.

class Factura(models.Model):
    numero          = models.CharField(max_length=20, unique=True)
    cliente         = models.ForeignKey("Cliente", on_delete=models.PROTECT)
    fecha_emision   = models.DateField()
    total_neto      = models.DecimalField(max_digits=14, decimal_places=2)
    total_iva       = models.DecimalField(max_digits=14, decimal_places=2)
    estado          = models.CharField(
        max_length=20,
        choices=[("borrador","Borrador"), ("emitida","Emitida"), ("pagada","Pagada")],
        default="borrador",
    )
    # Integración Siigo
    siigo_id        = models.CharField(max_length=60, blank=True, null=True, unique=True)
    siigo_synced_at = models.DateTimeField(null=True, blank=True)
    siigo_error     = models.TextField(blank=True)

    class Meta:
        ordering = ["-fecha_emision"]
        indexes  = [models.Index(fields=["estado", "siigo_id"])]

4. RPA para PyMEs: automatizar lo que el ERP no puede

El ERP centraliza los datos, pero hay procesos operativos que suceden fuera de él: notificaciones a clientes por WhatsApp, envío de reportes PDF a supervisores, alertas cuando un contrato está próximo a vencer. Para esto implementamos flujos de RPA con Power Automatesobre la capa de datos del ERP.

La clave del éxito del RPA para PyMEs no está en la complejidad del bot — está en conectarlo a una fuente de datos limpia. Antes del ERP, automatizar estos flujos era imposible porque los datos estaban dispersos en hojas de cálculo sin estructura consistente. El ERP creó la base; el RPA la aprovecha.

5. La migración: cero downtime en una empresa en operación

El mayor riesgo de cualquier migración ERP no es técnico — es operativo. Ecolia no podía darse el lujo de parar operaciones ni un día. Nuestra estrategia fue un Big Bang controladocon rollback garantizado:

1. 1
   Semanas 1-6 — Migración histórica silenciosa: importamos 3 años de datos (clientes, contratos, inventario) al nuevo sistema mientras Ecolia seguía operando en Excel. Validaciones automáticas diarias comparaban totales.
2. 2
   Semana 7 — Modo paralelo (5 días): el equipo operaba simultáneamente en Excel y en el ERP. Cada transacción se registraba en ambos. Nos permitió detectar y corregir 23 inconsistencias.
3. 3
   Semana 8 — Cutover en fin de semana: el sábado a las 11pm cerramos el Excel definitivamente. El ERP quedó como sistema único. El lunes el equipo llegó a trabajar en la nueva plataforma.
4. 4
   Semanas 9-12 — Hypercare: un miembro de nuestro equipo estuvo disponible 8am-8pm para resolver dudas y ajustes. 147 tickets en 4 semanas; ninguno fue un bug crítico.

6. Resultados: 8 meses en producción

7. Lecciones aprendidas

Después de 18 meses en este proyecto, estos son los principios que aplicaría en cualquier implementación ERP para PyME:

• La calidad del dato es el proyecto. Podemos construir el mejor ERP del mundo, pero si los datos de partida están sucios, el ERP solo automatizará el caos. Dedicamos el 30% del presupuesto a limpieza y validación de datos históricos. Valió cada peso.
• No construyas lo que ya existe bien. Siigo resuelve la contabilidad y la facturación DIAN mejor que cualquier módulo que podamos construir. Django resuelve la lógica de negocio de Ecolia. La integración entre ambos fue la decisión correcta — no reemplazar uno con el otro.
• El RPA amplifica el ERP, no lo reemplaza. Power Automate conectado a la API del ERP automatizó en semanas procesos que habrían requerido meses de desarrollo custom. Para PyMEs, esta combinación es la relación costo/impacto más alta que encontramos.
• Azure App Service es suficiente para el 80% de las PyMEs. No necesitas microservicios ni Kubernetes para una empresa de 80-300 empleados. App Service con auto-scaling y SQL Server managed cubren las necesidades con un costo operativo predecible y sin necesitar un DevOps interno.