Negociación de un contrato ERP: un CFO de MENA ahorra 850 mil USD

Un contrato de implementación de ERP solo protege el presupuesto si lo protege su estructura: entregables concretos, recursos con nombre, hitos ligados a resultados aceptados, hypercare con tope y órdenes de cambio controladas. Este caso práctico muestra cómo el CFO de un fabricante mediano de MENA evitó 850.000 USD antes del arranque, al descomponer la declaración de trabajo (SOW) y reescribir el contrato antes de la firma, sin recortar el alcance. Es para CFO, directores financieros y responsables de compras que están a punto de firmar un contrato de implementación de ERP o de SAP. Aplique la lista de verificación previa a la firma, cerca del final, a su propia propuesta.

El CFO me entregó una propuesta de 120 páginas. Me dijo que parecía sólida, pero que algo no le cuadraba. Tenía razón.

Las cifras no eran el problema. Lo era la estructura. Términos generales como «configuración estándar» y «apoyo a las pruebas», sin explicar el trabajo que implicaban. El mismo trabajo apareciendo en secciones distintas con nombres distintos. Un lenguaje lo bastante vago como para justificar casi cualquier sobrecosto más adelante. Así se descarrilan los proyectos antes de empezar.

Yo veía lo que él había intuido sin poder concretar. Conocía el presupuesto y los objetivos. Su equipo era competente, pero nunca había revisado un SOW de entrega de esta escala, y el proveedor ya avanzaba hacia la firma.

Tres semanas de trabajo después, el contrato era fundamentalmente distinto y el proyecto pesaba 850.000 USD menos antes del arranque.

$850Kevitados antes del arranque

1. Racionalización del alcanceHoras infladas recortadas, formación y pruebas duplicadas eliminadas, ciclos de pruebas reducidos de cuatro a dos más una reserva$340K
2. Reasignación de roles y tarifasEquilibrio entre perfiles sénior y júnior bajo control, con personal interno en documentación y pruebas básicas$310K
3. Cambios contractualesPagos por entregable, topes de gastos, hypercare con tope, aprobación del CFO para las órdenes de cambio$200K

Un fabricante y distribuidor industrial de tamaño medio, con operaciones transfronterizas y una función financiera central: fabricación discreta, distribución de posventa, finanzas de servicios compartidos y compras del grupo. El grupo había crecido rápido en cinco años y ya había elegido SAP. Era el momento entre la selección del proveedor y la implementación, cuando están a punto de cerrarse los grandes compromisos.

Dividí el SOW en seis categorías: configuración, migración de datos, integraciones, pruebas, formación y PMO. Una vez dividido así, las lagunas se veían con facilidad.

1. Entregables vagos. «Integraciones estándar» sin nombres de sistemas, volúmenes de datos ni complejidad. Configuración descrita en horas, sin vínculo con los procesos de negocio. «Por confirmar en los talleres» repartido por todo el documento, cada uno de ellos una futura orden de cambio.
2. Pirámide de recursos. Consultores sénior nombrados en la propuesta, con tarifas diarias de sénior. Una vez firmado el contrato, los sénior suelen desaparecer y los júnior hacen el trabajo a la misma tarifa. Lo he visto en casi todos los programas. Sin una cláusula de recursos nominativos, no hay protección.
3. Facturación repetida. Formación en la UAT y otra vez en el hypercare. Comprobaciones de datos en las pruebas y otra vez en el cutover. Transferencia de conocimiento repartida entre los frentes funcional y de PMO y facturada dos veces. Solapamientos pequeños por separado, pero juntos son una causa seria de sobrecosto.
4. La ilusión del precio fijo. Presentado como precio fijo, pero «fijo» solo se sostiene si todos los supuestos están bloqueados. Esas frases mantienen estable la cifra principal y abren la puerta a facturar más tarde.
5. Hitos débiles. Pagos ligados a fechas del calendario, como «diseño completo en septiembre», sin definición de completo, sin criterios de aceptación y sin forma de retener una factura por un trabajo a medias.
6. Horas comodín. Líneas de reserva «para usar según haga falta», sin justificación. Se consumen rápido en tareas rutinarias y vuelven como solicitudes de cambio.

Dos detalles de alcance también llamaron la atención. La migración de datos estaba presupuestada íntegramente como trabajo del proveedor, aunque el cliente ya tenía herramientas internas. Y las pruebas estaban fijadas en cuatro ciclos completos, sin supuestos de defectos que los respaldaran.

El ahorro vino de tres áreas:

Área	Ahorro	Cómo
Racionalización del alcance	340.000 USD	Se recortaron las horas infladas de configuración; se eliminaron la formación y las pruebas duplicadas; se pasó de cuatro ciclos de pruebas a dos más una reserva
Reasignación de roles y tarifas	310.000 USD	Se controló el equilibrio entre sénior y júnior; el personal interno asumió la documentación y las pruebas básicas, con protección de recursos nominativos
Cambios contractuales	200.000 USD	Pagos ligados a entregables; topes a viajes y gastos con aprobación previa; hypercare acotado en el tiempo con salida basada en KPI; órdenes de cambio gobernadas con la aprobación del CFO

El esfuerzo de migración de datos del proveedor bajó aproximadamente un tercio al usar las herramientas y los estándares del propio cliente, y las horas de formación externa bajaron cerca de la mitad gracias a un modelo dirigido internamente. Nada de esto redujo el alcance ni la funcionalidad. El proyecto arrancó en la fecha prevista y no hubo órdenes de cambio en el primer trimestre. Normalmente, para entonces habrían llegado unas cuantas al escritorio del CFO.

Seis cláusulas marcaron la diferencia práctica:

1. Recursos nominativos. Cada consultor clave figura con nombre. Las sustituciones requieren la aprobación del cliente y un ajuste de tarifa. Sin esto, las personas de la propuesta no son las que trabajan en el proyecto.
2. Hitos basados en entregables. Cada hito se define por resultados: mapas de procesos firmados, datos conciliados, pruebas de aceptación completadas. El pago se libera cuando se cumplen los criterios, no cuando llega la fecha.
3. Gobernanza de las órdenes de cambio. Todo cambio de alcance requiere una declaración de impacto sobre alcance, plazos y costo. Las tarifas del trabajo nuevo tienen tope. La aprobación del CFO es obligatoria. Las órdenes de cambio pasan a ser excepciones controladas en lugar de un modelo de ingresos.
4. Tope de hypercare con criterios de salida. Acotado a seis semanas, con la salida definida por la estabilidad de las transacciones y el cumplimiento de los SLA, no por el criterio del proveedor. Las ampliaciones requieren una nueva aprobación.
5. Topes a viajes y gastos. Aprobación previa por encima de ciertos umbrales. De lo contrario, los viajes posteriores al go-live se convierten en una partida abierta.
6. Derechos de auditoría. El derecho a revisar los registros de facturación, aunque no se use nunca. Cambia el comportamiento, porque es menos probable inflar las cifras cuando se pueden comprobar.

Para la negociación en sentido amplio, mis notas sobre asesores de negociación de SAP y negociación de licencias de SAP cubren la parte de software del acuerdo.

Los equipos de finanzas suelen tratar la entrega de un ERP como un proyecto de TI y se echan atrás una vez aprobado el presupuesto. Eso es lo que deja que los sobrecostos crezcan.

El contrato es un instrumento financiero. Los hitos definen el flujo de caja. Las cláusulas de recursos definen el costo. El proceso de órdenes de cambio define la exposición. Si finanzas no revisa esto antes de firmar, no lo revisa nadie con experiencia comercial.

Hay tres carencias que aparecen una y otra vez:

1. El mito del precio fijo. Los CFO aprueban una cifra que parece tener tope, pero el alcance no es fijo si los supuestos quedaron vagos. Los talleres del proveedor son donde el alcance crece, y se cobra.
2. Ningún modelo de lo que cuesta el retraso. Un retraso suma más que las semanas extra de consultoría: suma tiempo interno y retrasa los beneficios. La mayoría de los presupuestos planifican el costo del proyecto y nunca modelan el costo de cada semana de desviación.
3. Una PMO interna sin habilidades comerciales. Hay planificación e informes; no hay capacidad de réplica comercial. Los directores de proyecto del proveedor saben cómo manejar las condiciones del contrato, y sin alguien igual de hábil por parte del cliente, este va cediendo terreno. Mi guía sobre por qué se desbordan los presupuestos de SAP muestra dónde suele convertirse esa exposición en costo.

Si el acuerdo incluye RISE with SAP, hay dos contratos que leer: la suscripción de SAP, con su propia descripción del servicio, y el SOW del socio de implementación. Aplique la misma disciplina a ambos y modele cómo crece la suscripción con el número de usuarios durante todo el plazo, no solo el primer año.

Aplique esto a cualquier propuesta de implementación de ERP antes de firmar:

1. ¿Está el SOW desglosado por frente de trabajo (configuración, datos, integraciones, pruebas, formación, PMO), con el esfuerzo de cada uno?
2. ¿Indica cada integración los sistemas, los volúmenes de datos y la complejidad?
3. ¿Se ha cerrado o excluido de forma explícita cada supuesto «por confirmar en los talleres»?
4. ¿Figuran con nombre los consultores clave, con aprobación de las sustituciones y ajuste de tarifa?
5. ¿Está cada hito de pago ligado a un entregable con criterios de aceptación y la conformidad del cliente?
6. ¿Existe un proceso de órdenes de cambio con declaraciones de impacto, tarifas con tope y aprobación del CFO?
7. ¿Está el hypercare acotado en el tiempo, con criterios de salida objetivos?
8. ¿Tienen tope los viajes y los gastos, y tiene usted derechos de auditoría sobre las horas facturadas?
9. ¿Se ha sacado del alcance del proveedor el trabajo que puede hacer su propio equipo (migración de datos con herramientas internas, documentación, pruebas básicas, formación)?

El CFO lo resumió después así: «Cuando revisé la propuesta por primera vez, pensé que las cifras parecían razonables. Lo que se me escapó fue lo vago que era realmente el alcance. Cuando lo desglosamos, me di cuenta de que la mayor parte del riesgo estaba en la letra pequeña. Tener una mirada financiera sobre el contrato me dio un control que no sabía que me faltaba. El ahorro importó, pero el mayor logro fue entrar en la implementación con claridad y sin sorpresas».

Compartió el resultado con su consejo de administración. El ahorro fue el titular. El resultado más importante fue un contrato, y un proyecto, que la empresa podía controlar desde el principio.

¿Qué es la pirámide de recursos en los contratos de ERP y cómo se evita?

Consiste en ofrecer en la propuesta consultores sénior y tarifas diarias de sénior, y después ejecutar con personal más júnior tras la firma. La tarifa de facturación sigue igual. La calidad, no.

La solución es una cláusula de recursos nominativos. Cada rol clave figura con nombre, las sustituciones requieren la aprobación del cliente y, si la tarifa del reemplazo es menor, la facturación se ajusta.

¿Cómo deben estructurarse los hitos de facturación de un ERP?

Ligue los hitos a entregables, no a fechas. «Diseño completo» no es un hito. «Mapas de procesos firmados y configuración revisada para finanzas y compras» sí lo es.

Dé a cada hito criterios de aceptación que el cliente firme antes del pago. Eso le da poder de negociación cuando la entrega está incompleta y evita facturas por trabajo parcial.

¿Cuál es la trampa del precio fijo en los contratos de implementación de ERP?

Un precio fijo solo es fijo si todos los supuestos se bloquean antes de firmar. Frases como «por confirmar en los talleres», «integraciones estándar» o «según el alcance actual» mantienen estable la cifra principal mientras crean más tarde oportunidades para órdenes de cambio.

Cierre los supuestos antes de firmar, enumere las exclusiones de forma explícita, ponga tope a las tarifas de las órdenes de cambio y ponga a prueba cada afirmación de precio fijo línea por línea.

¿Cómo debe definirse el hypercare en un contrato de ERP?

Un hypercare abierto se convierte en una fuente de ingresos para el proveedor. Póngale un tope de un periodo definido, normalmente de seis a ocho semanas, con criterios de salida objetivos como la estabilidad de las transacciones, el cumplimiento de los SLA y el volumen de tickets. Cualquier ampliación requiere aprobación formal.

Así el hypercare pasa a ser una red de seguridad acotada en el tiempo, con condiciones claras para el traspaso.

¿Qué debe revisar un CFO antes de firmar un contrato de implementación de ERP?

Como mínimo: cómo se definen los hitos, la protección frente a la sustitución de recursos, las reglas de las órdenes de cambio, el alcance y la salida del hypercare, los topes de viajes y gastos, y la lista de exclusiones.

Además de las cláusulas, haga descomponer el SOW frente por frente y contraste las estimaciones de esfuerzo con su capacidad interna. Donde su propio personal pueda asumir la documentación, las pruebas básicas o la formación, el contrato debe reflejarlo.

¿Por qué siguen apareciendo órdenes de cambio de ERP incluso en contratos de precio fijo?

Porque los contratos de precio fijo rara vez bloquean todos los supuestos. Las propuestas se redactan a alto nivel, las lagunas afloran en los talleres y cada laguna se convierte en una solicitud de cambio que, técnicamente, queda fuera del alcance.

El patrón es previsible: alcance vago, talleres que lo amplían, órdenes de cambio que monetizan la laguna. Exija un alcance concreto antes de firmar y requiera un análisis de impacto y la aprobación de un directivo sénior antes de que empiece cualquier trabajo nuevo.