SCL Artículos CONSULTING. Luis Aguado SCl Consulting CONSULTING

Transcripción

1 SCL Artículos Luis Aguado SCl Consulting

2 Two value releases per year Este concepto es simple: la TI debe ser capaz de liberar 2 nuevas versiones (releases) para las soluciones de negocio al año, basadas en la innovación y que permitan llevara cabo la transformación del negocio. Las condiciones de partida para llevar a cabo esta tarea no son fáciles: IT suele estar fuertemente presionada para implementar nuevos modelos de negocio, y además muchas veces IT e incluso las propias soluciones (SAP y no-sap) son vistos como inhibidores a la innovación. El objetivo de Two value releases per year es acelerar la forma de incorporar la innovación en la compañía, mientras se minimizan los riesgos y se asegura el menor coste total de propiedad (TCO). La propuesta de SAP es utilizar las plataformas SAP Business Suite HANA y SAP Mobile Platform como las palancas para introducir innovación en la compañía pero la pregunta a la que se intenta dar respuesta aquí no es con qué solución o producto, si cómo introducimos esas nuevas releases de forma ágil (2 veces al año) sin interrumpir el funcionamiento normal de las operaciones de negocio: aquí es donde entra ALM y la su plataforma SAP Solution Manager, concretamente planteando una estrategia basada en estos 5 pilares: Gestión de requisitos y releases. Gestión de un landscape dual (línea de mantenimiento / línea de proyecto). Gestión del código propio o código ad-hoc. Ajustar y probar sólo lo necesario. Tiempos de parada cercanos a 0 durante el cut-over. Repasemos cada uno de estos pilares y veamos cómo es posible conseguir el objetivo marcado: Gestión de requisitos y releases IT debe controlar y gestionar los nuevos requisitos necesarios para satisfacer las necesidades del negocio y para ello hay que diferenciar entre dos tipos de cambios y requisitos: 1 Major Releases: Grandes ideas, nuevos proyectos basados en la innovación que permiten llevar a cabo la transformación del negocio, es decir, que cambian los procesos de negocio para adaptarnos a entorno cambiante. 2 Minor Releases: Cambios menores, pequeñas mejoras y correcciones a las soluciones y procesos existentes. Su alcance e impacto es menor, pero requieren una gestión y resolución mucho más ágil. Para las Major releases SAP propone llevar a cabo una gestión de proyectos utilizando por ejemplo ITPPM (IT Portfolio and Project Management), estos proyectos siguen una estrategia de liberar 2 grandes releases al año (en donde sincronizaremos la puesta en marcha y principales hitos de estos proyectos). Synchronized Go Live Synchronized Go Live Project 7 Project 4 Project 11 Project 2 Project 8 Project 9 Project 10 Project 1 Project 6 Release1 1 Release2

3 La gran ventaja de esta estrategia es que se agrupa el esfuerzo tanto de la fase de pruebas de regresión (negocio) como de las operaciones de paradas de mantenimiento (fases de cut-over). Para las Minor releases SAP proporciona IT Service Management en Solution Manager: se trata de una serie de herramientas para la gestión de peticiones de servicio e incidencias (Service Desk), integrada con una estrategia de gestión del cambio (ChaRM - Change Request Management). Major Release Customer release 1 Minor Releases Customer release Months Break Fix 1-4weeks On request 1 Year Gestión de un landscape dual (línea de mantenimiento / línea de proyecto) Para llevar a cabo la anterior estrategia de releases se necesita poder trabajar en paralelo en una línea de proyecto o innovación (major releases), y por otro lado una línea dedicada al mantenimiento (minor releases). La forma óptima de hacer esto es aislar la línea de mantenimiento de la de proyecto de forma física, para ello se introducen el landscape dual con dos tracks: Retrofit Production Support SBX Project Development Este esquema tiene 6 ó 7 sistemas (si queremos además opcionalmente un sandbox ) y permite que el desarrollo de la línea de innovación (upgrade SAP/EhP + desarrollo proyecto ad-hoc) no influya en la línea de mantenimiento que queda exclusivamente para los minor changes (correcciones y pequeñas mejoras). Además, con las herramientas de gestión del cambio de SAP Solution Manager dispondremos de una funcionalidad de control que analiza de forma proactiva los posibles conflictos y problemas que se pueden dar con los diferentes versiones de objetos que se van modificando en ambas líneas. Ventajas del Dual track landscape : Evita downgrades de objetos y conflictos de versionado. Retrofit: de forma automática y semi-automática las modificaciones en objetos de la línea de mantenimiento se reflejan en la línea de proyecto (80% automáticos 20% semi-automáticos). Segregación de tareas. Reduce enormemente el tiempo de la fase de cut-over. Los cambios en la línea de mantenimiento se llevan a cabo de forma mucho más ágil. 2

