Escenarios de configuración

Cualquier entorno de software de gestión empresarial presenta la necesidad de tener sistemas completos (hardware y software) separados dedicados a funciones específicas. Entre estas funciones podemos destacar el desarrollo del software, las pruebas del mismo, la formación a los usuarios finales y, la más importante de todas, la puesta en producción del software. SAP R/3 dispone de múltiples alternativas de configuración de escenarios.

Cada empresa deberá decidir, según los criterios que veremos posteriormente, cual es la que mejor se ajusta a sus necesidades. Esta decisión, debido al carácter abierto y escalable de R/3, puede alterarse en cualquier momento si se aprecia que los condicionantes de la empresa que llevaron a optar por una solución determinada han cambiado.

Consideraciones generales sobre los sistemas R/3

Siguiendo la definición de sistema R/3 que se da en el glosario, vamos a indicar una serie de requerimientos y limitaciones que existen, y que deben tenerse en cuenta a la hora de decidir el número de sistemas necesarios para una implantación real.

La base de datos de un sistema R/3 requiere aproximadamente unos 15 Gb (en la versión 4.0B) de disco duro y cada servidor de aplicaciones necesitará unos 2 Gb. Un mandante que contenga únicamente la parametrización básica ocupa unos 500 Mb, pero si le añadimos los datos de aplicación que se van creando al entrar en productivo, los requerimientos de almacenamiento puede incrementarse hasta varios gigabytes. Otros factores que influyen en la necesidad de espacio son el sistema de base de datos elegido, el número de mandantes creados, la cantidad de datos históricos que se guardan. . . R/3 no provee de ninguna herramienta para separar los datos maestros de los datos transaccionales. No podemos transportar únicamente los datos maestros de proveedores sin pasar también los datos de sus pedidos y/o facturas. Del mismo modo, tampoco podemos separar los datos de módulos diferentes, una aplicación individual como FI o HR no puede aislarse para transportarse a otros sistemas.

Por otro lado, sí que disponemos de herramientas para reinicializar los datos transaccionales antes de la entrada en productivo 2 lo que nos permite borrar toda la contabilidad, pedidos, facturas, órdenes de mantenimiento, etc, que se hayan creado durante las pruebas.

Descripción y funciones de cada sistema

Atendiendo únicamente a la función que van a cumplir, hay varios tipos de sistemas R/3. Vamos a describir los tres más habituales (desarrollo, integración y producción) aunque dependiendo del tamaño y necesidades de la empresa SAP también contempla la posibilidad de tener un sistema de formación aislado y un sistema de desarrollo de cliente propio.

Sistema de desarrollo

Este es el sistema inicial donde se origina el software. Todos los desarrollos y la parametrización se llevan a cabo aquí. Una vez que se han completado las pruebas unitarias de los programas, estos pueden ser transportados al sistema de integración para hacer pruebas más exhaustivas. Los datos de este sistema suelen ser escasos (únicamente los que se van creando como pruebas) y a veces son inconsistentes. Debido al gran número de personas (muchas veces ajenas a la empresa) que acceden a este sistema debemos controlar, por motivos de seguridad, que nunca tenga datos reales.

Sistema de integración

En este sistema se realizan pruebas definitivas del software que incluyen:

Pruebas integradas Con ellas nos aseguramos que nuestros desarrollos no interfieren en otros módulos del sistema. También debemos probar conjuntamente desarrollos de distintos módulos que interactúen entre sí. (“Go Live”es el término inglés que se utiliza para referirse al momento en que el sistema productivo se abre a los usuarios finales para que comienzen a trabajar).

Pruebas de rendimiento Cargando el sistema de integración con suficiente volumen de datos podemos probar la eficiencia de nuestro software permitiéndonos descubrir errores no funcionales pero que nos imposibilitan poner en explotación los programas.

Pruebas de usuario El usuario final no suele tener acceso al sistema de desarrollo así que es en integración donde debe comprobar que la funcionalidad del software es la que él pidió en sus especificaciones. También le sirve para familiarizarse con los nuevos programas y su

interface y solicitar cambios en la interacción si algo no es de su agrado. La formación a usuarios es otra de las funciones de este sistema. Aprovechando la necesidad de volumen de datos que tienen las pruebas de rendimiento, podemos enseñar a los usuarios con ejemplos casi reales como funciona el software que van a tener que utilizar.

