Las aseguradoras se encuentran en una situación compleja debido a las expectativas de los clientes, de los competidores, de otras industrias y de los reguladores, que exigen introducir nuevas y crecientes soluciones ágiles.

Pero ¿cómo es la verdadera agilidad? ¿Cuáles son sus impactos? Hoy miramos algunos resultados específicos asociados a la agilidad. Por ejemplo: cuánto nos cuesta hacer algo por unidad, cuánto se tarda o cuánto trabajo manual requiere. Todo ello lleva a preguntarse cuánto tardará en cambiar la situación a nuestro favor. Esta es una buena cuestión y la siguiente imagen identifica cuánto tiempo conllevaban ciertas actividades.

La presión comercial ha hecho que ciertas actividades, como la fijación de precios, se hiciesen más rápidamente, mientras que otras, como el lanzamiento de nuevos productos, pueden tardar bastante (muchas compañías tardan entre 9 y 12 meses en colocar un nuevo producto en el mercado).

Agilidad i2S

Si avanzamos en 2018, podemos ver que existe una alteración, por lo menos con relación a las expectativas:

Agilidad i2S

La mayoría de las actividades han reducido su duración significativamente. Lo que antes tardaba años, ahora se ejecuta en meses; lo que se hacía en semanas, ahora se hace en días; y, en algunos casos, lo que antes conlleva un proceso de varios días, ahora se desarrolla en segundos. Todo ello, en muchas ocasiones, bajo un contexto de volumen creciente de trabajo.

En este cuadro hay algo que queda claro: ciertas actividades cambian más rápido que otras y si ciertos componentes de arquitectura no soportan ese cambio es porque no somos lo suficientemente ágiles.

Entonces: ¿cómo hacemos para ser ágiles? En todo ello algo tiene que ver la discrepancia entre la oferta y la demanda. En la mayoría de las aseguradoras, todo el mundo quiere las cosas al mismo tiempo. Sin embargo, pocas poseen los recursos para efectuar cambios en todos sus sistemas. Pero si cambiar todo a la vez no es una opción, ¿qué podemos hacer para alcanzar un nivel más elevado de agilidad?

El primer paso es definir qué significa agilidad para nosotros. Por ejemplo, en el diagrama de abajo podemos ver, en un contexto particular, cómo mapear la urgencia del cambio (la demanda) y la oferta del cambio (nuestra arquitectura).

Si necesitamos cambiar nuestra capacidad para crear nuevas experiencias de usuario, soportar nuevos equipos o lanzar nuevos productos más rápidamente, entonces nuestra arquitectura de canales, nuestro proceso de suscripción de riesgos y nuestros procesos de análisis de datos deben soportar esa velocidad de cambio.

Agilidad i2S

El segundo paso es saber cómo avanzar en la dirección correcta para crear los componentes de arquitectura que necesitamos.

Esta es, simultáneamente, la parte más fácil y la más difícil. Sin detallar demasiado, porque cada caso será de alguna manera único, existen algunos principios generales que podemos definir:

  1. Cambiar el ámbito de actuación: hay que cambiar los canales para adaptarlos a los nuevos sistemas y quebrar la dependencia de sistemas más antiguos. Por ejemplo, cambiando la validación para el front-end y desconectándola del back-end, manteniendo únicamente single points of truth.
  2. Cambiar las reglas: hay que impulsar las reglas de sistemas que cambian lentamente, adaptándolas a sistemas que cambian a un ritmo más rápido. Por ejemplo, motores de reglas, motores de clasificación u otros que pueden ser utilizados desde cualquier sistema.
  3. Automatizar: debemos dividir la funcionalidad en servicios y funciones y automatizar procesos/acciones/tareas. Esto no significa añadir tecnología, sino adoptar la automación como condición de base y con vistas a automatizar el 80% de los procesos, dejando el 20% para el software ya existente.
  4. Desacoplar: debemos separar conjuntos en sus partes constituyentes de forma que el cambio pueda ser aplicado de manera más granular. Mientras todos los sistemas estén alineados y operando como un bloque indivisible, todos tendrán que moverse conjuntamente. En particular, conviene separar reglas y datos de las aplicaciones, definiendo áreas claras de responsabilidad y conectándolas con procesos específicos.

Agilidad i2S

La clave reside en no descartar los sistemas que cambian a un ritmo más lento porque, en realidad, no podemos hacerlo. Lo que si podemos hacer es extraer la presión de esos sistemas, recurriendo a los cuatro principios esbozados arriba.

Si hacemos esto, podemos sustituir sistemas más lentos con mucho menos riesgo y a un coste más bajo, que terminarán siendo cubiertos por las ganancias de eficiencia resultantes de los cambios implementados en los procesos más abiertos al cambio, mejorando los resultados del negocio.