“No podemos migrar a otra plataforma ni hacer aplicaciones propias. Ya llevamos tres años y más de $50 millones invertidos en esta implementación del ERP”.
Si te has sentado en una mesa de directorio o comités de gerencia tecnológica, garantizo que has escuchado alguna variación de esa frase. Quien la pronuncia generalmente cree estar protegiendo el patrimonio de la compañía frente a un riesgo innecesario. Sin embargo, en la mayoría de los casos, está cometiendo uno de los errores más elementales de la gestión corporativa: operar bajo la falacia del costo hundido (Sunk Cost Fallacy).
El dinero que le pagaste a tu proveedor de licencias y consultoría los años pasados ya salió del flujo de caja. En la toma de decisiones financieras racionales, las inversiones se justifican únicamente por sus flujos de caja incrementales futuros.
Si mantener tu engorroso sistema ERP hoy frena a tus vendedores, retrasa a tu logística y fuerza a tu equipo administrativo a llevar planillas Excel por fuera para “hacer el trabajo real”, no estás siendo conservador. Estás aceptando un EBITDA drag (pérdida recurrente) por miedo a asumir un error histórico.
Pero al momento de salir de esa trampa, se abre la gran discusión estructural. El eterno dilema de TI: ¿Compramos otro software enlatado (Buy) o lo desarrollamos nosotros mismos (Build)?
Cómo construir tu propio ERP: Comienza por el dolor, no por la contabilidad
En la década pasada, la advertencia gerencial era dogmática: “No reinventes la rueda. Compra un ERP genérico”. Quienes intentaban desafiar esta regla solían fracasar, pero casi siempre porque cometían el mismo error táctico de manual: intentaban construir el ERP empezando por el Módulo Contabilidad.
Punto de quiebre: La magia financiera diferencial de tu empresa no está en cómo calculas una partida doble o cómo pagas el IVA. Está en cómo operas el negocio en la calle.
El enfoque ganador para desarrollar tu propio sistema no es un reemplazo de “Big Bang” contable. Es construir orgánicamente apoderándote de tu columna vertebral operativa. Se empieza capturando y resolviendo los mayores dolores que la rigidez del software enlatado es incapaz de modelar con agilidad:
- El flujo duro de Compras y Órdenes de Compra (OC).
- La gestión compleja de Pedidos, Subcontratos y sus respectivos Estados de Pago.
- La centralización de Facturas, Pagos y Rendiciones de personal.
- El avance físico de tus operaciones y la gestión en tiempo real de las Bodegas.
Toda esa operación es tu verdadera ventaja competitiva. Una vez que digitalizas y dominas este flujo de valor operativo en una infraestructura moderna (usando stacks como React y bases de datos ágiles sin fricción), tú controlas la “sangre” de la empresa.
Con esa madurez técnica y operativa ya capturada, la pregunta de la contabilidad se puede hacer con calma. Y mi respuesta, para la gran mayoría de las empresas, es no absorberla: la contabilidad, las remuneraciones y la facturación electrónica son justamente el territorio donde tu empresa no se diferencia, y donde un error tiene costo tributario y legal. En Chile, además, cada cambio normativo del SII o de la Dirección del Trabajo lo absorbe el proveedor certificado por ti. Lo que construyes son satélites operativos que se integran por API con ese núcleo contable comprado.
No construyes un ERP tratando de replicar a SAP el Día 1. Construyes, módulo por módulo, la parte operativa que el software viejo no sabía modelar, hasta que tu empresa corre más rápido que tu competencia gracias a su tecnología propia, sobre un núcleo contable que no tuviste que reinventar.
La Matemática Financiera: El verdadero Costo Total de Propiedad (TCO)
El modelo de Venta de Software como Servicio (SaaS) le vendió a los CFOs el sueño del Gasto Operativo (OPEX): “Te evitas el CAPEX millonario de invertir, págame $50 dólares por usuario al mes”.
Esto suena bien hasta que tu empresa escala o requiere personalización, y chocas con la dura matemática corporativa. Revisemos cómo estructurar un modelo de cálculo comparativo real.
El análisis del Caso de Negocio (Ejemplo a 5 años)
Supongamos que tu empresa comercial necesita digitalizar a 300 operarios de terreno. El proveedor de ERP corporativo te ofrece el “Módulo Adicional Field Service”.
Opción A: Modelo Buy (SaaS Adicional)
- Licenciamiento: $40 USD/mes por operario × 300 usuarios × 12 meses = $144,000 USD al año.
- Consultoría e Integración: Implementar sus flujos requiere 1,000 horas de su consultoría certificada a $120 USD/hora = $120,000 USD (año 1).
- Costos ocultos (Vendor Lock-in): Para adaptar tu proceso a los reportes que ellos te obligan, incurres en 30 horas semanales de trabajo administrativo improductivo ($30,000 USD/año en nómina muerta).
Opción B: Modelo Build (Satélite Propio en Stack Moderno) Aquí somos brutalmente honestos. Desarrollar in-house implica un gasto enorme inicial. Tienes que pagar a desarrolladores altamente calificados. No es barato.
- CAPEX Intelectual (Equipo Dev): Squad técnico (Líder Arquitectura, 2 FullStack, UX) durante 5 meses = $150,000 USD (año 1).
- OPEX de Infraestructura (Serverless): Al usar arquitecturas transaccionales bajo demanda como Supabase, el costo de bases de datos para 300 usuarios concurrentes es marginal. Literalmente menos de $2,000 USD anuales.
- Mantenimiento (Soporte interno): Una fracción del tiempo de tu equipo dev o retención. Promedio de $30,000 USD/año.
- La Ventaja Oculta (Aceleración): Tu aplicación satélite hace exactamente lo que necesitan los operarios. Si esa menor fricción aumenta las visitas efectivas diarias, es beneficio adicional; en las cuentas de abajo no lo sumo, porque es el tipo de beneficio que todo caso de negocio promete y pocos miden.
La cuenta, con un escenario honesto
Sumando los números de arriba a cinco años, la comparación da:
| Escenario | Año 1 | Acumulado a 5 años | Valor presente al 10% |
|---|---|---|---|
| Buy (SaaS + consultoría + fricción) | US$294 mil | US$990 mil | US$769 mil |
| Build, estimación base | US$152 mil | US$280 mil | US$230 mil |
| Build, pesimista (desarrollo y mantención al doble) | US$302 mil | US$550 mil | US$453 mil |
Fíjate en la segunda fila, porque es la que debería despertar sospecha: con la estimación base, Build gana desde el primer año. Cuando un caso de negocio sale tan limpio, lo más probable es que la estimación sea optimista, y los desarrollos de software son el ejemplo de manual de estimación optimista: cinco meses que terminan siendo nueve, una mantención que crece con cada pedido nuevo. Por eso la fila que importa es la tercera. Con el desarrollo y la mantención al doble, Build se paga a comienzos del segundo año (el cruce cae en el mes 13) y a cinco años sigue ahorrando más de US$400 mil, también descontando los flujos.
Costo Total de Propiedad (TCO Acumulado) a 5 Años
Buy contra Build, con un escenario pesimista para Build. En dólares acumulados.
Esa es la conclusión robusta: no que Build sea barato, sino que sigue ganando aunque te equivoques al estimarlo. El modelo Buy esconde su impuesto en el tiempo: a medida que sumas usuarios, tu factura sube linealmente (y la licencia estándar suele subir de precio cada año). El modelo Build concentra el costo al principio y después se aplana: sumar 200 operadores más te costará $0 adicionales en licencias, aunque sí algo más de infraestructura y soporte.
Y la advertencia de siempre: estos números son de un ejemplo. Rehaz la tabla con tus cotizaciones reales, y si tu propio escenario pesimista no gana, la respuesta es comprar.
El efecto en tu Activo Corporativo (M&A)
Existe un último multiplicador que los gerentes financieros puros omiten al cruzar la calculadora. Es el carácter del activo.
Cuando pagas $1 millón de dólares a Microsoft, SAP o un tercero en licencias a lo largo de 5 años, tu empresa registra $1 millón en gastos operacionales. Cero activos. Cuando inviertes $1 millón desarrollando tu propio sistema satélite, parte de ese desembolso puede registrarse como un activo intangible. Has creado un software que te pertenece.
Con dos matices que tu contador te va a recordar, y con razón. Bajo IFRS, que es la norma que usan las empresas chilenas, no todo el desarrollo se puede activar: solo la fase que cumple condiciones estrictas (factibilidad técnica demostrada, intención y capacidad de usarlo, beneficios futuros probables), y el activo se amortiza, así que igual termina pasando por resultados, solo que repartido en el tiempo. Y en una fusión o adquisición, nadie paga más por el software en sí: paga más si ese software explica una operación mejor que la de la competencia, algo que cualquiera puede arrendar por la misma cuota mensual no puede explicar.
Conclusión: Una decisión de madurez técnica
El mandato de “hacer aplicaciones de negocio a la medida” no es un cheque en blanco. Exige directores ejecutivos y líderes tecnológicos preparados. Necesitas Business Engineers y arquitectos técnicos que sepan qué tocar, cómo integrarse por API de forma segura al viejo ERP monolítico base, y cómo garantizar la ciberseguridad.
Cualquiera puede comprar el ERP completo. Es la opción cómoda y segura (si algo falla, llamas al proveedor), y para el núcleo contable es además la correcta. Solo las gerencias más maduras asumen su deuda técnica, aíslan la “vieja guardia” de la contabilidad en el rincón y se lanzan a escribir el código de las trincheras logísticas, operativas y comerciales que dictarán si sobreviven la próxima década comercial.
La pregunta que define al liderazgo corporativo hoy no es si “compilamos o compramos”. Es: ¿Estás dispuesto a aceptar que tu agilidad operativa como organización nunca podrá ser más rápida de lo que los programadores de tu proveedor de ERP decidan permitírtelo en su próxima actualización?