Por último, destacaremos como función importante la posibilidad de probar el sistema de transporte. Al pasar el software de desarrollo a integración ya tenemos una prueba de como va a pasar de integración a producción. Veremos el sistema de transporte detalladamente en capítulos posteriores.

Sistema de producción

El sistema de producción tiene una única función: la explotación real del software. Aquí es donde se almacenan los datos reales de la empresa y donde se ejecutan los procesos de negocio. Los otros sistemas deben garantizar que los programas o parametrizaciones incorrectas no afecten ni al trabajo productivo ni a los datos reales.

Mandantes

Mandantes estándar

Cualquier sistema R/3 se instala inicialmente con tres mandantes estándar. En el caso de un sistema IDES existe también el mandante 800 que incluye un modelo de compañía completo para demostraciones y formación.

Las funciones de los mandantes estándar son las siguientes:

Mandante 000 Es el mandante de referencia. No contiene datos de parametrización empresarial y por lo tanto las creaciones de mandante propios se deben hacer como copias de este para asegurarnos que empezamos la parametrización desde cero. Durante un cambio de versión de R/3 los datos dependientes de mandante se actualizan automáticamente en el 000 y los cambios al resto de mandantes se deben hacer desde aquí. En el IMG se incluyen unos proyectos que destacan los cambios entre diferentes versiones de SAP R/3 y que sirven de ayuda después del upgrade. Este mandante no debe borrarse del sistema ni cambiarse ningún aspecto de él.

Mandante 001 Es el mandante de ejemplo. Inicialmente es idéntico al 000 y salvo que lo cambiemos nosotros, ninguna actualización de R/3 lo va a modificar, al contrario de lo que ocurre con el 000. Siempre lo podemos tener como ejemplo de la instalación inicial aunque SAP no impone ninguna prohibición de cambiarlo o borrarlo.

Mandante 066 Mandante del servicio EarlyWatch. Para garantizar la confidencialidad de nuestros datos reales en productivo existe este mandante aislado al que se conecta SAP cuando le pedimos que nos realice un servicio de detección de problemas de rendimiento. Los usuarios de este mandante tiene las autorizaciones mínimas para poder ejecutar el informe de rendimiento. Este mandante tampoco debe ser borrado ni modificado nunca.

Mandantes propios

A partir del mandante de referencia 000 podemos crear tantos mandantes como queramos (siempre que el tamaño de nuestra base de datos nos lo permita). En el sistema de desarrollo se suelen crear varios mandantes, en integración alguno menos y en el sistema de producción solo debe existir un mandante propio. A continuación vamos a describir los mandantes que se crean habitualmente y cuales son sus funciones. Aunque vemos que tienen un número asignado, esto se ha hecho para facilitar la diferenciación entre ellos.

En nuestros sistemas R/3 nosotros podemos darle el número que queramos a cada mandante propio. Es posible implementar SAP con más o menos mandantes de los indicados pero hay que buscar el equilibrio entre muchos y pocos. Con pocos mandantes podemos tener conflictos durante la parametrización, el desarrollo de programas o las pruebas, pero con muchos mandantes estaremos aumentando el tamaño de la base de datos y empeorando el rendimiento además de requerir un mayor esfuerzo en los procedimientos de administración

de sistemas. Las funciones de los mandantes propios son las siguientes:

Mandante 200 Desarrollo y parametrización en el sistema de desarrollo. Aquí iniciamos nuestro prototipo de empresa y creamos los primeros desarrollos a medida que sean necesarios. Los programadores y consultores de aplicación trabajan en este sistema. No tendremos datos maestros ni transaccionales de manera que la pruebas las realizaremos en el mandante 220 después de pasar todos los cambios hechos aquí.

Mandante 210 Trastero. Las pruebas inusuales de parametrización las realizaremos en el 210 de manera que no interrumpamos el trabajo normal del mandante 200. Los cambios que hagamos aquí no se registran en ningún sitio de manera que si probamos algo que nos va bien debemos repetirlo a mano en el 200 para que quede grabado en una orden de transporte y se pueda pasar al mandante de pruebas unitarias. Periódicamente y para mantener el mandante limpio se hará una copia de refresco desde el 220.

