5 razones por las que tienes que involucrar a negocio en tu proceso de modernización.

No hay duda, un proceso de modernización de grandes aplicaciones es el proyecto más complicado en el que se puede meter cualquier compañía de cualquier sector: tecnologías obsoletas, pérdida de control del legacy, modelos de convivencia, acoplamiento… Este tipo de proyectos no sólo se enfrenta a retos tecnológicos y organizativos complejos, sino que además requieren de una inversión muy elevada.

Estos riesgos son bien conocidos por toda compañía que quiere abordar este tipo de proyectos y, aun así, hay algo que suelen pasar por alto: la necesidad de incorporar decididamente a negocio si quieres que la modernización vaya bien. Porque sí, la modernización de grandes aplicaciones y cores también es cosa de negocio. Hace unos días hablamos sobre cómo podía afectar la desconexión entre IT y negocio y hoy recopilamos las principales razones por las que incorporar a negocio es garantía de éxito.

1 Asegurar que el software entregado se utiliza.

La primera razón es la más obvia, el resultado final de una modernización de una gran aplicación o sistema core es software que alguien va a usar (clientes, equipos internos de distintas áreas de negocio…) y ya desde hace años se ha demostrado que obviar al usuario final en las prácticas de desarrollo software es tomar el camino directo al fracaso.

En el caso de modernizar un sistema antiguo, podemos caer dos errores al sacar al usuario de la ecuación:

• Pensar que lo quiero exactamente igual que lo que tengo ahora mismo.
  Esto pocas veces es real. La mayor parte de las veces que la oímos es porque no se ha ido a negocio a preguntar qué problemas les causa la herramienta o qué necesidades tienen paradas o bloqueadas. Parece que si se va a negocio, vamos a tener que realizar un sobreesfuerzo en el proyecto y se nos va a agrandar el presupuesto, pero nada más lejos de la realidad. Si la modernización escogida es una recodificación de todo el sistema, es más o menos igual de caro preguntar a negocio que copiar tal cual lo que tienes y gastar dinero en entregarles, años después, lo que ya tienen ahora mismo.
• Pensar que en IT hay personas que conocen perfectamente lo que se necesita.
  Aunque es cierto que en IT puede haber personas que conocen perfectamente cómo están implementados los procesos de negocio, estas personas no suelen saber cómo se utiliza, la frecuencia de uso, resto de tareas que hace fuera de la herramienta o problemas que tienen a la hora de utilizarla. Recoger esa información de primera mano es importante para no jugar al teléfono escacharrao e implementar lo que realmente necesita negocio sin invertir, de nuevo, esfuerzo y tiempo en realizar algo que no se adapta a lo que necesitan.

No hay que descuidarse porque, aunque sea la más obvia, no es una premisa que esté interiorizada y nos hemos encontrado con varias compañías en las que han tenido que tirar a la basura el proyecto una vez terminado (con sus millones de euros gastados) porque lo que se entregó no casaba con el negocio.

2 Preparar a la compañía para los retos de presente y futuro.

El resultado de un proyecto de modernización no es algo que vaya a estar en producción 1 ó 2 años y luego vaya a hacerse de nuevo. Se espera que el resultado dé servicio a la compañía durante décadas. Esta premisa la tenemos muy clara a la hora de plantear la nueva solución tecnológica. Sin embargo, suele pasarse por alto en el plano funcional cuando te piden “que funcione tal y como funciona ahora”.

Hay que aprovechar este proceso para pensar en lo que la compañía va a tener por delante en los próximos años a nivel negocio: retos, competencia, innovación, diversificación, eficiencia operativa… Y es importante aprovechar este proceso para incorporar este tipo de conversaciones por dos motivos:

• El proceso de modernización va a llevar años, así que estos retos van a llegar sin la modernización terminada.
• Si este software tiene que dar servicio durante años tiene que estar preparado para ello y que no sea un limitante en el futuro.

Y esto es totalmente imposible de hacer si no se tiene a negocio muy presente en el proceso de modernización.

3 Garantizar la continuidad del proyecto.

Los proyectos de modernización son proyectos que consumen mucho esfuerzo de la compañía, tanto a nivel de inversión como de esfuerzo humano necesario para llevarlo a cabo. Por eso, aunque el proyecto pueda mantenerse en un principio dentro del perímetro de IT, en algún momento este va a acabar traspasando esa barrera y llegando a negocio.

Cuando esto ocurra y la modernización llegue a negocio (si no se les ha involucrado desde el principio), lo va a hacer de la peor manera posible, en forma de problemas. Problemas porque les cambiarán la forma de hacer las cosas sin preguntarles, problemas porque les pararán iniciativas por falta de capacidad en el área de IT o, quizá, porque el modelo de convivencia planteado no permite incorporar determinada funcionalidad que negocio requiere.

Esos problemas provocarán que la organización se desfonde, que surjan las dudas alrededor de la modernización y comiencen a retirarse los apoyos que provoquen la reducción presupuestaría para el proyecto o la repriorización de iniciativas.

4 Optimizar el presupuesto dedicado al proceso de modernización.

Cuando nos enfrentamos a la modernización de un sistema aparece el vértigo de cuánto tiempo y dinero me va a costar modernizar esto. Por desgracia, es una pregunta que no tiene respuesta cien por cien fiable a no ser que dediques demasiado tiempo a analizar el sistema. La buena noticia es que, en un mundo de asignación de presupuestos anual, no es necesario tener esa respuesta.

Modernizar o no un sistema en su totalidad es una decisión que puede tomarse a lo largo del proceso. Para ello, hay que trabajar en una fragmentación del sistema en partes más o menos independientes que tengan una entrega de valor identificada. De esta forma, priorizando estas partes teniendo en cuenta el valor de negocio que aportan o las criticidades que resuelve, se podrá ir asignando y gestionando el presupuesto teniendo claro el retorno de la inversión realizada.

Además, poder demostrar que las inversiones y el esfuerzo que se dedican a estos proyectos sirven para algo concreto y medible, va a facilitar el levantamiento de presupuesto en la dirección.

5 Legitima al equipo de IT al ir entregando valor de forma constante.

Muy de la mano con el punto anterior, esa fragmentación del sistema teniendo en cuenta los procesos de negocio permite una entrega de valor constante y medible. Esto le da armas a IT, que consigue así una trazabilidad clara entre los nuevos y costosos activos tecnológicos y el impacto en negocio. De esta forma, podrá comunicar de forma irrebatible y entendible al resto de la organización los logros alcanzados gracias a un proyecto de IT.