El caso de negocio para una plataforma de desarrollo organizacional y talento: vende la decisión, no el software

La mayoría de los casos de negocio para software de desarrollo organizacional y de talento se pierden en los primeros diez minutos de la reunión, y por el mismo motivo. Describen el software: funcionalidades, módulos, integraciones, horas ahorradas por responsable. La alta dirección oye un coste nuevo con beneficios que suenan difusos y llegan más tarde. Los casos que se aprueban se construyen al revés. Parten de un problema organizacional caro y recurrente que la dirección ya siente, muestran lo que cuesta ese problema y presentan la plataforma como la forma creíble más barata de dejar de pagarlo. Y piden un piloto antes de pedir un presupuesto.

Hemos estado en los dos lados de esta conversación, ayudando a responsables de RR. HH. y de estrategia a construir casos y sentados frente a los equipos directivos que deciden sobre ellos. Hay un consejo incómodo que damos siempre: si no puedes nombrar la decisión que la plataforma va a cambiar, no deberías comprarla. Eso incluye comprar la nuestra.

«Me has dicho lo que hace, no lo que cambia»

El director de RR. HH. de una empresa de Arabia Saudí con unos trescientos empleados dedicó varias semanas a preparar un caso de negocio para una plataforma de talento y desarrollo organizacional. Ocupaba treinta diapositivas: una comparación de funcionalidades de cuatro proveedores, una estimación de las horas ahorradas en evaluaciones de desempeño y en informes, y un cálculo del retorno de la inversión construido con cifras de los proveedores.

El director financiero lo rechazó en unos diez minutos. Lo que se le quedó grabado al director de RR. HH. fue el motivo: «Me has dicho lo que hace. No me has dicho qué cambia, ni quién lo cambia.»

El segundo intento fue una sola diapositiva. En el retiro del equipo directivo unos meses antes, el director general se había quejado de que tres de las iniciativas estratégicas del año estaban estancadas y de que nadie sabía decir quién era responsable de ellas. El nuevo caso nombraba ese problema, estimaba los ingresos retrasados de solo una de las tres iniciativas, proponía un piloto de noventa días en el que el equipo directivo usaría la plataforma para asignar la responsabilidad de esas tres iniciativas y hacerles seguimiento, y pedía financiación solo si el piloto alcanzaba una medida acordada de antemano. Se aprobó en la misma reunión.

El Caso de Negocio de Una Decisión

La estructura que hay detrás del segundo intento tiene cinco partes, y sirve para casi cualquier inversión organizacional, no solo para el software.

1. El problema. Un problema organizacional con nombre, recurrente y costoso, que la dirección ya ha sentido, idealmente expresado con sus propias palabras. Iniciativas estancadas, derechos de decisión poco claros, rotación no deseada en un equipo crítico, una reestructuración que no ha cuajado. Si la dirección no cree ya que el problema existe, ningún caso de negocio la convencerá; empieza por ahí.
2. El coste de no hacer nada. Una estimación, en rangos, de lo que cuesta el problema si continúa, expresada en términos que la dirección ya usa: ingresos retrasados, contratos perdidos, costes de sustitución, tiempo de dirección dedicado a escaladas. Prudente y creíble gana a grande y discutido.
3. El cambio. Qué decisión o comportamiento será distinto, y quién lo hará de otra manera. Es la parte que la mayoría de los casos omite, y es la que pedía el director financiero de la historia. El software no cambia nada por sí solo; lo que cambia las cosas son las personas que lo usan para decidir de otra forma.
4. La prueba. Un piloto corto y acotado en el tiempo sobre el problema real, con las personas cuyas decisiones deben cambiar y una medida acordada antes de empezar.
5. La petición. Un compromiso escalonado ligado al resultado del piloto, con el coste completo explícito, incluido el tiempo interno, y una forma clara de parar si no funciona.

Un caso construido así ocupa a menudo menos de una página. No es una debilidad; es lo que permite que lo lea un equipo directivo con otras cuarenta decisiones que tomar ese mes.

Aquí está la parte a contracorriente

No abras con un porcentaje de retorno de la inversión. Es la parte de un caso de negocio de software en la que la dirección menos confía, porque sabe que viene del proveedor, y desplaza la discusión hacia los supuestos que hay detrás de la cifra en lugar de hacia el problema. Una estimación modesta de un coste en el que la dirección ya cree es mucho más persuasiva que un gran retorno que tiene que aceptar por fe.