Mandante 220 Pruebas unitarias en desarrollo. Los responsables de desarrollo y parametrización efectuarán aquí las pruebas unitarias del prototipo que se está creando. Aquí si que tendremos datos maestros y transaccionales aunque no serán muy fiables debido a que la parametrización puede cambiarse.

Mandante 300 Pruebas integradas y control de calidad en integración. La función de este mandante es similar a la del 220 pero con la diferencia de que las pruebas incluyen la interacción entre los diferentes módulos, rendimiento y aprobación del usuario. También se comprueba que el paso de las órdenes de transporte desde el sistema de desarrollo sea correcto como garantía de que el paso de esas mismas órdenes a producción también lo sea.

Mandante 310 Formación a usuarios finales. Una vez superadas las pruebas correspondientes al mandante 300, pasamos el prototipo aquí para que los usuarios finales reciban los cursos de formación y tengan un sitio donde poder seguir practicando después. De esta manera, los datos maestros y transaccionales que crean no nos interfieren en nuestro trabajo de implantación habitual. (La palabra que utiliza SAP es ”sandbox” que es una caja de arena en la que juegan los niños. El término ha sido libremente traducido al castellano por los autores)

Mandante 320 Maestro de parametrización. Este mandante se usa únicamente como referencia para poder consultar la parametrización que tenemos en productivo sin tener que acceder a la maquina de productivo, no obligándonos a dar acceso a la misma a personal no autorizado. Para que cumpla su función se deben transportar los cambios al mandante 400 y al 320 al mismo tiempo y mantenerlos siempre sincronizados.

Mandante 400 Mandante productivo. Aquí es donde se lleva a cabo la explotación real del software. Este es el único mandante propio que debe existir en el sistema productivo. Antes del arranque en productivo realizaremos aquí las cargas iniciales de datos maestros, movimientos e históricos.

Comparación de escenarios

SAP tiene contemplados escenarios de configuración desde un sólo sistema hasta cuatro. El escenario que aconseja en todas sus especificaciones técnicas es el de tres sistemas aunque también es aceptable trabajar con dos (si las necesidades de la empresa no son muy grandes). Trabajar con un solo sistema R/3 es un caso excepcional como veremos más adelante. Vamos a ver esquemáticamente las ventajas y desventajas de cada una las configuraciones.

Configuración con un sólo sistema (Producción)

Ventajas

Al tener una sola máquina los costes de hardware son mínimos. Todo el trabajo del transporte de elementos de desarrollo queda suprimido con lo que la administración del sistema se simplifica en cierto modo.

Desventajas

Tendremos problemas con las tablas independientes de mandante. Problemas durante la instalación y pruebas de los parches. Tendremos dificultades para crear nuevos desarrollos y tendremos que provocar la indisponibilidad del sistema para realizar las pruebas integradas.

El rendimiento de nuestra única máquina será malo ya que tendremos todos los mandantes en la misma base de datos con el aumento de tamaño de las tablas que ello implica.

Conclusión

SAP desaconseja totalmente esta configuración. Algunos clientes se decantan por ella alegando que no van a desarrollar nada de software nuevo y que tampoco van a parametrizar mucho con lo que un sistema R/3 básico les sirve para empezar a trabajar. La realidad demuestra más tarde que hacer esto significa infrautilizar el potencial de adaptabilidad y crecimiento que tiene SAP y en poco tiempo instalan un segundo sistema que les permite hacer cosas que antes no podían. La reducción inicial de costes en hardware también resulta engañosa porque en el presupuesto de un proyecto de implantación de R/3 el coste del hardware representa un porcentaje bastante pequeño del total. Lo que ocurre es que es uno de los primeros gastos en el que hay que incurrir y por eso da la impresión de que es importante reducirlo al mínimo. Únicamente se aconseja esta configuración para centros de formación o demostración del producto.

Configuración con dos sistemas (Desarrollo y Producción)

Ventajas

