Asegurando el valor de las aplicaciones para el negocio PERSPECTIVA. j u n i o

Transcripción

1 GESTIÓN DE CARTERA DE APLICACIONES APM Asegurando el valor de las aplicaciones para el negocio Por Vanesa Cabral, Raúl Jaraba, Miguel Katz y Cristian Martínez, Practia Consulting España La crisis que comenzó en 2008 ha hecho que el sector financiero en particular haya tenido que responder tomando acciones decididas, como las fusiones de bancos y cajas de ahorro en España con el fin de alcanzar volumen suficiente y mejorar sus parámetros de negocio. Una fusión de empresas de estas características plantea para el área de Sistemas un reto en cuanto a la duplicación de las aplicaciones de las diferentes entidades: debe decidirse cuáles conviene mantener y cuáles habrá que fusionar, integrar o eliminar. Esta misma situación se repite en otros escenarios, como la reorganización de una unidad de negocio por compra o la segregación (spin off) de organizaciones. Las preguntas que se reiteran son: Existe un método racional que permita evaluar de manera homogénea el conjunto de aplicaciones? Cómo decidir, utilizando criterios homogéneos, qué aplicaciones mantener y cuáles no? A nivel empresarial, la respuesta a estos interrogantes tiene formato de sigla: es APM (Application Portfolio Management), es decir, la gestión de la cartera de aplicaciones. La toma de decisiones en relación a qué acciones tener en cuenta para cada aplicación analizada se basa en el análisis de indicadores, informes y riesgos. 23

2 REGIÓN QUÉ ES? QUÉ ENTEN- DEMOS POR APLICACIÓN? QUÉ CARAC- TERIZA A UNA APLICACIÓN? 24 APM o gestión de la cartera de aplicaciones se define como el conjunto de procesos y métodos que permiten conocer el valor y los costes y riesgos para el negocio de las aplicaciones utilizadas por nuestra organización. Si tenemos en cuenta que las organizaciones gastan un 70% del presupuesto de TI en el mantenimiento de software, el análisis de la cartera de aplicaciones nos ofrecerá un conjunto de acciones posibles para reconvertir parte del presupuesto de mantenimiento en inversión. Por sorprendente rend ente que parezca, uno de los primeros desafíos con los que nos encontramos al implantar una práctica APM, es saber a qué nos referimos cuando decimos aplicación. Si pensamos en los diferentes actores que interactúan con el software aplicativo tenemos dos grandes equipos: por un lado el de desarrollo, que ve las aplicaciones como código fuente, por otro, el de operaciones, que da soporte, como código que se ejecuta sobre la infraestructura. Además, desde la perspectiva de los usuarios, una aplicación es un conjunto de funcionalidades y procesos de negocio soportados. Parece que todos entendemos lo mismo. Sin embargo hay más que preguntar para encontrar visiones contradictorias. Qué se debe hacer? Aunque parezca difícil de seguir, se debe adoptar una definición y comenzar a trabajar. La madurez de la práctica permitirá reconciliar las diferentes visiones y obtener un análisis completo. Tanto la recolección de datos de las aplicaciones como el mantenimiento deben ser claramente definidos e insertados en los procesos de la organización TI. Toda nueva aplicación debe ser incorporada en el inventario, así como cualquier modificación sobre las aplicaciones debe generar una actualización en el mismo. En un proceso de APM, el esfuerzo para la recolección de datos, la exactitud y homogeneidad de la información son temas de vital importancia. Por eso el equipo de trabajo debe hacer su mayor esfuerzo por lograr automatizar la recolección y conseguir que los atributos que definen cada aplicación sean totalmente objetivos. Los datos de las aplicaciones deben recoger las diferentes visiones, es decir, las áreas de desarrollo, de operaciones, de arquitectura y de negocio, como así también los costes involucrados en todo el ciclo de vida. La dificultad para obtener los datos puede variar entre unos y otros. De todos modos no debe olvidarse que el objetivo es disponer de información completa sobre las aplicaciones para poder tomar las POR DÓNDE EMPEZAR? Para comenzar hay que generar un catálogo de nes. Luego se evalúan y anali- aplicaciozan con el objetivo de obtener propuestas de acción. Estas acciones podrán ser: tolerar, integrar, migrar o eliminar. A diferencia de otras mejoras en los procesos de TI que pueden ser mejores decisiones. La figura 1 muestra de manera simplificada una serie de datos de las aplicaciones agrupados en cuatro grandes bloques: datos generales, datos de valor para el negocio, datos de calidad técnica y datos de costes. A la hora de seleccionar los datos de las aplicaciones se debe prestar especial atención al mecanismo de recolección de datos. Identificar las fuentes de alimentación del APM de manera automática colaborará significativamente, ya que minimiza el esfuerzo necesario para mantener actualizado el inventario. Es probable que en las fases iniciales los datos se recolecten de manera manual, pero es de esperar que sea posible identificar mecanismos que automaticen este proceso. aplicadas desde un principio de manera completa, la práctica APM necesita ser ejecutada numerosas veces para poder robustecerse en cada paso. En resumen, el primer paso es disponer del inventario y generar un primer análisis de un subconjunto de aplicaciones.