4 Inconvenientes del Dual track landscape : Mayor número de sistemas implica mayor coste y mantenimiento. Hay un esfuerzo (aunque pequeño) de retrofit. Gestión del código ad-hoc En todo sistema basado en tecnología SAP encontramos lo que llamamos el código Z, es decir, la adaptación de software SAP a unos requisitos de cliente que no pueden ser satisfechos sólo con opciones de configuración. El código Z o código ad-hoc es necesario ya que diferencia a los procesos del cliente de la competencia y cierra los gaps del software de SAP, pero también acarrea los siguientes problemas: Exige un alto grado de mantenimiento (aumento de costes). Es el principal factor bloqueante a la hora de incorporar la innovación SAP (Upgrades y EhPs). Mayor lentitud a la hora de adaptar el software ante un nuevo requisito de negocio (ej. imperativo legal). El objetivo es que el código ad-hoc de una compañía sea el mínimo posible, exclusivamente el necesario que implemente los gaps de la versión actual de la solución SAP. Para esto SAP propone que las compañías definan un modelo basado en ALM aplicado al código ad-hoc, donde se identifiquen todas las fases de su ciclo de vida y se incluyan fases para re-examinar el código y ver si ha quedado obsoleto, optimizarlo o sustituirlo por código estándar. Solution Manager nos da una serie de herramientas que nos ayudarán a esto. CDMC Custom Development Management Cockpit Clear Analysis (CA): análisis del código en función de estadísticas de uso, permite identificar el código que ya no se utiliza y archivarlo o borrarlo. Upgrade/Change Impact Analysis (UCIA): identifica todos los objetos Z que se ven afectados por un upgrade(ampliaciones/modificaciones al estándar, copias de objetos del estándar, utilización y referencias de objetos del estándar). Integración con otros procesos y herramientas en SolMan: documentación, alcance de impacto del cambio, gestión del cambio, etc CCLM Custom Code LifeCycle Management Permite gestionar todo el código ad-hoc manteniendo automáticamente una librería con el estado actual del mismo: clasificación de objetos, documentación, estadísticas de uso, gestión de versiones en diferentes sistemas... Además permite desde aquí lanzar la funcionalidad CDMC, iniciar proyectos de análisis de calidad de código y por supuesto disponer de capacidades de reporting, como por ejemplo la imagen siguiente clasifica el código en 4 dimensiones: calidad, cantidad, criticidad para el negocio y tipo de código ad-hoc (independiente, modificación al estándar, ampliación al estándar ): 3