Pide menos de lo que necesitas. Un compromiso escalonado con un piloto es más fácil de aprobar que un gran contrato anual, y cambia la pregunta que responde la dirección de «¿vale esto lo que cuesta?» a «¿vale esto noventa días?». Si el piloto funciona, la segunda aprobación es mucho más fácil de lo que habría sido la primera.

Incluye tú mismo los costes ocultos. La licencia rara vez es el mayor coste de una plataforma organizacional. Lo es el tiempo de la dirección, seguido del trabajo de preparar los datos actuales sobre estructura y roles y del cambio necesario para que la gente la use de verdad. Los casos de negocio que los omiten no son más persuasivos. La dirección piensa en ellos de todos modos, y la omisión le cuesta credibilidad al autor.

Por qué funciona

Las razones están bien documentadas en la investigación sobre la toma de decisiones. Samuelson y Zeckhauser describieron el sesgo del statu quo a finales de los años ochenta: cuando las personas eligen entre mantener la situación actual y cambiarla, favorecen la situación actual más de lo que justifican sus méritos. Por eso un caso de negocio tiene que hacer visible el statu quo como una elección con sus propios costes, no como una opción neutral por defecto. Eso es lo que hace la sección del coste de no hacer nada.

La teoría prospectiva de Kahneman y Tversky explica por qué importa el enfoque además del contenido. Las pérdidas pesan más que las ganancias equivalentes, así que un problema que la dirección ya está pagando se valora más que un beneficio que podría obtener. John Kotter planteó lo mismo en términos organizacionales en Leading Change: el primer paso de cualquier cambio es crear un sentido de urgencia, y un caso de negocio que tiene que crear urgencia de la nada va cuesta arriba.

Por último, coincide con lo que vemos en las organizaciones que sacan valor de plataformas como esta. El valor casi nunca viene solo del software; viene de un equipo directivo que decide de otra manera, porque la estructura, la responsabilidad y las medidas que necesita por fin son visibles en un solo lugar. Nuestros artículos sobre por qué falla la ejecución de la estrategia y la deriva de las decisiones describen los problemas que hacen que merezca la pena pagar por esa visibilidad.

Una lista de comprobación práctica

• Encuentra el problema en las palabras de la propia dirección: notas del retiro, discusiones del consejo, la queja que el director general no deja de repetir.
• Estima el coste de un solo episodio del problema, con prudencia y en rangos, en términos de negocio y no de RR. HH.
• Escribe una frase sobre qué se decidirá de otra manera y quién lo hará. Si no puedes, detente y reconsidera la compra.
• Diseña un piloto sobre el problema real, acotado en el tiempo, con los responsables de las decisiones implicados y una medida acordada de antemano.
• Enumera el coste completo, incluido el tiempo de la dirección, la preparación de datos, la configuración, la formación y el apoyo al cambio.
• Pide un compromiso escalonado ligado al resultado del piloto, e incluye cómo pararías.
• Comprueba el encaje con honestidad antes de presentar el caso. Nuestras guías sobre para quién está pensado Green Apple y cómo se compara con otras plataformas están escritas para ayudarte tanto a descartarnos como a elegirnos.

Pregúntate

• ¿De qué problema organizacional se ha quejado ya nuestra dirección más de una vez este año?
• ¿Cuánto nos costó, aproximadamente, la última vez que se produjo ese problema, en términos que reconocería el director financiero?
• ¿Quién tomaría qué decisión de otra manera si existiera esta plataforma, y se lo hemos preguntado?
• ¿Qué resultado de un piloto de noventa días nos convencería de ampliarlo, y qué resultado nos convencería de parar?
• ¿Compramos esto para resolver un problema, o porque otras empresas como la nuestra tienen uno?

La conclusión

La alta dirección no financia software. Financia el final de un problema que ya está pagando. Nombra ese problema con las palabras de la propia dirección, estima su coste con honestidad, di quién decidirá de otra manera, demuéstralo con un piloto corto medido frente a un resultado acordado y pide un compromiso escalonado. Si no puedes nombrar la decisión que la plataforma va a cambiar, el caso de negocio más creíble es el que no presentas.