3 QUIÉN ES EL MEJOR RES- PONSABLE? (FIGURA 1) RAMAS O DISCIPLINAS RELACIONADAS MANTENIMIENTO OPERACIÓN PROPENSIÓN A FALLOS CALIDAD DE CÓDIGO CONSTRUCCIÓN S CALIDAD TÉCNICA OBSOLESCENCIA TÉCNICA GENERALES APLICACIÓN NOMBRE VALOR PARA EL NEGOCIO SATISFACCIÓN DE USUARIO RESPONSABLE CRITICIDAD DE PROCESO UNIDAD DE NEGOCIO COBERTURA DE PROCESO Si bien la práctica APM es llevada a cabo de una manera más o menos formal en algunas organizaciones para preparar el presupuesto de mantenimiento o reducir costes, en esos casos se trabaja con una visión parcial de la aplicación, y hay mayores beneficios que pueden obtenerse gracias a una perspectiva más corporativa de la cartera de aplicaciones. En la práctica ca nos encontramos con situaciones muy diversas en la manera de implantar APM en las organizaciones. En algunos casos esta responsabilidad es otorgada a la Oficina de Proyectos, en otras al área de Arquitectura, y finalmente a áreas de Desarrollo de Aplicaciones. Cada organización deberá determinar el lugar más adecuado de acuerdo con su cultura y el ajuste con los demás procesos de TI. No obstante, se podrá comenzar otorgando a un área la responsabilidad y, a medida que la organización madure con respecto a esta práctica, podrá transferirse a otro sector. Como veremos, es fundamental que disponga de una visión global y completa del área de Sistemas de Información a fin de maximizar el beneficio de la perspectiva integrada de la cartera de aplicaciones. A continuación enumeramos las responsabilidades de la práctica APM: aplicaciones. inventario. áreas las acciones más adecuadas para la actualización del inventario de aplicaciones, tomando como base las acciones propuestas por el análisis APM. las iniciativas surgidas del análisis realizado. miento de la práctica APM. Es fundamental que el responsable de APM reciba la autoridad suficiente para que sea capaz de impulsar las acciones que se acuerden con las diferentes áreas de Sistemas de Información y con el Negocio. Los niveles más altos de la organización de TI deberán respaldar las acciones de APM. En definitiva, tomar elecciones es un proceso que se puede perfeccionar. Como en el día a día de una persona, lo que hay que saber es que, inevitablemente, al abrir una nueva puerta se cierra otra. Lo importante es ser conscientes de las alternativas mediante de la búsqueda de la más adecuada según contexto, tiempo y lugar. Ya sea el primer hogar de una familia o el software que mejor se adapte a las necesidades de la empresa, saber elegir es todo un arte. 25

