PMO independiente en implementaciones ERP: por qué el diseño falla recién en el go-live

En casi todos los proyectos ERP y core en los que hemos entrado como PMO independiente, el problema no es la tecnología: es que el diseño funcional se validó contra escenarios ideales y no contra el ciclo de vida real del producto o servicio. La demo del proveedor luce impecable; el primer cierre contable —no—. La experiencia de proyectos complejos y distintos estudios de la industria muestran que las implementaciones pueden desviarse en plazo, presupuesto y beneficios cuando el gobierno del proyecto y los controles de corte son débiles.

Los patrones se repiten. 1) Productos configurados sin considerar modificaciones intermedias del ciclo de vida —renegociación, prórroga, castigo parcial, cesión, condonación de intereses—. 2) Parametrización contable definida por el integrador sin validación cruzada del área contable ni del auditor externo, con impactos sobre IFRS 9, IFRS 15 e IFRS 16. 3) Interfaces con sistemas satélites probadas solo en el camino feliz, sin escenarios de reproceso, caída ni reversa. 4) Segregación de funciones diluida en la urgencia del go-live, contradiciendo la matriz SoD del propio proyecto. 5) Migración de datos sin plan de reversa documentado ni certificación paralela contra el sistema legado.

El rol del PMO externo no es reemplazar al integrador ni al proveedor: es asegurar que el directorio y el Comité de Auditoría reciban una lectura independiente de riesgos, y que la decisión de go-live o no-go-live se tome con evidencia y no con optimismo. La matriz de escenarios producto ↔ contabilidad, los casos de prueba trazables con evidencia archivable, la certificación paralela por al menos un ciclo completo de cierre y los criterios objetivos de corte —criterios previamente aprobados por el sponsor y el Comité— son el mínimo razonable para un proyecto de esta magnitud.

El costo de descubrir un error de diseño después del go-live —horas de reproceso, ajustes manuales, notas al pie en los estados financieros, observaciones del auditor y riesgo reputacional— puede ser significativamente superior al costo de una segunda opinión anticipada e independiente del integrador.

---

**Fuentes y referencias**

- IFRS 9 — Instrumentos financieros; IFRS 15 — Ingresos de contratos con clientes; IFRS 16 — Arrendamientos. - COBIT 2019 (ISACA) — gobierno y gestión de TI empresarial. - ISACA, marcos de segregación de funciones (SoD) y controles generales de TI. - Standish Group, CHAOS Report — tasas históricas de fracaso en proyectos TI de gran escala. - Panorama Consulting, ERP Report — estudios anuales sobre desviaciones de plazo, presupuesto y beneficios en implementaciones ERP. - IAASB, NIA 315 (revisada 2019) — riesgos derivados del entorno de TI de la entidad.