¿Por qué necesitamos 20 equipos?: la pregunta anterior al organigrama

Un caso recurrente en consultoría organizacional se presenta más o menos así: una aseguradora decidió construir su propio sistema de gestión de clientes. El proyecto está aprobado, el presupuesto asignado, y ahora la pregunta es cómo organizar los veinte equipos que van a trabajar en él. ¿Qué modelo de escalado usamos? ¿Cómo coordinamos las dependencias? ¿Qué ceremonias de sincronización necesitamos?

Son preguntas legítimas. Y son la segunda pregunta.

La primera es incómoda y casi nunca se hace en voz alta: ¿por qué necesitamos veinte equipos y por qué debemos construir un sistema de gestión de clientes?

El costo de saltarse la pregunta

Organizar bien un trabajo que no debería hacerse es la forma más cara de eficiencia. Un programa de veinte equipos consume durante años la capacidad de construcción de la organización entera. Si una parte significativa de lo que va a construir es funcionalidad genérica disponible en el mercado, esa capacidad se está gastando en replicar lo que ya existe.

Y el costo no es solo el desarrollo. Es el mantenimiento perpetuo de todo lo construido, la deuda que acumula, la gente que hay que retener para operarlo y la capacidad que no estuvo disponible para lo que sí diferenciaba a la organización.

Por eso el orden de las preguntas importa tanto. Diseñar la topología de equipos antes de decidir el alcance real institucionaliza el alcance no examinado: veinte equipos con trabajo asignado son veinte equipos que van a producir, y lo que producen se vuelve muy difícil de cuestionar seis meses después.

Mapear antes de organizar

Hay un ejercicio previo que rinde más que cualquier decisión de estructura: mapear los componentes del sistema propuesto según su grado de evolución.

Un mapa de Wardley hace esto de forma explícita. Ubica cada componente en un eje que va de lo génesis —novedoso, incierto, único— a lo commodity —estandarizado, disponible, indiferenciado—, encadenado a las necesidades del usuario que sirve.

El resultado, aplicado a un sistema de gestión de clientes en una aseguradora, suele ser revelador. La gestión de contactos es commodity. La agenda de actividades es commodity. La gestión de campañas es producto de mercado maduro. La autenticación es commodity absoluta.

Y después están los componentes donde efectivamente reside la diferenciación: la suscripción de riesgos con criterios propios, el manejo de siniestros con las particularidades del mercado local, la relación con la red de intermediarios, la detección de fraude, el modelo de tarificación, la integración con los sistemas centrales.

Ninguna de esas dos listas justifica la misma decisión. La primera se compra. La segunda, o parte de ella, se construye.

Separar capacidades genéricas de capacidades diferenciadoras

Este es el trabajo analítico que precede a cualquier decisión de estructura, y se puede hacer en semanas con las personas correctas en la sala.

Para cada capacidad del sistema propuesto, tres preguntas:

1. ¿Un competidor podría comprar esta capacidad en el mercado y quedar en igualdad de condiciones con nosotros?
2. Si la respuesta es sí, ¿hay alguna razón específica por la que nosotros no podamos comprarla?
3. Si la respuesta a la primera es no, ¿qué la hace distinta y podemos articularlo en una frase?

La tercera pregunta es la más útil. Si nadie puede articular en una frase por qué una capacidad es diferenciadora para esta organización, probablemente no lo es. La respuesta “nuestros procesos son distintos” casi nunca sobrevive al escrutinio: los procesos distintos suelen ser accidentes históricos, no ventajas.

Los journeys y los resultados, no los módulos

Hay una segunda entrada al problema que complementa el mapa: partir de los recorridos del cliente y de los resultados esperados, en vez de partir de módulos funcionales.

Un sistema pensado en módulos produce una lista de funcionalidades que hay que construir, y esa lista se reparte entre equipos. Un sistema pensado en recorridos produce una pregunta distinta: qué tiene que poder hacer un cliente, un intermediario o un analista, de punta a punta, y qué se interpone hoy.

