✒️La entrada en productivo de la implementación de SAP

La entrada en productivo de la implementación de SAP

La fase de preparación a la salida en productivo

La fase de preparación a la salida en productivo corresponde a las tareas previas que se deben realizar al comienzo de la operación en el entorno real, es decir en el ambiente de producción. Aquí se realizan las pruebas y puesta a punto del nuevo sistema SAP para el comienzo de la operación.

Las tareas a realizar en esta fase son las siguientes:

· Las pruebas

· El transporte de la parametrización y los programas

· La creación de los perfiles de usuario

· La documentación

· Las cargas iniciales de datos

A continuación, vamos a describir cada una de estas tareas en detalle.

Las pruebas

Antes de transportar la parametrización al sistema SAP productivo, es necesario asegurar que los procesos, las interfaces, los programas y las cargas, funcionan de acuerdo a lo requerido. Para ello, se realizan diferentes pruebas en el mandante de testing o pruebas.

Los diferentes tipos de pruebas son las siguientes:

· Pruebas unitarias

· Pruebas integrales

· Pruebas de volumen o de estrés

Entre otros tipos de pruebas más.

A continuación, analicemos los diferentes tipos de pruebas en detalle.

Las pruebas unitarias

Son una forma de comprobar el correcto funcionamiento de una unidad de código. Consisten en aislar una parte del código y comprobar que funciona a la perfección. Son pequeños tests que validan el comportamiento de un objeto y la lógica. Sirven para asegurar que cada unidad funcione correctamente y eficientemente por separado. Además de verificar que el código hace lo que tiene que hacer verificamos que sea correcto el nombre, los nombres y tipos de los parámetros el tipo de lo que se devuelve que, si el estado inicial es válido, entonces el estado final es válido también.

Para que una prueba unitaria tenga la calidad suficiente se deben cumplir con las siguientes características:

· Automatizable: no debería requerirse una intervención manual. Esto es especialmente útil para integración continúa.

· Completas: deben cubrir la mayor cantidad de código.

· Repetibles o Reutilizables: no se deben crear pruebas que sólo pueden ser ejecutadas una sola vez.

· Independientes: la ejecución de una prueba no debe afectar a la ejecución de otra.

· Profesionales: las pruebas deben ser consideradas igual que el código, con la misma profesionalidad, documentación, etc.

Realizar pruebas unitarias proporciona cuatro ventajas básicas:

· Fomentan el cambio: las pruebas unitarias facilitan que el programador cambie el código para mejorar su estructura, puesto que permiten hacer pruebas sobre los cambios y así asegurarse de que los nuevos cambios no han introducido defectos.

· Simplifican la integración: puesto que permiten llegar a la fase de integración con un grado alto de seguridad de que el código está funcionando correctamente. De esta manera se facilitan las pruebas de integración.

· Documentan el código: las propias pruebas son documentación del código, puesto que ahí se puede ver cómo usarlo.

· Los errores están más acotados y son más fáciles de localizar: dado que tenemos pruebas unitarias que pueden desenmascararlos.

Por ejemplo, probamos cual es la salida del programa A cuando introducimos en la pantalla de selección del mismo, una fecha distinta a la fecha del día, que es la que corresponde utilizar.

Las pruebas integrales

Son aquellas que se realizan en el ámbito del desarrollo de software una vez que se han aprobado las pruebas unitarias y lo que prueban es que todos los elementos unitarios que componen el software, funcionan juntos correctamente probándolos en grupo. Se centran principalmente en probar la comunicación entre los componentes y sus comunicaciones ya sea hardware o software. Aquí debe verificarse la integración de los procesos, entre todos los módulos implementadas.

El objetivo de las pruebas de integración es verificar el correcto ensamblaje entre los distintos componentes una vez que han sido probados unitariamente con el fin de comprobar que interactúan correctamente a través de sus interfaces, tanto internas como externas, cubren la funcionalidad establecida y se ajustan a los requisitos no funcionales especificados en las verificaciones correspondientes.

Las pruebas de volumen o estrés

Las pruebas de volumen o estrés corresponden a las pruebas de performance del sistema cuando éste opera con todos sus usuarios conectados. Estas pruebas se utilizan normalmente para romper las aplicaciones. Se va doblando el número de usuarios que se agregan a la aplicación y se ejecuta una prueba de carga hasta que se rompe. Este tipo de pruebas se realiza para determinar la solidez de la aplicación en los momentos de carga, extrema y ayuda a los administradores para determinar si la aplicación rendirá lo suficiente en caso de que carga real supere a la carga esperada.

Las pruebas de volumen o carga tienen como objetivo saber cuánta carga puede soportar un sistema sin empeorar su rendimiento. Estas pruebas sirven para conocer la capacidad máxima de un sistema bajo una carga determinada y poder dar con las causas que puedan condicionar su rendimiento.

Supongamos que hemos construido un puente y tenemos que probar su calidad. Para esto comenzaremos a agregar grupos pequeños de personas cada cierta cantidad de tiempo, indicándoles que realicen una acción como saltar una vez arriba del puente.

Por otro lado, las pruebas de estrés son realizadas sobrecargando un sistema más allá de sus especificaciones, para verificar cómo y cuándo fallará. Dentro de informática podemos colocar una gran carga en la base de datos, entradas (peticiones) continuas al sistema o almacenar información más allá de la capacidad de memoria del sistema.

Siguiendo con el ejemplo anterior esta vez agregaremos un gran grupo de personas en el mismo instante y en un lapso corto de tiempo agregaremos aún más, observando las fallas en mayor medida.

El transporte de la parametrización y los programas

