concepto de idea bombilla decisiónUn proceso de evaluación de transformación de sistemas core es un proyecto en sí mismo. Desde que se decide que hay que valorar un cambio, hay una cantidad enorme de asuntos a tratar. Las dificultades de hacer mejoras, mantenimiento de sistemas, obsolescencia, falta de personal que conozca los lenguajes de programación antiguos, afrontar el futuro, nuevas necesidades, procesos, productos… Suele haber muchas razones que justifican el cambio y ordenarlas es ya una tarea complicada. Cada aseguradora lo planteará de una forma distinta.

Es común solicitar la ayuda de un tercero que dé una visión de mercado externa a la compañía. Esto ayuda a la hora de plantear la transformación de un modo que no nos lleve a querer hacer lo mismo con una tecnología diferente. Si el objetivo es conseguir resultados distintos, como dijo Einstein, hay que cambiar la manera de intentarlo.

Durante los procesos de evaluación, como se hace con muchas otras soluciones, se hace una lista de proveedores, que normalmente se valora a partir de informes de analistas. Luego se da comienzo un proceso de análisis basado en presentaciones, demos y sesiones, que ayudan a saber si el modelo, filosofía y estrategia del que pueda ser nuestro proveedor, están en línea con las nuestras. Como suele ocurrir en proyectos de software, se analiza, se califica y se acaba comprando lo que plantee un mejor equilibrio entre calidad esperada y precio…esperado. Lo que ocurra después ya difiere en cada caso.

Cuando se trata del core de la compañía, el riesgo que se asume es tan alto que el análisis y las decisiones deben ser absolutamente justificadas y firmes. Las necesidades de movilización de equipos y las implicaciones de una transformación no permiten cambios a mitad de proceso y, aun así, ocurre con frecuencia. Participamos en muchos proyectos en los que estamos cambiando sistemas que nunca han salido a producción. Cuando se habla de costes, es importante valorar el coste que tiene una mala decisión.

Como indicaba antes, evaluar mediante sesiones específicas, demos y tratar con otros clientes siempre ayuda. Muchos clientes nos piden pruebas de concepto y, aunque podemos hacerlas, un core es tan amplio que siempre, por muy acotada que sea la prueba, van a faltar cosas. Además, lo más probable es que el esfuerzo dedicado a la prueba de concepto no sea reutilizable para el proyecto. Entonces, ¿cuál es la manera de saber con precisión el grado de cumplimiento que ofrece un producto? La forma más precisa y útil es mediante una Inception.

¿Qué es una Inception? Bueno, yo he buscado el termino Incepción a ver qué encontraba, pero la palabra no existe en español. En 2010 se tradujo una película con el título original de Inception como Origen… como se ve, por semántica no voy a poder explicarlo.

Cuando hablamos de Inception, nos referimos a una fase inicial de proyecto en la que se planifican sesiones de trabajo con los responsables de cada área, en la que se comienza con una demo orientada al asunto a tratar y se trabaja después en las necesidades, adaptabilidad y cambios que se deben hacer para saber el esfuerzo que supondrá y definir, con precisión, el coste y esfuerzo del proyecto. A la vez, y no menos importante, el cliente va a ver cuál es el nivel de cumplimiento de lo que pide de la solución.

La experiencia de nuestros clientes tras las Inceptions siempre ha sido muy positiva. A mi modo de ver, lo mejor que tiene es que tanto tecnología como negocio y operaciones participan en sesiones ordenadas en las que se da respuesta a cualquier asunto relacionado con el tema a tratar y, al cabo de unas semanas, se tiene una imagen muy clara de cómo se va a realizar el proyecto, cuándo va a terminar y qué se va a conseguir. Si queremos empezar a construir la casa por los cimientos, esta es la mejor manera.


Asís Angolotti, GuidewireSobre el autor del artículo

Asís Angolotti es director de Ventas para España y Portugal de Guidewire Software.