Con un plan de rollouts para llevar SAP de tres a trece países, cada semana de retraso del equipo de desarrollo equivalía a un mes de retraso del proyecto. La compañía cambió el modelo. Más de una década después, sigue.
Este caso se publica en perfil ciego, sin el nombre del cliente. Cada cifra indica su origen: referida por el cliente, dato de WSP International o estimación.
1. La situación
Un fabricante industrial multinacional, proveedor de la industria automotriz global. Al arrancar tenía SAP en unas cuantas plantas de Norteamérica y un plan de rollouts a más de una decena de países, varios ya en marcha. Todo sobre una sola instancia central.
El problema era de capacidad. La expansión internacional y la operación diaria competían por el mismo equipo de cinco programadores, y cada país nuevo exigía su propia localización fiscal y legal, desarrollada por quienes ya sostenían las plantas existentes.
Lo crítico se atendía primero y el resto de la cola se detenía. El filtrado y la priorización recaían en el propio Gerente de SAP. Y cada salida de un programador obligaba a reconstruir el conocimiento de los programas críticos, con los rollouts corriendo.
2. Lo que estaba en juego
Una semana de retraso en un desarrollo de localización podía mover el arranque productivo al siguiente periodo fiscal. Un mes de proyecto, con un equipo funcional externo de al menos seis consultores senior esperando mientras el arranque se posponía, en un programa que duró al menos tres años y medio.
Cada mes de retraso equivalía a unos seis meses-persona de consultoría senior. Esa última cifra es una estimación de WSP International con base en el tamaño del equipo funcional que el cliente refirió.
3. Qué decidieron
La compañía tenía dos caminos: ampliar su base instalada de desarrolladores o cambiar el modelo. Eligió el segundo. El diagnóstico fue que sumar manos a un sistema sin flujo formal ni documentación completa reproducía el problema con otras caras.
El servicio se construyó sobre cuatro decisiones:
- Una transición gradual, por olas. Primero los desarrollos nuevos de los rollouts y los ajustes de versión. Después, con transferencia de conocimiento, los programas críticos existentes. El usuario no vivió un corte.
- Un responsable, no un grupo de personas. Un líder técnico dedicado como contacto único, con el contexto completo del entorno y el estatus de cualquier desarrollo en cualquier momento.
- La capa de gestión incluida. Flujo de atención con seguimiento semanal del añejamiento de tickets, especificaciones completas antes de codificar, estimación desglosada y un estándar único de programación.
- Un equipo extendido. Un equipo base estable que se amplía temporalmente en los picos, con horas mensuales disponibles en lugar de aprobar cada requerimiento por separado.
4. Qué cambió
La cadencia de rollouts pasó de uno cada cinco meses a uno cada tres en varios países. En los rollouts en paralelo la demanda se duplicaba, de unos 20 a unos 40 requerimientos, y el equipo se amplió temporalmente sin que bajara la calidad, volviendo a su nivel base al pasar el pico.
Analizar un cambio en un programa crítico pasó de unas 24 horas a dos o tres. Un proceso batch crítico pasó de dos días a cinco horas.
Años después apareció un beneficio que nadie había pedido. Al convertirse en emisora pública, la compañía quedó sujeta a revisiones externas de sistemas, y como proveedora de clientes globales recibe por traslado esas mismas exigencias. La documentación funcional y técnica que el servicio había dejado acumulada permitió superarlas con todo en orden.
5. La prueba de continuidad
Cuando el primer líder técnico dejó la cuenta, lo relevó una desarrolladora del mismo equipo que ya conocía la forma de trabajar del cliente y sus desarrollos más importantes. No hubo curva de aprendizaje porque el conocimiento no estaba en una persona.
El servicio opera sin interrupción desde hace más de una década, y el 80% del equipo que arrancó sigue en la cuenta.
Lo que el cliente recomienda a quien está donde él estaba: dedicar el tiempo necesario a la transferencia de conocimiento y promover el cambio dentro de la organización, porque el beneficio no se ve de inmediato.
Sobre WSP International
WSP International es una firma tecnológica mexicano-americana con más de 25 años de operación en un solo mercado: el ecosistema SAP. Su equipo de Ingeniería tiene 9.5 años de antigüedad promedio. Opera con registro REPSE vigente y bajo el estándar de exigencia que imponen los clientes más demandantes del ecosistema.
Nota: WSP International no tiene relación alguna con WSP Global Inc., firma canadiense de ingeniería e infraestructura.