La diferencia práctica es que la segunda entrada permite encontrar una rebanada vertical de valor: un recorrido completo, de principio a fin, que se puede construir y poner en producción con dos o tres equipos. No un módulo aislado que no sirve para nada hasta que estén los otros once.

La secuencia que sí funciona

De todo lo anterior se desprende una secuencia bastante distinta de la que empezó este artículo:

1. Mapear qué componentes son commodity, cuáles se compran y dónde reside realmente la diferenciación.
2. Identificar los recorridos y resultados de cliente que importan.
3. Separar capacidades genéricas de potencialmente diferenciadoras: suscripción, siniestros, intermediación, fraude, tarificación, servicio, integración y datos.
4. Empezar con una rebanada vertical de valor operada por dos o tres equipos.
5. Liberar más capacidad solo cuando se validen la arquitectura, el flujo y la demanda real.

El paso cinco es el que reencuadra la pregunta original. Puede que la organización efectivamente necesite veinte equipos. Pero eso se descubre, no se decide de antemano. Y se descubre cuando los primeros tres equipos demuestran que la arquitectura sostiene el trabajo en paralelo, que el flujo de entrega funciona y que hay demanda real por lo que se está construyendo.

Escalar antes de esas tres validaciones no acelera nada. Multiplica por siete un problema de coordinación sobre una arquitectura no probada.

Por qué las organizaciones deciden construir

Conviene entender por qué la decisión de construir gana tan seguido, porque los motivos rara vez son los que se declaran, y sin entenderlos el análisis no cambia nada.

Los procesos son distintos. Es el argumento más frecuente y el más débil. Casi siempre los procesos son distintos por razones históricas, no por ventaja competitiva. Y hay una asimetría de costo que no se contabiliza: adaptar el proceso a un producto de mercado se paga una vez; construir un sistema a la medida del proceso se paga todos los meses, para siempre.

Ningún proveedor cubre el cien por ciento. Cierto casi siempre, e irrelevante como criterio. La pregunta correcta no es si cubre todo, sino qué proporción cubre y cuánto cuesta el resto. Un producto que cubre la mayor parte más una integración específica suele salir mucho más barato que construir el conjunto completo.

Preocupa la dependencia del proveedor. Es un riesgo real y merece análisis serio: portabilidad de datos, costo de salida, condiciones contractuales. Lo que no suele hacerse es comparar ese riesgo con el de la alternativa, que también existe: dependencia de un equipo interno, de las personas que entienden el sistema, y de la capacidad de la organización para mantenerlo durante una década.

Motivos que no se declaran. Construir es más interesante que integrar. Un programa grande otorga visibilidad y presupuesto. Y hay áreas cuya existencia se justifica por el tamaño de lo que construyen. Ninguno de estos aparece en un documento y todos pesan en la decisión.

El análisis de mapeo no elimina estos factores. Lo que hace es obligar a que la conversación ocurra con información: aquí están los componentes que son commodity, aquí los que diferencian, aquí lo que cuesta cada camino. Con eso sobre la mesa, la decisión sigue siendo política —todas las decisiones de esta escala lo son— pero al menos es una decisión informada.

Y con frecuencia produce un resultado intermedio que nadie había planteado: comprar la base, construir solo los tres componentes que efectivamente diferencian, e invertir la capacidad liberada en integración y datos. Suele ser la opción de mejor rendimiento y la que nunca llega al comité, porque el debate se planteó como comprar contra construir.

La pregunta que conviene hacer en el comité

La próxima vez que llegue una pregunta de estructura para un programa grande, vale la pena devolverla una vez antes de responderla: ¿qué parte de esto compraríamos si empezáramos hoy desde cero, y qué parte construiríamos aunque costara el doble?

La respuesta a esa pregunta define el alcance real. Y el alcance real define cuántos equipos hacen falta, no al revés.