4 REGIÓN APM LOS 4 PILARES DE NUESTRA METODOLOGÍA 2 ANALIZAR LAS APLICACIONES LA METODOLOGÍA APM DESARROLLADA POR PRACTIA ESPAÑA SE APOYA EN LAS BUENAS PRÁCTICAS DE MERCADO Y EN LA EXPERIENCIA RECOGIDA EN LOS PROYECTOS. Dependiendo de la cantidad de aplicaciones de la organización es posible analizar el catálogo completo, o bien un subconjunto definido de acuerdo a prioridades puntuales. En este sentido es necesario aplicar uno o varios focos de interés seleccionando aquellas aplicaciones de mayor prioridad para la organización. En el caso de que se unifiquen procesos se hará foco en aquellas aplicaciones que cubran los procesos abarcados por la reingeniería y sólo esas serán analizadas. Por otro lado, si la intención es analizar aplicaciones provenientes de una fusión de organizaciones, como comentábamos al principio, se tomarán en cuenta las funcionalidades cubiertas por ambas organizaciones. Los criterios para definir los focos y aplicarlos podrán variar entonces según las necesidades de cada organización. La toma de decisiones, en relación a qué acciones tener en cuenta para cada aplicación analizada, se basa en el análisis de indicadores, informes y riesgos. Los indicadores son un elemento clave tanto para el análisis de las aplicaciones y su clasificación posterior como para poder obtener información relevante que sirva de ayuda en la toma de decisiones tras el análisis de las mismas. 1 DEFINIR Y MANTENER UN INVENTARIO DE APLICACIONES 26 La mayoría de las organizaciones disponen de catálogos de aplicaciones, muchos de ellos departamentales y parcialmente actualizados. Con el paso de los años se han generado con un propósito definido por el área y con la visión parcial del objetivo perseguido. La práctica APM va un paso más allá: busca unificar los catálogos departamentales para disponer en un único repositorio con una visión completa de las aplicaciones. La actualización es una necesidad que se deberá definir en función de los recursos de la empresa y la periodicidad que se establezca para ejecutar la práctica APM.

5 APM posee dos características: es iterativa e incremental. Iterativa porque se realiza con una periodicidad establecida e incremental porque en cada iteración se incorporan más aplicaciones o se realiza un análisis más profundo. CUADRANTE DE APM Ubicación de las aplicaciones de una empresa medida según su alineamiento técnico y su valor aportado al negocio. MIGRAR INTEGRAR 3 DETERMINAR LAS ACCIONES MÁS ADECUADAS JUNTO A LAS ÁREAS DE SISTEMAS DE INFORMACIÓN PELIGRO MEDIO RIESGO TÉCNICO ALTO ELIMINAR SIN RIESGO MANTENER ALINEAMIENTO TÉCNICO RIESGO TÉCNICO Y FUNCIONAL ALTO VALOR PARA EL NEGOCIO PELIGRO MEDIO RIESGO FUNCIONAL ALTO Determinar las acciones más adecuadas junto a las áreas de Sistemas de Información. El análisis APM provee de una herramienta para apoyar la toma de decisiones. El análisis proporcionará acciones recomendadas para cada cuadrante que deberán ser estudiadas en profundidad, teniendo en cuenta la información de contexto y de negocio que convalide la viabilidad de la acción propuesta. que co ón propuesta 4 COORDINAR CON LA GESTIÓN DE LA CARTERA DE PROYECTOS (PPM) LAS NUEVAS INICIATIVAS A EMPRENDER PARA LAS APLICACIONES Las acciones acordadas con las diferentes áreas y el Negocio se convertirán en iniciativas que formarán parte de la Cartera de Proyectos. Las aplicaciones se distribuyen en cuatro cuadrantes según la calidad técnica y su alineamiento estratégico con las necesidades del negocio. Para obtener el primero se emplea un subconjunto de atributos que evalúan la calidad desde el punto de vista de desarrollo, obsolescencia técnica, falta de alineamiento con la arquitectura de referencia, productos con riesgo técnico por falta de soporte u otros problemas provenientes de la infraestructura técnica. Desde la perspectiva del indicador de valor de negocio se emplea un conjunto de atributos que tienen en cuenta la obsolescencia funcional, satisfacción del usuario, criticidad de procesos y otros atributos relativos a la funcionalidad y el uso. 27