Una vez realizadas todas las pruebas y las correcciones correspondientes, se deben transportar las parametrizaciones y los programas nuevos o modificados al sistema productivo, es decir al ambiente de producción. Para ello, previamente, a medida que se van generando las órdenes de transporte con los cambios a los programas existentes o la creación de nuevos programas, estas son registradas en una planilla de Excel de modo de saber exactamente que vamos a transportar a producción.

Cuando efectivamente se termina de completar la planilla con todos los transportes a realizar entonces se deben liberar las órdenes de transporte a través del sistema de transportes, correspondiente a las transacciones estándar de SAP cuyo código es SE10, SE09 y SE01. Todas estas transacciones corresponden a distintos accesos de la misma herramienta de transporte.

El proceso de transportar esas órdenes de transporte del ambiente de desarrollo al ambiente de producción, es realizado por los administradores SAP BASIS.

La creación de los perfiles de usuario

Los perfiles de usuario contienen las autorizaciones para operar en el nuevo sistema.

Existen muchos elementos que permiten definir las autorizaciones para realizar determinadas actividades en el sistema. Este es un punto crítico, ya que si los usuarios no cuentan con los perfiles adecuados pueden ver bloqueado el acceso a las operaciones que realizan o se les puede dar acceso a operaciones e información que no corresponde a sus funciones. Para la creación de perfiles de usuario debe establecerse una matriz de roles de acuerdo a las funciones que desempeñan los usuarios de la empresa. A cada rol le corresponden autorizaciones para ejecutar algunas tareas.

Luego de crear los perfiles, estos se asocian a los usuarios creados en el sistema.

La realización de la documentación

Como resultado de las diferentes etapas de la implementación, se generan varios documentos que sirven de apoyo al control del proyecto y a la operación posterior.

La documentación más importante es la siguiente:

· Diseño Conceptual. El diseño conceptual registra los procesos a implementar, después del análisis de procesos modelo de referencia del nuevo sistema. Es aprobado al final de la fase de diseño del sistema.

· Manual de Parametrización. En el manual do parametrización se registran los cambios realizados durante la etapa de parametrización sistema. Es fundamental cuando se quieren realizar nuevos cambios.

· Manual de Usuario. El manual de usuario está orientado a los usuarios finales del sistema SAP. Es una guía acabada de la forma de operar cada una de las transacciones funcionales a las que los usuarios deben acceder, en el nuevo sistema. Es importante como soporte a la entrada en productivo.

· Manual de Procedimientos. El manual de procedimientos complementa al manual de usuario. Es una guía de los procedimientos a seguir, fuera del sistema. Tiene llamadas al manual de usuario para indicar acciones a realizar en el sistema.

La principal diferencia entre el manual de usuario y el manual de procedimientos, tiene que ver con que el manual de usuario se utiliza para explicar detalladamente como se usan cada de una de las transacciones del sistema SAP que el usuario debe conocer para realizar sus labores del día a día en la empresa. En cambio, el manual de procedimientos contiene una descripción precisa de cómo deben desarrollarse las actividades de la empresa, es decir, se detallan los procedimientos más importantes, incluye además los puestos o unidades administrativas que intervienen, especificando su responsabilidad y participación. En caso de no funcionar el sistema informático, en el manual de procedimientos se especifican los pasos a seguir para la operatoria manual.

Las cargas iniciales de datos

Cuando se ha transportado la parametrización, el sistema productivo está listo para ser "poblado", es decir, para recibir los datos maestros con los que debe comenzar a operar. Los datos deben haber sido depurados por los usuarios y extraídos desde sus sistemas de origen, a través de archivos o manualmente. La carga inicial de datos es el último paso antes de la entrada en productivo.

Para estos efectos se han construido los programas de Batch Input, que simulan las y transacciones de entrada de datos.

Cuando se instala una aplicación en un ambiente de producción, es necesario dar de alta toda la información que es indispensable para que pueda funcionar, a este proceso lo llamamos carga inicial de datos. Supongamos que necesitamos hacer la carga inicial de datos de 10 mil clientes, para hacer esto, deberíamos ingresar 10 mil veces a la transacción Maestro de Clientes, lo cual sería muy tedioso y muy costoso de tiempo. Algo similar ocurriría si necesitamos ingresar 10 mil registros en una tabla base de datos, ya que si bien, en este caso podríamos crear un programa mediante transacciones SQL y carga en los registros, no estaríamos utilizando todas las variaciones estándar que tiene el sistema SAP por lo que necesitaríamos dedicar mucho tiempo para cubrir ese batch. Para esto SAP introduce la técnica de A Batch Input mediante la cual podremos dar de alta, modificar o borrar, grandes cantidades de datos en el sistema de forma automática y utilizando las mismas transacciones con sus respectivas validaciones tal como si lo hiciéramos manualmente de a un dato por vez.

El soporte y la optimización

Los proyectos de implementación no terminan con la entrada en producción. Hay muchas tareas que continúan después de la entrada en productivo, entre ellas:

Soporte a la operación

Se debe prestar soporte a los usuarios finales del sistema, mediante una mesa de ayuda.

También debe crearse un plan de contingencia para el caso de que la operación con el nuevo sistema no esté disponible. Los principales problemas al momento de comenzar la operación son los siguientes:

· Las autorizaciones de los usuarios para la ejecución de tareas

· El desconocimiento de la operación del sistema

· El desconocimiento de los nuevos procedimientos administrativos

La optimización del sistema

La optimización del sistema es necesaria ya que no todos los escenarios pueden ser completamente probados antes de la entrada en productivo. También surgen nuevos requerimientos de los usuarios cuando el sistema ya se encuentra en productivo. Los factores que más influyen en la estabilización del sistema son los siguientes:

· Las cargas iniciales

· Las pruebas y la preparación del sistema

· La difusión del proyecto y la formación de usuarios