La transformación es una función, no un proyecto

La mayoría de las organizaciones cambia sus sistemas de la misma manera. Alguien defiende la necesidad de un proyecto. Se aprueba un presupuesto, se forma un equipo, se elige un proveedor y se fija en el calendario una fecha de salida a producción. El equipo trabaja duro, el sistema entra en funcionamiento y el proyecto se cierra. Las personas que entendían el trabajo pasan a otras cosas.

Luego la organización sigue cambiando. Una nueva línea de productos necesita un nuevo paso de aprobación. Una regulación cambia lo que se debe registrar. Dos equipos se fusionan, pero sus hojas de cálculo no. Nada de esto espera al siguiente proyecto y, sin embargo, la capacidad de responder se fue con el anterior.

Este es el patrón detrás de buena parte de la frustración con la tecnología. El problema rara vez es que el último proyecto haya fracasado. Es que el modelo de proyecto trata el cambio como un evento, cuando para la mayoría de las organizaciones el cambio es una condición permanente.

Por qué el modelo de proyecto sigue decepcionando

El modelo de proyecto se pensó para trabajos con un comienzo y un final claros: construir un almacén, mudar una oficina, instalar una máquina. Esas cosas están terminadas cuando se terminan. El software que hace funcionar una operación nunca está terminado en ese sentido. Está en medio del trabajo, y el trabajo no se detiene.

Cuando un sistema se entrega como proyecto, suelen pasar tres cosas una vez que el proyecto se cierra.

• El conocimiento se dispersa. Las razones detrás del diseño, los casos especiales que descubrió el equipo, las concesiones que se hicieron: casi todo eso vivía en personas y reuniones. Cuando el equipo se disuelve, la organización conserva el sistema pero pierde la comprensión que tenía de él.
• Los cambios pequeños se acumulan. Cada solicitud es demasiado pequeña para justificar un nuevo proyecto, así que espera. Mientras tanto, la gente suple la carencia con una hoja de cálculo, un mensaje o una verificación manual.
• El sistema se aleja del trabajo. Mes a mes, la forma en que la organización opera de verdad se aparta de la forma en que el sistema espera que opere. El siguiente proyecto empieza entonces por redescubrir lo que el anterior ya sabía.

Nada de esto es culpa de nadie. Es lo que produce el modelo.

Cómo es una función

Las organizaciones ya saben gestionar un trabajo que nunca termina. Finanzas no cierra las cuentas una vez y se disuelve. El área legal no deja de revisar contratos después del primero. Son funciones: responsabilidades permanentes, a cargo de personas que se quedan, con memoria de lo anterior y una capacidad estable para atender lo que viene.

La transformación puede funcionar igual. Tratarla como una función significa algunas cosas concretas.

• Alguien es responsable de forma continua. Hay un responsable con nombre propio que responde por cómo evolucionan los sistemas de la organización, no solo por la próxima iniciativa.
• La capacidad es estable. En lugar de formar un equipo para cada proyecto y disolverlo después, hay una capacidad continua que pasa de una necesidad a la siguiente a medida que cambian las prioridades.
• La memoria se conserva. Las decisiones, el contexto y las restricciones quedan registrados donde la siguiente persona pueda encontrarlos. Nadie tiene que reconstruir por qué el flujo de aprobación funciona como funciona.
• El cambio es continuo. El ciclo de entender una necesidad, dar forma a una respuesta, construirla, verificarla, desplegarla y hacerla evolucionar se repite una y otra vez, al ritmo que la organización necesita.

Tres cambios en la práctica

Pasar de proyectos a una función tiene menos que ver con organigramas que con hábitos. Según nuestra experiencia, el cambio se nota en tres lugares.

De los entregables a la capacidad

Un proyecto se describe por lo que va a entregar. Una función se describe por lo que puede asumir. La pregunta pasa de «cuánto costará construir esto» a «en qué debería trabajar ahora nuestra capacidad». Eso permite resolver las cosas pequeñas que nunca justificaron un proyecto, y cambiar de rumbo sin empezar un nuevo proceso de compra.

Del traspaso a la continuidad

En el modelo de proyecto, el momento más peligroso es el traspaso: de quienes diseñaron el sistema a quienes lo operan, o de un proveedor al siguiente. Una función elimina la mayoría de los traspasos, porque el mismo equipo lleva el trabajo desde la primera conversación hasta la operación, y de vuelta. Lo que no puede eliminar, lo registra.

De las grandes entregas a la evolución constante

Cuando el cambio es costoso de iniciar, las organizaciones lo acumulan y lo entregan en grandes lotes. Los grandes lotes son más difíciles de probar, más difíciles de explicar y más difíciles de revertir. Una función permanente puede hacer cambios en pasos más pequeños, cada uno comprendido, verificado y explicado a las personas a las que afecta.

Lo que les pide a los líderes

Una función no se gestiona sola. Pide a los líderes que decidan algunas cosas de forma deliberada.

Primero, quién es responsable de la evolución de los sistemas de la organización y cómo se apoya a esa persona. Segundo, cómo se define y se revisa la capacidad continua, para que siga siendo proporcional a la ambición. Tercero, cómo se eligen las prioridades, porque a una capacidad que puede asumir cualquier cosa se le pedirá que lo asuma todo.

También pide un tipo particular de paciencia. Los beneficios de una función son acumulativos. Vienen del conocimiento que se queda, de los problemas que se resuelven mientras todavía son pequeños y de sistemas que siguen coincidiendo con el trabajo. Se ven más fácilmente en un año que en un trimestre.

Dónde encaja Croo

Construimos Croo en torno a esta idea. Tu Croo es un equipo que se queda junto a la organización: una persona en la sala que conoce tu operación y, detrás de ella, las disciplinas que el trabajo requiere, desde los procesos de negocio y la arquitectura hasta la ingeniería de software, las finanzas y la gobernanza. La Factory le da a ese equipo una memoria compartida y un sistema de producción, para que cada cambio se apoye en el anterior en lugar de empezar de cero.

La relación funciona con una capacidad continua y no con una sucesión de proyectos. No es una licencia de software ni un encargo puntual. Es una forma de que la transformación sea algo que la organización lleva de forma continua, sin tener que construir un departamento completo propio.

Los proyectos seguirán teniendo su lugar. Algunos cambios son lo bastante grandes como para merecer un nombre, un plan y una fecha. Pero cuando el proyecto termina, la función no debería terminar. La organización seguirá cambiando. Su capacidad de cambiar debería quedarse.