[12/02/2021] Como una de sus primeras tareas cuando se convirtió en CIO la primavera pasada, Kristin Myers examinó su cartera de aplicaciones y adoptó una especie de mantra de "fuera lo viejo, dentro lo nuevo".
Para Myers, vicepresidenta ejecutiva, CIO y decana de tecnología de la información en el Sistema de Salud de Mount Sinai, fue "un gran ejercicio de reducción de costos, porque muchas de estas aplicaciones heredadas siguen existiendo y se sigue pagando el mantenimiento y el soporte del software", señala. Muchas de las aplicaciones de las plataformas que no se actualizan pueden convertirse en riesgos de ciberseguridad, añade.
El departamento de TI inventarió y etiquetó toda la cartera de aplicaciones de Mount Sinai como de retiro, inversión o retirada contenida, lo que significa que los funcionarios no invertirán mucho en una determinada plataforma, y la revisarán anualmente para ver si debe pasar a las categorías de inversión o retiro.
Myers comenzó este trabajo en su anterior cargo de vicepresidenta senior de aplicaciones en el sistema sanitario y lo califica como "un componente clave del programa de cualquier CIO".
El impacto financiero negativo de la pandemia del COVID-19 fue el impulso para ampliar el programa cuando se convirtió en CIO. "Está claro que, con el COVID, todas las instituciones sanitarias han sufrido un impacto muy negativo desde el punto de vista financiero", afirma Myers. "Así que realmente hay que revisar el presupuesto línea por línea para elaborar los de cara al futuro".
También están las implicaciones de la ciberseguridad. Aunque Myers trabaja con su CISO, "finalmente, es mi responsabilidad como CIO y creo que tenemos que minimizar el riesgo en la medida de lo posible".
A finales de este año, TI retirará 59 aplicaciones de un total de 824. Myer afirma que el plan es reducir la cartera de aplicaciones de Mount Sinai en un 38% para finales del 2024. Ha podido ahorrar 6,5 millones de dólares en el presupuesto de este año gracias al retiro de aplicaciones, "que luego compensamos con inversiones en las aplicaciones del estado objetivo".
Cuando se abre la caja de Pandora, no se sabe lo que se puede encontrar. "Uno de los retos cuando inicia uno de estos programas, es que encuentra cada vez más aplicaciones a medida que la gente toma conocimiento del programa", anota Myers, especialmente porque Mount Sinai es tanto un centro médico académico como una institución de investigación.
La racionalización de las aplicaciones va en aumento
Aunque puede ser una tarea desalentadora, muchas organizaciones se han embarcado en programas de racionalización de aplicaciones para reducir los costos operativos al tiempo que mejoran la resistencia, la agilidad y la eficiencia. Evaluar la viabilidad y la necesidad de una aplicación también ayuda a una organización a mantenerse innovadora y competitiva, en una época en la que la aceleración de las transformaciones digitales se ha convertido en la norma.
Según las tendencias tecnológicas de 2021 de Deloitte, "en muchas organizaciones, los sistemas han surgido a lo largo del tiempo para sortear otras limitaciones, dejando cargas de deuda técnica, aplicaciones obsoletas y soluciones provisionales. La transición de los conjuntos de sistemas a la nube puede permitir (o forzar) el proceso largamente esperado de racionalizar los sistemas redundantes, eliminar las dependencias innecesarias y modernizar las capacidades".
Con tantos sistemas básicos que se trasladan a la nube, "la gente se está replanteando las actualizaciones para reducir la deuda técnica", observa Scott Buchholz, director general de Deloitte Consulting y director de investigación de tecnologías emergentes. "La capacidad de moverse rápidamente es cada vez más importante a medida que avanzamos".
No malgaste y nada le faltará
Gary Brantley descubrió mucho "despilfarro" cuando inició un proyecto de racionalización de las aplicaciones después de firmar como CIO de la ciudad de Atlanta. El departamento de TI descubrió muchas redundancias, como cuatro o cinco sistemas de CRM, y dos o tres sistemas de correo electrónico, indica.
"Cuando miramos el porcentaje de uso, puede tener un 26% de uso en esta herramienta y un 36% en otra, y estoy hablando de herramientas que hacen casi lo mismo", sostiene Brantley.
Al igual que Myers, esta fue su primera iniciativa como CIO "porque sabíamos que le podíamos ahorrar millones de dólares a la organización", indica. "Hasta la fecha, la eliminación de herramientas que no necesitamos ha supuesto un ahorro de unos cuatro millones de dólares en toda la ciudad en un periodo de dos años".
Pero Brantley advierte que a veces hay que "tolerar" ciertos sistemas, porque "la hoja de ruta para llegar a las tecnologías innovadoras [lleva] algún tiempo". También lleva mucho tiempo colapsar los sistemas y fusionarlos, añade.
Simon Pearce, CIO de Spirit of Tasmania, que opera transbordadores entre Australia y Tasmania, afirma que su equipo también descubrió un gran número de sistemas duplicados cuando empezó a revisar la cartera de aplicaciones de la empresa hace dos años. Por ejemplo, la empresa contaba con tres sistemas de gestión de turnos, "que en realidad hacían lo mismo. Nuestra opinión fue que necesitábamos una consolidación significativa de nuestras aplicaciones".
En lugar de fijarse en lo que era la aplicación, el departamento de TI revisó los requisitos de la empresa mediante un "proceso bottom-up", sostiene Pearse. "A partir de ahí, hicimos coincidir los requisitos con la aplicación [que] más se ajustaba. Las aplicaciones que ya no eran adecuadas eran retiradas".
Pearce afirma que han reducido su cartera de aplicaciones de unas 140 a 90, y que eso ha supuesto un ahorro de costos en compras, soporte e infraestructura.
Greg Belshe comenzó su programa de racionalización de aplicaciones como parte de una iniciativa de transformación digital de tres años. "Lo primero que hicimos fue crear un catálogo de las aplicaciones. Aunque teníamos información y documentación almacenada en varios lugares, nunca habíamos hecho esto", indica Belshe, director de la división de TI de la Academia Americana de Médicos de Familia (AAFP), que tiene más de 136.700 miembros.
Belshe formó un pequeño equipo que enumeró cada aplicación y alguna información clave sobre cada una, como en qué división se utiliza, las estadísticas de uso y cualquier problema de mantenimiento pendiente, y lo almacenó en su sistema de documentación Atlassian. El departamento de TI terminó con una lista de 90 aplicaciones y sistemas que dividió en diferentes categorías que representaban sistemas desarrollados internamente, sistemas de proveedores que el departamento de TI gestionaba y sistemas de proveedores gestionados por otra persona de la organización. El departamento de TI también enumeró los sitios web a los que daba soporte.
"Nos fijamos el objetivo en el primer año, una vez que tuvimos la lista, de identificar cinco sistemas que podíamos retirar", señala Belshe. "Cumplimos ese objetivo y lo repetimos para el 2020", lo que representa una reducción del 10% de los sistemas que soporta TI, indica.
"Aunque no es una cifra sorprendente, nos está llevando a la tendencia de reducir en lugar de a la de ampliar", indica. El equipo encontró redundancias, como las múltiples herramientas de encuesta que utilizaba la academia. Los funcionarios retiraron una y movieron a todos al mismo sistema.
"También encontramos algunos ejemplos de cosas que no se habían utilizado mucho durante algún tiempo, pero que nadie se había ocupado de retirar", sostiene Belshe. "Así que definitivamente dio algunos frutos de inmediato en términos de quitar algunas aplicaciones de la lista".
Aplicando la regla del 80/20
Al igual que los demás, Anupam Khare, vicepresidente senior y CIO del fabricante de equipos Oshkosh, hizo que el departamento de TI realizara una evaluación metódica de las aplicaciones, y también de su pila de infraestructura. Se elaboró una cartera para cada unidad de negocio, como ventas, ingeniería y fabricación, y luego para una pila de infraestructura, que incluía computadoras, red y almacenamiento.
"En cuanto a las aplicaciones, hicimos evaluaciones funcionales y técnicas" para determinar cuáles son técnicamente débiles y cuáles funcionalmente débiles, anota Khare. El departamento de TI también aplicó la regla del 80/20 para determinar qué 20% de las aplicaciones contribuyen al 80% de la funcionalidad de la empresa.
"Tenemos una cartera de aplicaciones y todas son importantes... pero no todas contribuyen por igual a los resultados del negocio”, afirma.
El departamento de TI también tuvo que decidir si una aplicación era importante para el 2020 y dónde priorizar el gasto en la modernización de las aplicaciones, afirma Khare.
Su equipo descubrió ciertas aplicaciones que debían actualizarse inmediatamente "porque el soporte técnico de un proveedor no estaba disponible o estaba a punto de expirar", señala Khare. Los funcionarios también descubrieron que algunas aplicaciones que se compraron cuando Oshkosh era pequeña "tenían que actualizarse para ajustarse a la escala y complejidad del negocio".
¿Se queda o se va?
Algunas de las aplicaciones que la AAFP catalogó para ser eliminadas eran clarísimas, "pero a medida que el proceso continuó, fue cuando hubo que elaborar un mejor conjunto de criterios sobre cómo gestionar y asegurarnos de que teníamos el conjunto correcto de aplicaciones", señala Belshe.
Hay un arquitecto de aplicaciones en el equipo que se encarga de decidir si tienen la aplicación adecuada en un área concreta, y qué cambios debería hacer el departamento de TI para apoyar mejor a la empresa.
"Él es quien realmente toma las decisiones difíciles sobre lo que es bueno para el negocio o si hay aplicaciones que podrían aportar más valor al negocio", señala Belshe. "Se refiere a eso como 'techscaping' y a cuidar nuestro jardín de aplicaciones. Al igual que en un jardín, cuando uno quiere añadir cosas nuevas tiene que hacer espacio".
Para la academia era importante centrarse más en el aspecto del retorno de la inversión (ROI) que, en el pasado, indica Belshe. "Hay que ser muy disciplinado a la hora de poner en marcha una aplicación y capturar el ROI y los procesos para su seguimiento en el futuro". Esto incluye determinar si la inversión dio sus frutos de la forma en que TI pensó que lo haría y por qué, anota. Otra consideración es: "¿Tenemos el sistema equivocado o hay otras cuestiones en juego?".
Myers afirma que el objetivo de Mount Sinai es conseguir que las consultas sanitarias que adquiera se estandaricen en su plataforma de historia clínica electrónica Epic. En el 2021, el departamento de TI retirará aproximadamente 19 aplicaciones solo con la implementación de Epic, señala.
Para determinar lo que debe permanecer y lo que debe desaparecer cuando el hospital realiza una adquisición, el departamento de TI examina métricas como el número de usuarios que hay en un sistema, para qué lo utilizan y qué ubicaciones de este usan. "A veces encontramos una aplicación que tiene 10 usuarios en un sitio frente a otros seis sitios que utilizan una aplicación similar", explica Myers. "Entonces tenemos que involucrar a la comunidad de usuarios, porque no es algo que se pueda desconectar inmediatamente. Se trata de una discusión en torno a que 'El sistema sanitario quiere un enfoque estandarizado de las aplicaciones'".
Dice que una vez que el departamento de TI explica las razones para utilizar una aplicación concreta, la mayoría de sus stakeholders entienden las ventajas, especialmente el ahorro de costos. "A veces lleva más tiempo que otras discusiones que tenemos", señala, "pero creo que la clave es asegurar que nuestra comunidad de usuarios finales esté obteniendo lo que necesita".
El proceso de racionalización de las aplicaciones en la actualidad
Mount Sinai cuenta con un grupo directivo de aplicaciones que revisa la funcionalidad de una aplicación, y si el sistema sanitario ya tiene algo en su cartera que se ajuste a la misma necesidad. "Todos los responsables de la infraestructura y los propietarios de las aplicaciones se reúnen una vez a la semana y revisan todas las aplicaciones que se están considerando y el costo, no solo del software, sino de su mantenimiento", explica Myers.
Dado que el objetivo es trasladar el mayor número posible de aplicaciones a la nube, el grupo directivo también examina el caso de negocio de una aplicación, y si tiene funcionalidad en la nube en lugar de continuar con las instalaciones locales, dice.
"Revisamos todo eso y muchas veces pedimos más información sobre el caso de negocio y si se alinea en general con la estrategia tecnológica", indica Myers. "Este año ha sido menos en cuanto a nuevas aplicaciones, pero es un proceso que tiene sentido. No está ahí para ser una barrera, sino para facilitar que nos aseguremos de que estamos pensando en nuestra estrategia tecnológica".
El arquitecto de aplicaciones de Belshe es el responsable último de decidir si la academia debe adquirir una nueva aplicación mediante un "proceso de puertas de etapa", afirma. Cuando la academia se embarca en nuevos proyectos, "tenemos varias puertas de etapa, en las que un equipo puede hacer las preguntas, y asegurarse de que hemos mirado el ROI y capturado eso y otras cosas de la lista de control".
Khare dice que la estrategia de Oshkosh no es reducir su cartera de aplicaciones. "Nuestra estrategia es tener la cartera adecuada para permitir las funciones empresariales. Eso significa que, si tenemos más aplicaciones, no hay problema".
Como OshKosh ha adoptado una estrategia en la nube, "encontramos proveedores especializados con funcionalidades específicas en la nube". Los funcionarios también buscan "la capacidad de conectar un sistema con otro para que los datos fluyan", anota.
Consejos para la racionalización de las aplicaciones
Una vez que una organización decide iniciar un programa de racionalización de aplicaciones, hay algunos enfoques que el departamento de TI debe adoptar para garantizar que se ejecute sin problemas.
"Invierta continuamente en la hoja de ruta de su cartera de aplicaciones empresariales", aconseja Pearce, de Spirit of Tasmania. "Asegúrese de que entiende exactamente lo que tiene y cuál es el impacto en su negocio. Permitir que las aplicaciones se multipliquen aumentará no solo los costos de sus aplicaciones, sino también los de infraestructura y soporte asociados".
Es importante empezar por hacer un inventario de lo que se tiene y asegurarse de que está clasificado correctamente, señala Myers, de Mount Sinai. "Entender realmente hacia dónde se mueve su estrategia tecnológica desde la perspectiva de la nube y del estado objetivo, y establecer un proceso de gobernanza con un grupo directivo de aplicaciones y colaborar con la comunidad y los stakeholders del negocio".
Tienen que entender el proceso y sentirse comprometidos con él, y con que la racionalización de las aplicaciones sea un facilitador y no un impedimento, subraya.
Dado que se trata de algo que el departamento de TI no está haciendo en respuesta a una solicitud o necesidad específica, ayuda tener una persona de contacto, anota Belshe de la AAFP. "Eso garantiza que reciba una atención continua".
Asimismo, añade que "hay que seguir comunicando que el tiempo que usted dedica a hacer esto dará sus frutos asegurando que tenga las aplicaciones adecuadas que aporten el máximo valor, y que [el departamento de TI] no está malgastando el tiempo en cosas que no están rindiendo como deberían".
Khare, de Oshkosh, afirma que esto no debe enmarcarse como una agenda de TI. "Hay que entrar con una mente abierta y centrarse en el resultado del negocio cuando se piensa en la racionalización y modernización de las aplicaciones".
Además, la medición de los beneficios no debe ser en términos de cuánto reduce los costos la TI, señala, "sino del impacto en el negocio o en los ingresos operativos que ha creado".
Basado en el artículo de James Esther Shein, CIO y editado por CIO Perú