Uncategorized

ENTREVISTA FRANCESC RABASSA  General Manager at CA Life Insurance Experts.     La tecnología en general y el lanzamiento de las Insurtech en particular están revolucionando la industria del seguro, ¿Qué tecnología piensas que va a tener mayor impacto? Creo que todo lo relacionado con servicio al cliente. La distribución ya esta muy avanzada, todo y que los resultados no son lo que se esperaba, ya que el cliente sigue informándose por todos los canales, pero contrata físicamente (considerando la vía telefónica también un canal presencial). Lo que este orientado al servicio derivado de las coberturas, así como todo lo que forme parte del ecosistema de la póliza es donde hay un desarrollo importante ya que también es una vía de vinculación y afinidad con el cliente. El internet de las cosas esta facilitando este contacto y prestación de servicios adicionales. Internamente, el blockchain será una de las novedades en cuanto a la gestión legal entre las partes, aunque creo que queda mucho por desarrollar aun antes que forme parte de la normal gestión diaria.   ¿Qué estrategia o iniciativas tiene su compañía en materia de innovación? ¿Colaboran o tienen pensado colaborar con alguna insurtech? La estrategia de innovación en CA Life, actualmente pasa todavía por desarrollos de gestión con la mediación y con los procesos, somos una compañía pequeña en crecimiento por lo que hemos de pensar en procesos directamente relacionados con negocio. No obstante, debo comentar que veo una inflación en las inversiones en insurtech que creo que esta llevando a un burbuja inversora en el sector. Establecer presupuestos para este concepto, implica que se realicen las inversiones esperando que alguna que funcione compense las inversiones que no.   ¿Piensas que la innovación es algo que debe de desarrollar un departamento en concreto o debe de permear a toda la organización?, ¿es posible involucrar a toda la compañía? Debe ser un concepto general de la organización, facilitando que todas las áreas puedan opinar sobre otras en los modelos. La única forma de romper los paradigmas es que alguien desde fuera, pueda introducir elementos de disrupción. Esto implica una organización dinámica, transparente y con canales de comunicación eficaces. No es sencillo, pero si posible a través de equipos multidisciplinares que a través de técnicas de innovación permitan canalizar estas ideas para llevarlas después a la práctica, lo que redunda finalmente, además, en el engagement de la organización.   ¿Se considera una persona conectada? Dentro de las limitaciones del tiempo y de los conocimientos, si me considero una persona conectada e intento estar al día de las novedades tecnológicas.. Dispongo de cuentas en Twiter y en LinkedIn para un uso profesional y en Instagram que es más personal. No suelo transmitir mi vida a través de las redes porque soy muy celoso de mi intimidad por lo que diferencio mucho las redes y los mensajes que a través de ellas transmito. Eso por ejemplo me lleva a no aceptar a gente que no conozca previamente en las redes sociales profesionales y a muy pocos, de un círculo más privado en las redes que considero personales. Sobre el resto de las gestiones, desde hace muchos

“Los índices son buenos para el rendimiento” En términos generales, los DBA y los desarrolladores pasan una buena cantidad de su tiempo de rendimiento tratando de encontrar qué índices agregar a una base de datos para mejorar el rendimiento. Si una consulta específica tiene problemas de rendimiento, una de las herramientas más sólidas para solucionar el problema es la indexación. Esta es una verdad indiscutible, casi dogmática. Universalmente conocida, como el hundimiento de la Armada Invencible. “Los índices son malos para el rendimiento” Sin embargo, ¡Sorpresa!  los índices no son del todo buenos. Dejando a un lado el hecho de que algunos índices, particularmente los índices con baja cardinalidad pueden dañar el rendimiento, los índices se almacenan físicamente en el disco. Esto significa que no sólo ocupan espacio en el disco, sino que también perjudican el rendimiento de las operaciones que insertan, actualizan o eliminan datos. Cada índice adicional representa un lugar más en el disco y Db2 tiene que insertar, actualizar o eliminar los mismos datos que están almacenados en la tabla. Los índices también deben mantenerse a través de reorganizaciones y estadísticas de ejecución y deben respaldarse con el resto de la base de datos. Esta parte ya no es tan universalmente conocida, como la derrota de la contraarmada inglesa primero en La Coruña y luego en Lisboa y Azores. Teniendo esto en cuenta, hay que establecer nuestras prioridades de rendimiento a la hora de calcular cuántos índices hay que agregar. Estas prioridades pueden ser diferentes de una tabla a otra dentro de la misma base de datos. Muchos consultores de Db2 cuentan historias de terror como entrar en un cliente y encontrar 30 o más índices en una tabla que es fundamental para el rendimiento de OLTP. Al menos un consultor que conozco afirma haber costeado la universidad de sus hijas y sus respectivas bodas eliminando índices. ¿Cuántos índices hay que crear, entonces? No hay un número mágico para el número correcto de índices en una tabla. Para Db2, a menudo un buen índice que ayuda a múltiples consultas es mejor que un índice perfecto para cada consulta. A menudo, es probable que las bases de datos en el extremo del espectro de análisis / BI / Data Warehouse tengan más índices que los del extremo del espectro OLTP / procesamiento de transacciones / comercio electrónico. Esto se debe a que la prioridad en las bases de datos analíticos son las consultas, mientras que la prioridad en las bases de datos de procesamiento de transacciones a menudo son las pequeñas actualizaciones, inserciones y eliminaciones de una sola fila que los índices adicionales pueden ralentizar. Identificación de índices no utilizados Con Db2 9.7, IBM introdujo una columna en varias vistas del sistema, incluido SYSCAT.INDEXES, que registra la última vez que se utilizó un objeto. Esta columna, llamada LASTUSED, no se actualiza inmediatamente después del uso de un objeto para evitar el impacto en el rendimiento, pero generalmente es precisa. Hubo algunos problemas con los primeros fixpacks de 9.7 (allá por 2010), por lo que los números realmente