Migración de CRM en medio de un trimestre de alta demanda: el error de timing
La decisión de migrar de la plataforma de CRM anterior a Dynamics 365 en el segundo mes del trimestre de mayor demanda del año fue tomada sin que nadie nombrara explícitamente el riesgo. El directorio quería el nuevo sistema operativo antes del cierre del año fiscal. El equipo de implementación había confirmado que la migración era técnicamente posible en las semanas propuestas. El equipo de ventas estaba en el período más intenso del año con el pipeline más alto. Nadie juntó esas 3 piezas de información en la misma conversación antes de aprobar el calendario.
Las primeras 2 semanas de la migración fueron de caos productivo. El equipo de ventas operaba simultáneamente en el sistema antiguo, que seguía siendo la fuente de verdad oficial durante el período de transición, y en el sistema nuevo, que debían aprender mientras gestionaban el pipeline más activo del año. Los registros estaban en proceso de migración con discrepancias que el equipo tenía que verificar manualmente. Las integraciones con las plataformas de marketing no estaban todas activas en el nuevo sistema. Los reportes que el directorio pedía en las reuniones semanales no podían ser generados desde el nuevo sistema con la misma lógica que el antiguo.
El impacto en el pipeline fue medible y evitable. En las 3 semanas más intensas de la migración, la tasa de seguimiento de oportunidades activas cayó un 23%. No porque el equipo no quisiera hacer el seguimiento sino porque el tiempo que normalmente dedicaban a gestionar el pipeline lo estaban dedicando a aprender el nuevo sistema, a verificar discrepancias de datos y a responder preguntas sobre cómo hacer en el nuevo sistema lo que hacían de forma automática en el antiguo. Al cierre del trimestre, el revenue fue un 14% menor al objetivo. El equipo de ventas había tenido el pipeline correcto. La migración había consumido el tiempo y la atención necesarios para convertirlo en revenue.
El análisis post-mortem identificó 3 errores de timing que se podían haber evitado. Primero, la migración debería haberse completado o pospuesto antes del inicio del trimestre de alta demanda, nunca durante él. Segundo, el período de transición con operación dual en dos sistemas debería haber sido de máximo 1 semana, no de 3, con recursos dedicados de soporte durante ese período. Tercero, el entrenamiento en el nuevo sistema debería haberse completado antes del inicio de la migración, no simultáneamente con ella.
La política que establecí después de esa experiencia fue sobre el timing de cambios tecnológicos que afectan la operación del equipo de ventas: ningún cambio significativo de sistema o de proceso ocurre en los períodos de mayor carga operativa, independientemente de las presiones de calendario del proyecto de implementación. El costo de posponer la implementación 8 semanas para hacerla en un período de menor demanda hubiera sido menor al costo del 14% de revenue perdido en el trimestre más importante del año. El timing de los cambios no es un detalle de planificación. Es una variable de negocio con consecuencias en el revenue.