Saltar al contenido
← Blog

Caso de éxito · ERP · Septiembre 2026 · 8 min

De un año estancado a cuatro semanas: cómo destrabamos el BBP de un ERP financiero

Un caso real y anonimizado sobre cómo la preparación al cambio permitió cerrar en cuatro semanas un Business Blueprint que llevaba doce meses detenido.

De un año estancado a cuatro semanas: cómo destrabamos el BBP de un ERP financiero

Una empresa de retail, con cerca de 100 stakeholders impactados por la implementación de su ERP financiero, llevaba doce meses sin cerrar el Business Blueprint (BBP). El implementador tenía el cronograma, el presupuesto estaba aprobado y el diagnóstico técnico estaba resuelto. Aun así, el proyecto no avanzaba.

El BBP es el plano sobre el que el equipo financiero valida cómo operará dentro del sistema nuevo: tesorería, cuentas por pagar, conciliaciones y cierre contable. Todo lo que el sistema haga después se configura sobre ese plano. Si no cierra, no hay parametrización que lo arregle.

El sistema no era el punto de quiebre

Antes de tocar cualquier proceso, hicimos una pregunta distinta: ¿está la organización preparada para sostener este cambio, o solo está lista la tecnología? Aplicamos el modelo de ShiftLab, que observa simultáneamente Proceso, Personas y Tecnología para identificar dónde se concentra la fricción.

La tecnología no era el problema. Tampoco había una resistencia activa al ERP. El quiebre estaba en Proceso, en un punto que parecía administrativo, pero no lo era: la firma que validaba la nueva forma de operar.

No todos los actores clave estaban en la mesa y no existía una metodología común para llegar a cada firma. Las validaciones se armaban con participantes y criterios distintos. Un año de estancamiento no era un problema de voluntad, sino de diseño: nadie había definido quién decidía, quién validaba y en qué orden.

Cómo destrabamos el BBP

Nos sentamos codo a codo con el implementador. Un BBP no se acelera con un informe de recomendaciones, sino trabajando dentro del mismo proceso que está atascado.

  • Identificamos a las personas específicas con el conocimiento operativo necesario para validar cada proceso.
  • Construimos con el implementador una metodología única: qué se revisa, quién lo revisa, en qué orden y con qué criterio se da por validado.
  • Instalamos un comité estratégico para resolver prioridades, alcance y excepciones.
  • Creamos un comité táctico para coordinar semanalmente al equipo financiero y al implementador.
  • Formamos un equipo de embajadores dentro del área financiera para sostener el nuevo proceso en el trabajo diario.

La agilidad no fue correr más rápido. Fue tener claro quién decidía qué y en qué momento.

El resultado y el aprendizaje

Con la gobernanza en marcha y la metodología unificada, el BBP que llevaba doce meses sin cerrarse quedó cerrado en cuatro semanas. Mismo equipo, mismo implementador y misma información disponible. Lo que cambió fue haber medido dónde estaba realmente el quiebre antes de intervenir.

Este caso no trata de un sistema ni de una industria en particular. Muestra por qué un cronograma, un presupuesto y una arquitectura técnica en orden no bastan para que una implementación avance. La preparación al cambio exige identificar con precisión en qué dimensión y en qué momento se puede atascar el proyecto.

Si un BBP —o cualquier hito equivalente— lleva más tiempo del que debería sin cerrarse, el paso práctico no es apurar al equipo ni atribuir el problema a su actitud. Es preguntar si el quiebre está en el proceso, en las personas o en la tecnología.

¿Tu ERP financiero está en fase de BBP o enfrenta un hito que no avanza? Conversemos sobre dónde está realmente el punto de quiebre.

Caso real de ShiftLab, presentado de forma anonimizada para resguardar a la organización y sus equipos.