5 Ajustar y probar sólo lo necesario Como vimos antes, con el landscape dual y la nueva estrategia de mayor releases agrupamos en 2 grandes hitos al año la puesta en marcha de diferentes proyectos. Una de las razones para esto era la de unificar los test de regresión de todos ellos, así aprovechamos que ya estamos probando los procesos para verificar que todo funciona como se espera. Aún siguiendo el esquema anterior, el esfuerzo para llevar a cabo los test de regresión puede ser enorme si se quieren probar todos los casos de uso de todos los procesos, además de que siempre existe el riesgo de no saber si hemos probado todo y se ha escapado de probar algún objeto técnico de los miles que hay por debajo. En primer lugar, válido sobre todo para minor changes, tenemos como principal herramienta el BPCA (Business Process Change Analyzer) que dado un evento de cambio (por ejemplo una orden de transporte) identifica todos los procesos y pasos del proceso que se ven afectados. Es decir, automáticamente dispondremos de las transacciones, jobs, programas, etc en las que puede impactar el cambio y con qué proceso están relacionadas (ya tenemos quién y qué tiene que probar). Esto está muy bien para minor changes, pero claro, ante una major release como por ejemplo un upgrade el resultado del BPCA estándar nos va a indicar que probemos el 90% o más por lo que no es mucha ayuda Fundamentalmente centrado en major releases la solución que nos brinda SAP Solution Manager es el Test Scope Optimization : tiene como requisito que para cada paso del proceso o proceso general tengamos que haber definido casos de test y haber asociado el esfuerzo necesario de aplicarlo. TestScope Optimization identifica el conjunto mínimo de test de regresión que realizar para alcanzar el objetivo que le indiquemos (por ejemplo que todos los objetos técnicos ejecuten al menos una vez). La reducción del esfuerzo de test se reduce en un 60-80% asegurando que todos los objetos ejecutan al menos una vez, y mucho menos aún si nos permitimos el lujo de dejarnos mínimos porcentajes del total de objetos técnicos sin probar. Esto se puede ver en la gráfica siguiente: : Eje X: se representan los pasos de procesos de negocio, y sus casos de test asociados. Eje Y izquierda: % cobertura de los test de regresión (en función del % total de objetos) > A esta escala referencia la línea azul del gráfico. Eje Y derecha: Esfuerzo asociado a los casos de test (en número de horas acumulado) > A esta escala hacen referencia las barras naranjas del gráfico. 4

6 Tiempos de parada cercanos a 0 durante los go-lives Un factor importante que los departamentos de IT deben tener en cuenta y que necesita de la coordinación con negocio es en la gestión de los tiempos de paradas planificadas para las operaciones de mantenimiento. Este tiempo de mantenimiento, durante el cual el sistema no está disponible para operaciones de negocio es denominado Downtime o Business Downtime y podemos separarlo en las siguientes fases: Ramp down phase : Aseguramiento de la consistencia del sistema y BBDD. Se lleva a cabo la parada del sistema productivo de forma controlada (bloqueo usuarios de negocio, parada de jobs, desactivación de interfaces, back-ups, etc ). Technical downtime : Ejecución de las herramientas de mantenimiento. Se lleva a cabo el upgrade del sistema (sistema, BBDD, software, etc ). Post processing phase : Chequeos técnicos y lanzamiento en el sistema de acciones siguientes. Validation : Verificación de que todo el proceso se ha llevado a cabo correctamente. Ramp up phase : Transición de nuevo a la fase de operaciones (liberación usuarios negocio, planificación de jobs ). De vital importancia es que IT y negocio proporcionen y gestionen un plan de cut-over, que deberá disponer de los siguientes elementos: Timeline de cada paso/operación. Lista de puntos de verificación. Back-ups de seguridad en puntos críticos. Lista de personas clave y responsables de cada paso/operación. Plan de contingencia. Proceso para correcciones de emergencia o transportes a producción. Fall-back strategy - Punto de no retorno. SAP proporciona toda una serie de herramientas para minimizar e incluso eliminar el tiempo de Business Downtime. A la hora de planificar dicho Downtime IT ha de tener en cuenta estas 3 preguntas: Cuál es el tiempo de parada aceptable para negocio?: Esto permitirá elegir la herramienta adecuada para llevar a cabo el proceso (que influirá en el coste también). Qué tipo de evento de mantenimiento está planificado (upgrade, EhP, SPS, proyecto código ad-hoc)? Qué sistemas se ven involucrados en la parada (dependencias técnicas y funcionales)? 5

7 Entre las nuevas herramientas de SAP para minimizar o eliminar el tiempo de Downtine destaca ZDM Zero Downtime Maintenande method que consiste en proporcionar un sistema donde las operaciones de negocio siguen operativas mediante se va realizando el upgrade en paralelo. De forma automática se llevará a cabo el traspaso de usuarios y cambios realizados durante la fase de solape. 6 Luis Aguado SCl Consulting

8 Oficinas Centrales Avenida de Europa, 34 B, 2ª Planta Madrid Teléfono: (+34)