Todos los desarrollos nuevos y la parametrización creada se puede probar en el sistema de desarrollo sin interferir con el trabajo real en productivo. Tenemos los datos reales de nuestro sistema productivo aislados en una máquina a la que no puede acceder el personal de desarrollo, de esta manera garantizamos la confidencialidad de nuestra información. Este punto puede ser en algunos caso vital, estratégicamente hablando, o incluso de obligado cumplimiento legal, en el caso de la información relativa a empleados, clientes y proveedores. La inversión en hardware es reducida. El sistema de desarrollo puede ser una máquina de características inferiores a la de productivo y estaremos ajustando bastante nuestro presupuesto.

Desventajas

La cantidad y el ámbito de actuación de los desarrollos que hagan estará limitado por la falta de un sistema dedicado a las pruebas integradas. Tendremos que hacer el control de calidad y las pruebas de aceptación de usuario en el mismo sistema en el que desarrollamos lo que puede implicar la interrupción de las tareas de desarrollo durante el tiempo que duren las mismas. Tampoco podremos llevar a cabo pruebas de rendimiento sin perjudicar a los equipos de desarrollo o al funcionamiento en productivo. Tareas ineludibles y de gran complejidad como un cambio de versión nos dejan inservible el sistema de desarrollo durante todo el tiempo que dura la actualización de versión.

Conclusión

Esta es la solución mínima que acepta SAP para una empresa que pretenda sacar rentabilidad de R/3. Es una opción correcta para empresas con un pequeño número de desarrollos y que implanta sólo uno o dos módulos lo que reduce la cantidad de parametrización a realizar. A medida que la empresa vaya instalando más módulos de R/3 o que vaya asimilando el Workbench ABAP/4 como paquete de desarrollo es posible que se vea en la necesidad de añadir un tercer sistema. En cualquier caso, es muy común ver empresas que tienen esta configuración desde hace varios años y funcionan correctamente con ella. En el caso de un cambio de versión, que es uno de los proyectos complicados que requieren una máquina aparte, la solución por la que se opta consiste en alquilar durante el tiempo de la actualización de versión una máquina de pruebas o subcontratar la migración a una consultoría externa que tenga máquinas disponibles para ello.

Configuración con tres sistemas (Desarrollo, Integración y Producción)

Ventajas

La instalación de aplicaciones o módulos adicionales se puede hacer sin afectar al trabajo habitual de desarrollo. La existencia del mandante trastero en el sistema de desarrollo facilita la familiarización con las funcionalidades de los módulos y la realización de pruebas sin peligro. Disponemos del sistema de integración para la realización de pruebas de rendimiento, pruebas de aceptación de usuario, formación a usuarios. . . Tres es el número mínimo de sistemas que hacen falta para poder probar el sistema de transporte. Al tener integración como paso intermedio antes de llevar el software a productivo podemos y hacer este paso utilizando el sistema de transporte, podemos garantizar que el transporte a productivo va a ser correcto siempre que haya sido correcto el paso a integración. La importancia de esta prueba radica en que puede resultar frustrante haber pasado todo el ciclo de pruebas de un desarrollo y que al final falle en producción por una mala gestión del sistema de transporte.

Desventajas

Necesitamos una inversión mayor en hardware, tanto en máquinas para albergar los sistemas R/3 como en hardware auxiliar de comunicaciones, copias de respaldo, administración de red. . . La administración del sistema se complica y por lo tanto necesitaremos más personal y que además esté bien formado en estas tareas. Este punto es realmente importante porque si no somos cuidadosos en la gestión de los transportes de workbench y customizing a través de los tres sistemas podemos llegar a anular alguna de las ventajas que supone tenerlos y convertirla en un claro inconveniente.

Conclusión

Como decíamos al principio ésta es la configuración que recomienda SAP y es la que utilizan la mayoría de las empresas grandes que tienen presupuesto y personal suficiente para gestionar todos los sistemas. Cuando se instalan muchos módulos diferentes y de áreas diferentes (logística, finanzas y recursos humanos) se hace necesario tener un sistema aislado para las pruebas integradas. Una configuración con cuatro sistemas solo será necesaria para empresas que tengan un volumen de desarrollos propios realmente grandes. Como se puede suponer, la gestión de un sistema así requiere de personal realmente cualificado y de una metodología y procedimientos de transporte que eviten cualquier error ajeno a los desarrollos en sí mismos.