Transformación e implementación

Los programas de transformación suelen fracasar en el traspaso. Un equipo de diseño redacta el estado objetivo y se va, las iniciativas caen en una cola de trabajo de TI que ya estaba llena, y la oficina del programa reporta los hitos en verde mientras el paquete de informes muestra que nada se ha movido. Cuando alguien compara el caso de beneficios con el libro contable, el dinero ya se ha gastado y los beneficios se han contado dos veces, una por cada iniciativa que tocó la misma línea de costo.

Dirigimos la transformación desde los registros hacia fuera. Cada beneficio se vincula a una cuenta contable o a un registro operativo antes de que empiece el programa, con una línea base leída de esa fuente y una regla sobre cómo se contará. Las iniciativas se redactan como tareas con criterios de aceptación que pueden comprobarse en los sistemas en producción, de modo que una tarea se cierra cuando el sistema de pedidos, el registro del almacén o las cuentas de gestión muestran el cambio, y no cuando alguien la da por hecha.

El equipo que diseña el programa también construye los sistemas de los que depende: la integración, la automatización, los informes, la tienda o la herramienta interna. Cuando el trabajo requiere una profundidad que no tenemos, como un ERP concreto o un despliegue en un idioma local, incorporamos un socio elegido para ese proyecto y seguimos siendo responsables del resultado. También construimos y operamos nuestros propios productos, lo que mantiene nuestras estimaciones realistas sobre lo que el software requiere de verdad.