 Voy a comentarles el caso y la experiencia. ¿Cuál es la situación nuestra? Bueno, me difé como mostraba el video. Tenemos más de 300.000 afiliados. Más de 300.000 asociados, 60 sucursuales en todo el país, diferentes planes, nuevas soluciones que hemos lanzado recientemente como la consulta virtual a través de la web o de la app. Me difé, trabaja también en conjunto con otras entidades de salud, por ejemplo, ASE. ASE tiene un centro médico propio, que es el sanatorio finoquieto. El sanatorio finoquieto es un centro médico altamente tecnificado. Tiene unos 5 años y desde su concepción, la tecnología fue central. El sanatorio posee la historia clínica integrada desde el principio, donde hay trazabilidad de todos la historia del paciente, integración con las imágenes, exámenes de laboratorio. Desde el ingreso en una internación el paciente se le asigna una pulsera con un código QR. Los enfermeros tienen iPods. Con los iPods escanean el código QR y les aparece la medicación que tienen que administrarle. Llega también la medicación a cada piso, a cada habitación. La administra a través de registro de administración a través del app. Escanean los códigos también de los medicamentos, actualizan estoque. Y todo eso se actualiza en la historia clínica para que después los siguientes enfermeros y los médicos ven cómo fue el comportamiento del paciente junto con los signos vitales. Y también toda la parte de neonatología tiene todos sistemas de seguridad para los recién nacidos. Es un poco para, quería contarles cuál era la situación tecnológica y cómo cada vez más la tecnología va entrando y va generando muchas demandas en el segmento de salud. Muchas veces, bueno, todo esto necesita que los sistemas que está por detrás que viabilizan todo esto acompañen a ese ritmo. En el caso de Medifé, yo estoy hace un año y medio en esta posición. Medifé es una, la entidad está organizada en unidades de gestión. Antes de mi llegada, la cada unidad de gestión tenía sus departamentos de tecnología separados, poca integración, diferentes soluciones. En muchos casos, las mismas soluciones que hacían lo mismo, pero diferentes. Y, claro, a medida que avanza la tecnología, surgen más y más demandas de interoperabilidad y que justamente todo esto se vea también viabilizado a través de esta solución y se hacía muy difícil. En resumen, teníamos un mapa de soluciones complejos con integraciones realmente complejas, muchas integraciones punto a punto o a través de bases de datos y junto con dos organizaciones, digamos, de tecnologías separadas. Teníamos muchas soluciones monolíticas, soluciones arquitectura de tres capas, donde estaba todo el código, digamos, todas las reglas de negocios embutidas en el código. Lo que hacía muy difícil y muy costoso en términos de recursos y de tiempo poder escalar y poder apalancar el lanzamiento de nuevos productos. Por ejemplo, para lanzar un producto nuevo que demanda desde temas de autenticación y provisionamiento y también validaciones, se hacía realmente muy difícil y lento. No se podía acompañar la necesidad, el ritmo que demandaba la operación, el segmento. ¿Qué hicimos? Bueno, entonces, primero, identificamos, diseñamos un framework donde definimos los diferentes dominios funcionales. En cada dominio funcional fuimos agrupando las diferentes aplicaciones, las diferentes soluciones, muchas de las que realmente estaban repetidas y hasta con diferentes tecnologías. Definimos en esos dominios funcionales las aplicaciones comunes, en algunos casos, algunas soluciones de mercado, como puede ser un RP o una solución paranoamina, por ejemplo. Pero en lo que es la construcción de la solución CORE y para lograr toda la interoperabilidad, ahí fue que nos definimos por OpenShift. Justamente todo este proceso de selección hicimos un análisis técnico, nos basamos en estándares y mejores prácticas de industria. Consultamos referencias como Garner, Forester, y también, digamos, diferentes referencias. Y dentro de soluciones de primera línea nos definimos por OpenShift, por, digamos, la tecnología. Y también mucho por el conocimiento que nos daban, la confianza que nos daban del conocimiento del sector que tenía la gente de Red Hat. Y así fue que, bueno, definimos y emprendimos este camino, ¿no?, como la chica de la publicidad. ¿Cuál es el objetivo de esta, digamos, evolución o migración tecnológica? Bueno, primero, darle el ritmo que demandaban las sales operativas para tener un time to market más rápido, dar un mejor servicio a los asociados. Nosotros vemos que cada vez cada uno de ustedes como asociado de alguna entidad de salud tiene más y más demandas. O sea, mucha movilidad, mucha autogestión. Y también para los usuarios internos de la organización. Trabajar con estas diferentes soluciones a la operación se le hacía también difícil y bastante tedioso, ¿no? Porque a veces tenía que trabajar con algunos asociados, con una aplicación o con otros con otra. Y hacía bastante pesado. Y necesitábamos justamente tener mucha integración, mucha interoperabilidad y una arquitectura robusta que nos permita crecer. Bueno, esto es un diseño macro de la solución. Acá sería, en este lado, sería alguna de las soluciones legasis que tenemos monolíticas. Lo que hicimos fue en las aplicaciones centrales. Tenemos básicamente unas tres, cuatro aplicaciones centrales, donde está el código, digamos, de la gestión de la operación. Fuimos identificando en estas soluciones todos los diferentes procesos y funcionalidades. Los catalogamos. Fuimos priorizándolos con las áreas operativas. Y a medida que, bueno, priorizábamos, cuando hicimos esa priorización, hicimos un balance entre el valor que le agrega la operación y la complejidad. Tratando de empezar por los más simples, ya el hecho de tener un primer proceso migrado e interoperando es un paso enorme, porque es justamente valida toda nuestra estrategia, que era llevar todos esas conjunto de soluciones legadas a una única orientada, una arquitectura orientada a microservicios que nos permita el día a manera de tener más y más flexibilidad, esa flexibilidad y esa escalabilidad que demanda el sector. Comenzamos el trabajo, digamos, de especificaciones. Y ahí también implementando metodologías ágiles. Ahora podemos hablar un poco más, pero especificando, desarrollando y probando cada una de los nuevos procesos. Y lo fuimos haciendo, digamos, estamos trabajando en forma que sea lo más transparente posible para la operación, para los usuarios finales. El objetivo es cada uno de estos procesos y funcionalidades, los vamos llevando a la nueva solución en containers. Trabajamos, bueno, utilizamos de OpenShift, Threescale como el API Manager. Tenemos Fuse como el USB. Y el PAM7 como VPN para todas las reglas de negocio, ¿no? El VPN que gestiona todas las reglas de negocio. A medida que vamos migrando los procesos del punto de vista de la operación, va a haber, tiene un nuevo frontend, estamos trabajando con Angular, pero lo hacemos en forma bastante transparente. Dentro de la bandeja legacy que tiene el operador, vamos reemplazando los puntos y cada una de las funcionalidades. Él va a ver que le aparece una nueva pantalla, una nueva, digamos, ya directamente cada una de la nueva aplicación. Él ve un cambio, ve un nuevo Lucanfill más amigable, también ahí trabajamos mucho con las áreas operativas. Termina de hacer la operación que necesita hacer en la nueva funcionalidad y vuelve a la bandeja original. Todo lo que hizo en la nueva aplicación se refleja en la misma base y va a seguir operando. Y lo que hizo, por ejemplo, una alta de un responsable, le va a aparecer después en las distintas funcionalidades de la aplicación legacy. Y así estamos, digamos, trabajando, migrando, llevando adelante toda esa migración. Hay una ganancia muy grande en performance. La verdad que ahí nos sorprendió gratamente la performance que tenemos con la nueva plataforma. Se ve y eso también nos da una ventaja que las áreas operativas piden, bueno, queremos más rápido, queremos más, que vayan miglando todo lo nuevo en forma más rápida. Esto sería básicamente el modelo, digamos, la visión macro de la solución. Esta, digamos, todo este despliegue lo fuimos haciendo en etapas, separamos principalmente dos etapas. Uno donde es la fundación, donde instalamos todos los fundamentos de la nueva plataforma. Trabajar en la integración, hacer que esa interoperabilidad funcione realmente, manteniendo la integridad de los datos es un paso enorme. Por eso empezamos con algo con funciones más simples, con procesos más simples. Y ahora estamos en la etapa de expansión, llevando, digamos, y cada vez más procesos. También alternanlo con una metodología ágil. Esto lo que nos permite es que no necesariamente vamos a seguir el orden que priorizamos o que vamos a seguir priorizando al principio, sino que, si surge una nueva, como nos está pasando, surgen nuevas demandas. Directamente lo podemos construir en la nueva y vamos trabajando con esta priorización en forma ágil. Bueno, todo el despliegue lo tenemos automatizado con Jenkins, trabajamos con Selenium, con los tres de regresión. Aquí también tenemos una ganancia muy grande, un beneficio muy grande con la forma de metodología, trabajo tradicional que llevaban antes las áreas, de definición, desarrollo, test. Y muchas veces en la etapa de test, los usuarios cuando valían decían, no, esto no es lo que pedí o no, esto no es lo que necesito. O el negocio cambió otra vez para atrás. Proyectos, hubo algunas tentativas antes de ir llevando adelante esta consolidación, porque me dice que creció muy rápido, tuvo un crecimiento muy grande y esas tentativas fueron, pero proyectos de muchos años, hay algunos, algunas iniciativas que fueron más de 5 años. Cuando, no, hace un año y medio, el equipo que estaba justamente en la etapa final de uno de estos proyectos tan largos, se notaba un equipo cansado, un equipo bastante, está desanimado con una cosa que veía que era muy difícil llegar al fin. Utilizamos Yamiter para todo lo que es testeo de carga y volumen, acá también le estamos mostrando una ganancia, con Selenium automatizando las pruebas, cada vez que hacemos un nuevo despliegue, automáticamente tenemos todo el test de regresión. Y con una ventaja que lo implementamos de forma tal que, cuando en la regresión encuentra un error, se abre automáticamente el travel ticket. Y eso entonces ya directamente para la subida en producción. Y tenemos Sonar para hacer toda la validación del código. Bueno, metodologías ágiles es fundamental. Acá el cambio lo que decía antes. Antiguamente las iniciativas y todas las áreas de tecnología que existían trabajaban con metodologías bien tradicional, muy fuerte, mucha orientación a desarrollo de software. Entonces los equipos también tuvimos que acomodando, desarrollando perfiles, perfiles de análisis, material de desarrollo, capacitando también, junto con OpenShift también adquirimos capacitaciones y equipos de testing, de test o también para hacer toda esta automatización. Pero con los principios ágiles de empezar pequeños, por eso como decía, empezar con un proceso más chico, más simple, pensando en grande, pensando no solo en la aplicación que estamos migrando, sino en todo lo que va a venir. Y aprender rápido para ganar velocidad de dinamismo, ese dinamismo que nos pide el sector. Bueno, este proyecto, esta iniciativa es un cambio cultural que trasciende la salida de tecnología. Implementar metodologías ágiles no es solo TI. Por todo lo que dije, suena muy lógico, muy racional. Todo el mundo debe estar sí, esa es la forma, pero trabajamos con equipos de personas y cada uno a cada diferentes áreas tienen inclusive diferentes formas y diferentes perspectivas para ver las cosas. Y necesitamos que se sumen, que se sumen y que trabajen en conjunto, trabajen en equipo. Es muy importante administrar ansiedades, muchas veces con sistemas legacy antiguos, digamos, cuando cuesta esa evolución, las áreas usuarias piden, a veces, mucha demanda, muchas veces hay limitaciones sistémicas que las compensan por operaciones manuales. Entonces, a veces, hay una cara muy importante. Si nosotros pensamos, por ejemplo, que servicios como el servicio financiero, los bancos no se pueden equivocar, pues equivocan el saldo, generan un problema a los clientes. Acá es salud, es recontra sensible. Pense a alguien que va a atender un hijo y tiene un problema con el sistema, es realmente súper, súper sensible. Esa sensibilidad se transmite directo a la operación. Entonces, esas situaciones de estrés, tenemos que administrarlas ahí. Nuestro rol de tecnología y de líderes también es trabajar mucho en la contención, trabajar mucho en que siempre se mantenga el respeto en las relaciones, porque tenemos muchas relaciones con las diferentes áreas usuarias. Alguien todo se puede equivocar en una definición o pueden demorar en una definición. Y tenemos que desarrollar mucho eso en los equipos. Hay mucho trabajo interdisciplinar con áreas con background muy diferente. También es importante resaltar este punto que lo optimo es el enemigo de lo bueno. Si queremos ser ágiles, muchas veces no se puede. Buscar la perfección en la definición de un proceso. Hay veces que tratan para definir algún proceso, buscar el proceso perfecto. Y el proceso perfecto es muy difícil. Lo puede llevar mucho tiempo. Así son esas metodologías tradicionales donde están mucho tiempo. A veces pues llegaste un año definiendo alguna función. Acá, a veces decimos, como decía, creo que era Emerson Fittipaldi. Cuando tengo todo, todo su recontrol quiere decir que no estoy yendo lo suficientemente rápido. Y es un poco así. El espíritu ágil es ese. Es tratar de ser rápido, obviamente. Hay que saber frenar. Pero tenemos que darle velocidad, darle dinamismo. Y por eso una plataforma que nos dé esta flexibilidad que podamos ir haciendo entregas graduales y tal vez ir evolucionándolas. Pero por eso mantenemos siempre esta cultura. Bueno, proceso de transformación, digamos, todo lo que tiene que ver con la visión macro de la arquitectura. Nada, una arquitectura robusta, escalable. Los que les decía que una sorpresa muy grata fue justamente la performance. La verdad que la performance es que estamos teniendo. Fue muy buena. Es un beneficio así que la operación lo ve. Cuando uno ve y vamos cambiando, digamos, los procesos van viendo lo que es el viejo y no la diferencia de la velocidad se ve es nítida. Esta arquitectura, bueno, orientada a microservicios, nos permite, la mayor integración, pero, a tu vez, nos permite, digamos, la reutilización. Lo que antes era lanzar un producto y tener que desarrollar una aplicación web y una aplicación mobile. Ahora tenemos la posibilidad de poder reutilizar mucho más fácil todos estos servicios. Externalizar también la lógica. Es otro punto muy importante. Esto también nos da bastante más flexibilidad a la hora de tener que implementar un cambio y también justamente volver ese tema de ser rápidos para entregar y poder después tener la posibilidad de ir ajustando los distintos procesos. Bueno, resumen, digamos, como beneficios, tener este despliegue automatizado seguro. Administrar estos microservicios es algo que nos permite un crecimiento rápido más con un segmento que cada vez nos está y nos va a demandar todavía mucho más. ¿Qué es lo que vemos del sector salud? Y esto también aplica a cualquier industria o servicio que va a continuar creciendo para, ¿hasta dónde va a ir? No sabemos, pero sí sabemos que va a seguir creciendo y hoy vemos tendencias. Vemos que en otros países, por ejemplo, las teleconsultas son cada vez mayores. Va aumentando. Acá lo estamos viendo también. Las tasas de crecimiento y adopción son cada vez mayores. Creo que hace poco salió alguna publicación que justamente, en muchos casos, en vez de tener que ir a una guardia y exponerse a una gripe, tal vez con una videoconsulta de suficiente. Y bueno, eso va aumentando cada vez más la demanda. Desde cosas simples como una credencial digital o tener acceso a la cartilla médica son algunos de los temas que vemos en el corto plazo. ¿Y hacia dónde va? Hay mucho automatización de actividades. Libera manos, digamos, para que los equipos de la operación puedan dedicarle más al análisis. Tenemos, vemos una demanda cada vez más creciente, dices, ¿a dónde queremos llegar? Mucha más autogestión, que el asociado, en vez de tener que ir a las filiales o ir presencialmente a hacer algunas series de pedidos, lo que fuera, puede tener todo mucho más autogestión. El paciente, también, automatización en seguimientos de algunos pacientes crónicos. Ahí estamos viendo, digamos, soluciones para que, a través de herramientas automatizadas a pacientes crónicos, les recuerden si toma la medicación, que envíen sus datos de presión o los síntomas que tienen que, o un índice de glucemia, en fin. Y que, de acuerdo a dar respuesta, se le pueda dar una respuesta a dispositivos para medir algunos signos vitales. O sea, sabemos que hay diferentes soluciones que se están evaluando en ese sentido. Análisis diagnósticos de imágenes con inteligencia artificial. Son algunas de las cosas que están surgiendo y también empoderamiento del cuerpo médico o de los usuarios de la operación, que un médico puede tener y monitorear sus diferentes pacientes que están internados o pacientes ambulatorios. Todos son esas, son nuevas soluciones, nuevas demandas que van a surgir, que justamente necesitamos tener una plataforma ágil que pueda soportar todo eso y que pueda soportar también seguir a acompañar al ritmo que nos va demandando la operación. Como puntos, digamos, ya para cerrar, qué, digamos, lecciones aprendidas tenemos de todo este proceso. Y un poco de cómo fue todo el ciclo, ¿no? Primero, tomar la decisión y adoptar la tecnología. Una vez que tomo la decisión, ir para adelante y transmitirle también a la operación, a los diferentes niveles, directivos, medios y operativos, transmitir la seguridad que confíen y abrazar la tecnología y avanzar. No hay otra alternativa y más con todos los, la transformación está. Hay que hacerla, digamos, hay que llevarla adelante. Segundo el tema del Sponsorship, eso también es es clave, es muy, muy importante. En ese sentido, no tengo más que agradecer a la dirección general de MediFest por todo el apoyo, porque sin eso es muy difícil en este contexto que les decía, a veces, donde las operaciones se ven desbordadas y vienen presiones y dudas. Bueno, ¿cuándo va a estar pedidos de fecha que les, en todos proyectos que tenemos? Y siempre nos piden, bueno, ¿y la fecha y cuándo va a estar y cuándo va a estar? Hay veces que no tenemos cómo confirmar una fecha y no podemos dar una falsa, crear una falsa expectativa. En ese sentido, recomendación es ser transparentes y claros y ser simples y directo. Dice, mira, no sé cuándo, no puedo confirmar una fecha cuando va a estar este tema, lo que sí te puedo garantizar que mañana, el mes que viene, vamos a estar mejor. O esto va a estar resuelto. O vamos a entregar esto acá. Y a ir ganando confianza. Pero eso es clave. El sponsor ship es muy importante. Y abrazar, integrar y hacer parte del proceso a las áreas operativas. Ellos se tienen que sentir parte. No son proyectos de tecnología. No pueden ser un proyecto de tecnología. El otro punto, bueno, avanzar de manera mayor, comenzar con algo pequeño. No querer hacer todo. Empecemos bien de abajo. Mi regalo es empezar bien de abajo, chico, ir creciendo. Uno va aprendiendo, digamos, con todo esto. Y también va ganando confianza. Y, bueno, y todo esto, mantener la pasión. Hablábamos hace poco de la alegría de codificar. Bueno, esa pasión hay que mantenerla. Quien soñó muchas veces con alguna solución. Ese fue dormir, que no podía resolver un algoritmo. Y soñó con la solución del algoritmo. Eso tenemos a mantenerlo. Y transmitirlo. No solo mandaron, sino transmitirlo. Quien pasó madrugadas de un día para el otro sin dormir, por estar con un tema de un proyecto, una operación. Eso uno lo hace porque le gusta. No es nadie te obliga a quedarte o quedar y luchar por la solución. Y eso tenemos que transmitirlo y contagiarlo. Y más allá de las áreas de tecnología. La pasión de esto es clave. Abrazar la tecnología y mantener esa llama viva. Eso es fundamental. Y ahí también es un rol nuestro. Bueno, creo que eso es todo. Espero que les haya sido de utilidad.